InformAction Forums

Following the advice in my signature, I was reading the dev build changelogs, and this makes me somewhat hesitant to update NoScript:

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.

I'm curious, why remove that completely? Why not just turn it off by default?

The only way to regain that functionality through ABE with the same convenience as before is going to be to use Thrawn's SABER extension, which AFAIK isn't even alpha stage yet...

I'm withholding NoScript's update as well. I'm uncomfortable with NoScript being stuck with the equivalent of a forbidXHR set to 0 (Allow any XHR) instead of 1 (Allow cross-site XHR across trusted sites only).

An explanation would be very welcome. Why isn't cross-site XHR a security threat anymore ? Or a privacy one ?

Thanks

As it currently stands (with CORS used as a way to regulate information disclosure from the requested resource), cross-site XMLHttpRequest doesn't pose any additional security or privacy risk than any resource fetching (e.g. through an <img> element) or script-driven form submission.
When the forbidXHR feature had been originally implemented, details on how to limit cross-site XHR were still murky and implementation was experimental and possibly buggy.
It's not the case anymore, while instead this obsolete feature is increasingly causing incompatibilities with websites and add-ons which are quite difficult to debug and work-around.
However, please let me know if you've got specific, current and real world concerns about it which could justify reintroducing it.

Thanks for the explanation. Couple questions:

1) Is even Fx 3.6.28 recent enough that this feature can be considered just as obsolete there as it can with, say, SeaMonkey 2.32.1?

2) Doesn't this put a lot of additional trust in what websites do with XHR?
Can a (Temp-)Allowed site do something crazy like fetch an entire JS file (or a file containing some segment of JS) from a non-(Temp-)Allowed site, read its contents into a variable, and pass the result to eval(), and thus pose a risk that's not there if that XHR were blocked? Or would NoScript (or something else) stop such madness some other way?
(Plugin objects fetched by XHR and embedded as data URIs would get placeholders, right?)

Privacy issue: Cross-site XHR with CORS doesn't respect referrer preferences. If no referrer is sent, Origin is still set.

Consistency issue: I'm guessing form submission means cross-site POST requests, in which case NoScript can turn them into GET requests with no parameters, and they respect referrer preferences. Shouldn't we expect cross-site XHR to behave similarly, instead of being allowed as-is in all situations ?

barbaz wrote:Thanks for the explanation. Couple questions:

1) Is even Fx 3.6.28 recent enough that this feature can be considered just as obsolete there as it can with, say, SeaMonkey 2.32.1?

Firefox 3.6.28 has bigger issues to worry about, but yes, I can't see any overwhelming benefit for that version either.

barbaz wrote: 2) Doesn't this put a lot of additional trust in what websites do with XHR?
Can a (Temp-)Allowed site do something crazy like fetch an entire JS file (or a file containing some segment of JS) from a non-(Temp-)Allowed site, read its contents into a variable, and pass the result to eval(), and thus pose a risk that's not there if that XHR were blocked?

Yes it can, but this means either that the temp-allowed site is malicious in itself or that it has been compromised.
In the former case I cannot see any additional benefit from retrieving the payload through XHR. In the latter it could give help work around size restrictions, but using XHR is usually quite verbose so the advantage seems slim. However this, no matter how slim, might actually be an argument in favor of restoring the remove functionality. I'll take a week looking for alternate ways to work around the compatibility issues and see what can be done in next release.

barbaz wrote: (Plugin objects fetched by XHR and embedded as data URIs would get placeholders, right?)

Nope, but again, this would only help working around size issues. And yet, again, it might be a reason to restore XHR restrictions.

Giorgio Maone wrote: I'll take a week looking for alternate ways to work around the compatibility issues and see what can be done in next release.

Please check latest development build 2.6.9.14rc1, thanks.

Upgraded, thank you Giorgio!

Thanks!

In the latter it could give help work around size restrictions

I wonder what are those size restrictions and how XHR helps a compromised site getting around them.

Anyway, when you will be publishing a release build with a modified forbidXHR feature, would you mind explaining how it has changed ?

bgmnt wrote:Thanks!

In the latter it could give help work around size restrictions

I wonder what are those size restrictions and how XHR helps a compromised site getting around them.

Anyway, when you will be publishing a release build with a modified forbidXHR feature, would you mind explaining how it has changed ?

Currently the change is that it allows XHR toward a data: URL, which is something kind of useless (to attackers, too) but which apparently the Zotero add-on relies upon, and had no work-around in previous version but disabling XHR blocking at all (you cannot whitelist data: URLs).

Ok, thanks again for clearing it up.

I don't know enough on data: URI to give input so I'm going to trust you