Here's the basics:
Go to http://www.somepage.com
Go to the URL and type the following
javascript:document.writeln("<h1>sometext</h1>");
Observe that the page content switches to "sometext" but the URL remains at http://www.somepage.com
This attack doesn't change what the user would see if they refresh the page. Nor does it change the content if they browsed to another URL in the future. It only changes the content until the user takes an action (submits a post, follows a link, etc). However, that action could be submitting their logon credentials...
So, why is this important? Well this enables a pretty convincing passerby attack. Imagine a user leaves their computer unlocked and the browser is left open at somebank.com. The attacker comes by and executes the above attack. But instead of entering sometext, the attacker inserts html which creates the bank.com page and changes one small item. The post of the login points to evilsite.com instead of somebank.com.
Now, the user comes back to the machine and remembers they need to check their bank account. The browser is already at the banks website. The URL is correct. The little URL bar is even yellow since the page is https (depending on the browser).
The user enters the username and password, hits submit, and off go the credentials to evilsite.com.
Clearly, it is not hard to add more complex html to create a convincing page.
Should you be concerned? Well, fundamentally this situation is not good. Arbitrary html content while keeping the URL address bar unchanged is a big security risk. But luckily, this attack can only be executed by a user with local access (at least to the best of my knowledge). This attack is a major threat for shared workstations and kiosks. However, most users are the only one using a machine. This is not a threat in that scenario. Now, if it is possible to do this remotely, then we have a huge problem. My tests so far have not been able perform this test remotely.
Here's a couple screenshot examples
Able to overwrite content of an https site. The nice little lock is still there :)
Can also read the content of the page, modify it and then return it to the browser.
Before
After
I just changed some text on the page, but I could have changed hidden fields, form elements, or inserted new data.
Just to be clear, this is an attack against the browser and how it handles local javascript calls in the URL. The remote site is never attacked, we simply use the javascript:document.writeln("blah") in the url. The browser made the incorrect decision to process the javascript and then replace the URL with the previous entry.
I really have no idea why the browser allows you to execute the javascript:document.writeln without changing the URL to some sort of local document reference. This is the case for both Internet Explorer 7 and Firefox 2.0.0.14
Happy browsing.
-Michael Coates