Closed Bug 18653 Opened 20 years ago Closed 20 years ago

"javascript:" URLs cross windows problems (probably regression bug)

Categories

(Core :: Security, defect, P3)

x86
Windows 95
defect

Tracking

()

VERIFIED FIXED

People

(Reporter: joro, Assigned: norrisboyd)

References

()

Details

Attachments

(2 files)

In builds 19991110 and 1999111108 (I think previous builds are unaffected)
"javascript:" URLs across windows reveals the DOM of the target document (guess
this is a regression bug).
The code is:
---------------------------------------------------------------------------
<SCRIPT>
a=window.open("http://www.yahoo.com","victim");
setTimeout("document.forms[0].submit()",10000);
</SCRIPT>
<FORM ACTION="javascript:s='Here are some links:   ';for(i=0;i< (
(document.links.length < 10) ? document.links.length : 10) ;i++) s +=
document.links[i].href +String.fromCharCode(10);alert(s);" TARGET="victim"
METHOD="POST">
<INPUT TYPE="SUBMIT">
</FORM>
---------------------------------------------------------------------------
Status: NEW → ASSIGNED
Target Milestone: M13
Assignee: norris → nisheeth
Status: ASSIGNED → NEW
Nisheeth, I wonder if your changes in this area may have caused this regression.
If you put a breakpoint in nsJSProtocolHandler::NewChannel and load the above
URL, you'll see that when it gets the URI from the webshell it gets yahoo rather
than the attacker page, so we fail to stop the attack.

Can you take a look at this? I'm happy to help out, but I don't know much about
URLLoaders.
Status: NEW → ASSIGNED
Accepting bug.
Assignee: nisheeth → norris
Status: ASSIGNED → NEW
The change that I had made earlier is documented in bug 1646.  We assumed that
the referrer of the url being loaded in nsJSProtocol::NewChannel() is accessed
by calling nsWebshell->GetURL().  This assumption is not true for the case
when a form is submitted by an "attacking" webshell targeted at a "victim"
webshell.  In that case, nsWebShell->GetURL() returns the URL of the victim
webshell while the correct referrer url is the URL of the attacking webshell.

The fix is to pass the referring URL from the doc loader on to the JS protocol
handler.  If the referrer url parameter to nsJSProtocolHandler::NewChannel() is
non-null, that url is used as the referrer url.  If the parameter is null, the
earlier method of calling nsWebshell->GetURL() is used to determine the referrer
url.

The patches to nsDocLoader.cpp and nsJSProtocolHandler.cpp are attached.

Even with these patches, the call to the security manager's
GetCodebasePrincipal() returns successfully and the attack succeeds.

Re-assigning this to Norris so that he can take it from here.
Attached patch nsDocLoader.diffSplinter Review
Target Milestone: M13 → M14
These bugs didn't make M13, postpone until M14.
Status: NEW → ASSIGNED
Merged nisheeth's patches into the latest version. (I'd fixed the other problem 
in another bug.)
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Verified fixed.
Status: RESOLVED → VERIFIED
Bulk moving all Browser Security bugs to new Security: General component.  The 
previous Security component for Browser will be deleted.
Component: Security → Security: General
Flags: testcase+
Flags: in-testsuite+ → in-testsuite?
You need to log in before you can comment on or make changes to this bug.