InformAction Forums

Does anyone else think that this 12-year-old Firefox RFE sounds very much worth doing? The default browser behavior, of automatically attaching all of your cookies and HTTP AUTH to any cross-site request that random.com chooses to send, is just begging for CSRF attacks. Having an option to warn first - like the dialog to ask before setting cookies - would be really handy.

Yeah but isn't it pretty much obsolete with NS installed?

GµårÐïåñ wrote:Yeah but isn't it pretty much obsolete with NS installed?

Mostly yes, especially with RequestPolicy as well.

However:

• Lots of people either don't know about NS, or think it's too heavy-handed (their loss, of course). Putting this functionality into Firefox would make it available to *anyone* who explores the Preferences menu.
• Unwisely trusting a site would allow it to bypass NS protection. Likewise for people who use Scripts Globally Allowed or click-to-play mode (ie globally allow but block plugins).
• The default behavior of Firefox on this issue is just plain terrible from a security standpoint.

To open this address, Mozilla needs to use your | | `-' stored login for `Realm' at`server'.

I don't store logins, either in the browser's pw manager or in permanent cookies, and when doing sensitive things like banking, always close browser - reopen -- do banking - close -- reopen if intending to continue browsing. Everything gets dumped when closing.

So I think these practices mitigate the threat, at least for serious things like banking, but I can't think of a good reason *not* to implement the RFE, because, as you correctly noted, most users are not security-conscious.

@Thrawn, I agree with you in the sense that Fx is HORRIBLE when it comes to security, it went from being the unexploitable alternative to IE (their claim) to being worse. In fact, IE 9 has much better built-in security than Fx does out of the box and that's just disappointing.

@Tom, I agree with you as well. I don't store squat on Fx and I don't leave anything behind and this option would be another set it and forget it and think you are safe excuse for users to just be lazy about their own security.

I guess it won't hurt for it to be there, like JS disabling is in there (NS functionality), third party cookie is in there (Ghostery functionality), image blocking is in there (Adblock functionality) but of course in all cases very limited, tediously manual and not comprehensive at all. So adding another fairly crippled functionality to the list won't hurt but I don't it will help much either, just saying.

If a site is sensible enough not to be vulnerable to CSRF GET, and they disable autofill of passwords so the browser doesn't remember them, then would this not also protect against XSS and clickjacking?

Thrawn wrote:If a site is sensible enough not to be vulnerable to CSRF GET, and they disable autofill of passwords so the browser doesn't remember them, then would this not also protect against XSS and clickjacking?

I think it would yeah but can't say for sure.

It's also a possible answer to the recently-published CRIME attack against TLS. Note the paragraph near the end of that article, in brackets:

It would be better if the security model of Javascript was fixed to prevent malicious code from sending arbitrary requests to a bank server; I am not sure it is easy, though.

It seems to me that this RFE would go a long way toward accomplishing that. Arbitrary requests could be sent, but if they're being sent to a site that has cookies or HTTP AUTH, then the user gets a warning dialog, so they can anonymize or block the requests.

Does anyone want to upvote it on Bugzilla?