InformAction Forums

JavaScript is able to read and write cookies despite ABE applying the Anonymize action

That's not surprising. The Anonymize action is designed to prevent attacks like CSRF, which don't involve hostile JavaScript on the target site, just an attacker request sent to it. ABE strips cookies from the request, but doesn't try to control the behavior of JavaScript loaded from the response.

CSRF can occur whether the cookie processing is done by the target site on the server side or on the client side (in the case of frames).

Attacks that rely upon server side processing of cookies do not rely upon hostile PHP/Perl/ASP/whatever coding on the target site either.

An attacker's request can be used to achieve the same results if the target site uses JavaScript to interact with authentication cookies.

RobertDrew wrote:An attacker's request can be used to achieve the same results if the target site uses JavaScript to interact with authentication cookies.

I don't understand this claim. A CSRF attack doesn't involve any JavaScript loaded from the target (eg your bank). It's a blind request, with the attacker forbidden to read the response because it's cross-site. The whole attack is in the request (eg a request to transfer money to the attacker's account). Stripping your authentication from the request defeats the attack.

Perhaps you are talking about cross-site scripting, rather than cross-site request forgery? In which case, the Anonymize action is not what you want. Sandbox might be better. But bear in mind that NoScript already has a cutting-edge XSS filter.

I'm not talking about XSS ...

CSRF basically relies upon two things ... the ability to send a command (e.g. transfer money), and authentication for that request (e.g. via cookie).

For example, the following URL might be loaded in an invisible iframe:
https://bank.example.com/transfer/?amou ... to=Mallory

The command in this case is transmitted via GET parameters. Of course, the request will not be successful unless the user's browser is authenticated (such as by cookie, either because the site is open in another tab or because the user never logged out after the last time they went to their bank's site). In order to render the request harmless, the cookies have to be suppressed. Now, the page which was loaded in the iframe from above may look at the cookies in the HTTP headers, or it may look at the cookies using JavaScript's document.cookie property. In cases where it looks at the cookies through JavaScript, which would be more likely in an AJAX-heavy site, for example, the Anonymize action is not sufficient to prevent CSRF.

I'm not talking about malicious JavaScript being injected into the target site. I'm talking about a target site which just happens to do cookie processing with JavaScript. In such a case, CSRF would be possible because ABE's Anonymize action does not suppress JavaScript access to the cookies. A solution to this problem could be to override to intercept access to the document.cookie property for any page load which was Anonymize'd.

A CSRF attack doesn't involve any JavaScript loaded from the target (eg your bank).

It can if the JavaScript happens to be involved in processing the cookies. Just like it can if PHP is used to do all of the cookie processing prior to page load.

It's a blind request, with the attacker forbidden to read the response because it's cross-site.

The attacker does not need to see the response to exploit the issue in the scenario I have outlined.

The whole attack is in the request (eg a request to transfer money to the attacker's account).

The attack remains in the request, but the exploit is in the handling of the request in either case, whether that handling takes place before page load or after page load.

Stripping your authentication from the request defeats the attack.

Not if authentication cookies are processed with JavaScript. For example, an AJAX site might have JavaScript which takes authentication data from document.cookie, then transmits that data along with the specific request (e.g. transfer money) back to the server via XHR and waits for dynamic page content to load as result of that request. You and I may question the merits of that approach, but the reality is that a) we cannot rule out the possibility of a use case where something along those lines makes sense, and b) even if it isn't the best way to do things it doesn't mean it won't be done -- ultimately, NoScript is designed specifically to address the security failings of the developers behind our banks' (for example) sites. CSRF wouldn't be possible if Web application developers did everything right, but they don't, which is one of the reasons NoScript exists.

Ah, what you're describing is essentially GET-based CSRF (load a page with the right query string and the site takes action). Presumably it would work just as well with a redirect instead of a frame (except being more visible).

Any site that allows state-changing operations via GET is basically broken and can't be protected via the usual mechanisms. If you really want to protect it, you'll need to use Deny rather than Anonymize.

Thrawn wrote:Any site that allows state-changing operations via GET is basically broken and can't be protected via the usual mechanisms. If you really want to protect it, you'll need to use Deny rather than Anonymize.

It would be protected if access to cookies were suppressed....

Using Deny is not an appealing option ... with a blacklist approach, you would have to remember to add every site you have credentials for to your rulesets; with a whitelist approach, you would have to make exceptions for lots and lots of websites which would become broken as a result. Anonymize is a much more appealing option because it allows a blanket rule to be applied to protect all sites, and requires much fewer exceptions to be added to restore broken functionality along the way.

If the developer doesn't wish to add cookie suppression for JavaScript, perhaps he would be willing to add a way for JavaScript to be able to detect that NoScript applied the Anonymize action (by setting a variable, say NoScriptABEAnonymized, to true)? This would allow a user to set up a GreaseMonkey script which suppresses cookie access in the relevant cases.

RobertDrew wrote:

Thrawn wrote:Any site that allows state-changing operations via GET is basically broken and can't be protected via the usual mechanisms.

It would be protected if access to cookies were suppressed....

But that is a much more complex business than it might sound like.

Using Deny is not an appealing option ... with a blacklist approach, you would have to remember to add every site you have credentials for to your rulesets; with a whitelist approach, you would have to make exceptions for lots and lots of websites which would become broken as a result. Anonymize is a much more appealing option because it allows a blanket rule to be applied to protect all sites, and requires much fewer exceptions to be added to restore broken functionality along the way.

Exactly my point when I say, "the site is basically broken and can't be protected via the usual mechanisms." If you can't trust links and redirects to be read-only, then you have to break the web to protect the site.

If the developer doesn't wish to add cookie suppression for JavaScript, perhaps he would be willing to add a way for JavaScript to be able to detect that NoScript applied the Anonymize action (by setting a variable, say NoScriptABEAnonymized, to true)? This would allow a user to set up a GreaseMonkey script which suppresses cookie access in the relevant cases.

That is an interesting idea, but if you're going to fix it with user scripts, then you probably don't need to set such a flag at all. You could use a surrogate script to put a framebuster on the site to be protected, for example.

RobertDrew wrote:If the developer doesn't wish to add cookie suppression for JavaScript, perhaps he would be willing to add a way for JavaScript to be able to detect that NoScript applied the Anonymize action (by setting a variable, say NoScriptABEAnonymized, to true)?

If this does get implemented this would *definitely* have to be limited to surrogates and/or privileged code (which user scripts using @grant are), there is no way I want ABE to be that easily detectable to the page, especially given my personal use of Anonymize.