InformAction Forums

Hi,

I'm currently digging into cross-origin requests and how they evolve as the World Wide Web Consortium and the Internet Engineering Task Force keep spawning standard after standard. It's all fine and good, but these groups are populated with a number of huge companies with direct interests in the data business, so it's not a bad idea to keep our eyes peeled.

That said, I just dug into CORS (Cross-Origin Resource Sharing) and how it extends XML Http Request among other things. I also heard about Fetch but am yet to dig in it.


My question is, does NoScript do something about the ORIGIN header specified by CORS ? Should it ? After all, NS has a whole XSS protection feature and even bothers to turn cross-origin POST requests into GET requests with no data.

What about Fetch ? I could be wrong but it seems that it works without JavaScript and also has an ORIGIN header. (This is separate from the "REFERER" header which can be disabled in about:config, I believe ORIGIN is sent regardless of the referrer settings)


Sorry this is a little messy. Basically this thread is about the ORIGIN header in particular, and extends the topic to XSS protection, what NoScript does about it (notably with the advance of CORS) and what it will do in the future (Fetch and possibly other standards).



(PS: Writing "XML Http Request" in one word in your post triggers the spam filter)

(related, viewtopic.php?f=8&t=19540 )

I think the guy actually asks for Origin *to be sent* with every POST request, as a CSRF protection measure. Because Firefox doesn't send it yet for regular POST (but Chrome apparently does). Now I could be wrong but I believe Firefox does send it with cross site XML Http Requests, and I was wondering if NoScript does something about it.

Like, if the Origin header is actually necessary for the request to succeed, set it to the target website instead of the source to avoid privacy issues.

bgmnt wrote:Like, if the Origin header is actually necessary for the request to succeed, set it to the target website instead of the source to avoid privacy issues.

Ah, no. Because that defeats the entire security purpose of the header, and NoScript is a security tool first, privacy second.

The point of the Origin header, I thought, was that it does not have the same privacy concerns as Referer, and so there is no need to block it (at proxies, etc), so it is more likely to be available for security purposes.

Origin contains the host instead of the whole URL, but that's still a privacy concern IMO. I'm not comfortable with it.

Maybe NoScript's normal XSS protection feature is good enough that we don't need the Origin header. I mean, NoScript goes pretty far already in tinkering with requests when it transforms cross-site POST into GET with no parameter. Shouldn't it also mess with the new cross-site XML HTTP Request standard revisited with CORS, which uses the Origin header ? Unless NS does already, in which case yay but I would like to hear about it

I've yet to look into Fetch (the thing controlled by the dom.fetch.enabled pref, I believe). If it really does work without JavaScript, I would also like to hear about what NoScript does or intends to do once Mozilla enables it by default.

I forgot where else the Origin is sent. XML Http Request, most likely the Fetch thing, regular cross-site POST (not applicable to Firefox, or not yet), and I believe a handful of edge cases.

bgmnt wrote:Origin contains the host instead of the whole URL, but that's still a privacy concern IMO. I'm not comfortable with it.

Well, I'm sure that there are, or will be, addons to let you block the header. The security vulnerability occurs when the site assumes that it can use the header to distinguish real users from CSRF attacks, and then you forge it so that traffic from your browser always looks legitimate. Bingo, CSRF comes back.

Maybe NoScript's normal XSS protection feature is good enough that we don't need the Origin header. I mean, NoScript goes pretty far already in tinkering with requests when it transforms cross-site POST into GET with no parameter.

Except if you trust the origin.

The security vulnerability occurs when the site assumes that it can use the header to distinguish real users from CSRF attacks, and then you forge it so that traffic from your browser always looks legitimate. Bingo, CSRF comes back.

CSRF is only a nuisance for the client when it has credentials on the target site, I think ? (And with no credentials, it would mostly be an issue for the target site rather than the client.) In that case a little CSRF here and there is acceptable for me, but showing where I come from is not.

I don't know if NoScript can or should do anything. But it was worth bringing these topics to NS support and hopefully Giorgio, so that I can hope that NoScript will keep an eye on the situation.

bgmnt wrote:CSRF is only a nuisance for the client when it has credentials on the target site, I think ?

Or a valid session cookie.

And it's more than a nuisance; it lets the attacker take any action on your behalf, as if s/he were logged in as you (eg at your bank).

Yep.

One could want to forbid cross-origin XML Http Requests through a NoScript anti-XSS about:config option that would be turned off by default, if nothing else fits the bill.

Dunno. Thanks for the feedback anyway

bgmnt wrote:One could want to forbid cross-origin XML Http Requests through a NoScript anti-XSS about:config option that would be turned off by default,

Like this?

https://noscript.net/changelog#1.4.9.4 wrote:v 1.4.9.4
==========================================================================
+ Added client-side policy control for new Firefox 3 cross-site XHR,
configurable via noscript.forbidXHR about:config preference:
0 - Allow any XHR
1 - Allow cross-site XHR across trusted sites only (default)
2 - Allow same-site XHR only (like Firefox 2)
3 - Forbid all XHR

Nice! And the default is good if it indeed means both source and target sites must be whitelisted for XHR to be allowed. I'm going to leave it as default. Thank you!

Now the fetch thing hopefully doesn't work without JavaScript or something. I really need to read more about it before Firefox enables it by default.

EDIT - this part of the changelog was superseded by NoScript v 2.6.9.14rc1

https://noscript.net/getit#devel wrote:v 2.6.9.13rc1
=============================================================
[...]
- Removed support for XMLHttpRequest blocking
(noscript.forbidXHR preference). The same functionality,
if really needed, can still be achieved through ABE anyway.

Oh noes. I take it that from now on, NoScript will behave as if it had forbidXHR set to 0 (Allow any XHR) instead of 1 (Allow cross-site XHR across trusted sites only) ?

I don't even know if 1 can be replicated with ABE ?


Either way, I would very much like to hear the reasoning on why this feature was troublesome to the point that development time was allocated to its removal. I don't understand unless NoScript's newest version still behaves like previous ones.

I have all the same concerns as you do, so I posted viewtopic.php?f=10&t=20538

Oh thanks! I posted something over there