On Wed, 11 Jan 2012 14:09:23 -0800, Chad innocentkiller@gmail.com wrote:
On Wed, Jan 11, 2012 at 4:43 PM, Happy Melon happy.melon.wiki@gmail.com wrote:
Yes, no user-editable scripts are run on pages where password forms reside, because it is trivially easy for users to use them to introduce password-sniffing JS attacks, either deliberately or inadvertantly. Or that's the idea, at least; IIRC there's an open bug about gadgets running somewhere they probably shouldn't, etc.
Yep, you're looking at bug 10005[0]. This applies to password reset pages, preferences (last I checked) and user login.
-Chad
That bug appears to be about user-js.
I used to be in the camp that wanted scripts to not be run on login pages for security, and opposed ajax logins on the grounds that scripts would be run on the page.
But awhile ago I learned about the history.pushState api. I found that it's almost pointless to hide scripts exclusively from pages with password forms on them. Since if a script is run on 'any' page on the wiki it's possible to use xhr and pushState together to fake the entire page browsing functionality, including the address bar changing as if you actually went to the url. So it's possible to hijack the native page browsing and make it look like the user went to the user login page when in reality the page never changed, the whole login page was actually loaded by xhr, and the malicious script is still running ready to swipe your password.