Bug 31270 – Social Engineering Issue with "javascript:" URLs

• Status: RESOLVED
• Resolution: INVALID
• Component: WebCore JavaScript

[Nathan Hammond]

This vulnerability is with regards to how easy it is to create a XSS + worm + phishing attack without necessarily triggering a non-technical user's security alarm. This could become a common attack vector at any point in time.

1. Create a Facebook group, 'Get $25 from $BANK'. (This works for any social networking site.)
2. Provide simple, easy-to-follow directions that will walk the person through using a "javascript:" URL, causing the user to create their own XSS hole in the social networking web application.
3. Use your new access to help promote the group in a worm-style manner, in a TRUSTED ENVIRONMENT: "Your friend Joe Smith has invited you to join the group, 'Get $25 from $BANK'."

Non-malicious examples of 1-3 in the wild:
-> http://www.facebook.com/group.php?gid=170096529644&v=info
-> javascript:var numfriends=document.getElementById('friends').getElementsByTagName('li').length;fs.click(document.getElementById('friends').getElementsByTagName('a')[1].parentNode);for(var i=0; i < numfriends; i++){fs.click(document.getElementById('friends').getElementsByTagName('a')[i].parentNode);}

4. Add a script loader into the "javascript:" URL. Any will do.
-> http://www.nczonline.net/blog/2009/07/28/the-best-way-to-load-external-javascript/

5. Use the script loader to load http://www.example.com/maliciousscript.js which mutates the DOM (blows everything away)--without making a page request--and turns it into a phishing site.

*** <FIXABLE PROBLEM> ***

6. Note that the URL still displays the "javascript:" URL. This effectively masks the site that the user is presently on (facebook.com, controlled by example.com/maliciousscript.js). With properly written instructions on the Facebook group the user will implicitly believe that they are on the actual $BANK site in spite of the "javascript:" URL being displayed in the location bar, *because they specifically pasted it there to create the action.*

*** </FIXABLE PROBLEM> ***

7. Steal usernames and passwords from thousands of people. Profit.

[Nathan Hammond]

I've reported this issue to Mozilla as well, bug 527530.

[Adam Barth]

Can you say concretely what change you'd like us to make?

Also, can you CC [e-mail] to the Mozilla bug so we can coordinate our response?  Thanks.

[Adam Barth]

Nevermind, I see that Mozilla has made this issue public.  I'm doing the same here.

[Nathan Hammond]

The change I am suggesting:

Immediately after execution of a "javascript:" URL, return the location bar to its prior state.

This would prevent the phishing site from hiding behind the "javascript:" URL.

[Adam Barth]

I'm sorry, but that's not a bug in WebKit.  The embedder (Safari) controls whether to reset the location bar.  For example, Chrome uses WebKit and does reset the location bar.  You should file a bug here:

http://bugreport.apple.com/

[Nathan Hammond]

Okay, thanks!

[Nathan Hammond]

<rdar://problem/7378262>