NoScript breaks Amazon AWS Calculator page

[womble]

Hi, I am finding that NoScript (2.6.7.1rc1) in Firefox is breaking the AWS Fee Calculator page, here: http://calculator.s3.amazonaws.com/

When NoScript is enabled (even after allowing all scripts globally), the AWS calculator page display this error dialog: http://i.imgur.com/RqCARrw.gif

- I disabled all addons except NoScript, problem remained.
- Disabled only NoScript, page worked correctly.

No amount of white-listing or disabling of options in NoScript makes the page work. The only way it works is completely disabling the NoScript addon. This is the first time I've seen this happen, in years of using NoScript, so I thought it was worth mentioning. (ed: Also tried on two different PCs as well, one XP the other Win7-64, same behaviour on both).

If someone can try out the AWS page and get it working in FF with NoScript, please let me know how you did it.

[barbaz]

You are running a very old version of NoScript. Please update NoScript to the latest development build (2.6.8.19rc2) and let us know if that solves your problem.

If that does *not* help, could you leave NoScript updated, try again to use the calculator with NoScript enabled, watch it fail, and post here any related messages you see in the Error Console (Ctrl-Shift-J)?

[womble]

could you leave NoScript updated, try again to use the calculator with NoScript enabled, watch it fail, and post here any related messages you see in the Error Console (Ctrl-Shift-J)?

Thanks, I've just done that, same behaviour occurs. It seems to be blocking some XSS, as the console had these entries in the Messages section (cleared the console first, reloaded page, then these appeared):


(posting the text seems to trigger the forum spam filter, hence a screenshot instead)

It seems odd, as I had previously added the following exception entry in the Advanced -> XSS tab:
^http://([\w-]+\.)+?cloudfront\.net.*
(testing in RegexBuddy, that does match those URLs in the console)

Pic of my XSS exceptions:


Is there a way of disabling the XSS module, or a regex to allow everything, so I can test if that's indeed the issue?

[barbaz]

It's not working because that's not the XSS filter that is triggering. Add

Code: Select all

^https?://([^/:]+\.)?cloudfront\.net/ver[0-9u]+/dictionary/(?:common|language/.+)\.txt(?:$|\?)

to about:config -> noscript.inclusionTypeChecking.exceptions

[Thrawn]

More and more sites are having problems with the content-type and content-disposition filtering, and in this case, I'm not sure that it's actually a mistake on Amazon's part.

Perhaps these filters should be visible in the Options dialog?

[womble]

noscript.inclusionTypeChecking.exceptions

Thank you! I just tried turning noscript.inclusionTypeChecking off, and that fixed it. Yay! Definitely needs to be in the options dialog, IMO. I spent hours trying various things to get a very important web page working.

Question: My exclusions in noscript.inclusionTypeChecking.exceptions is simply this:

https://scache.vzw.com/ http://cache.vzw.com .sony-europe.com .amazonaws.com lesscss.googlecode.com/files/ .hp-ww.com .yandex.st

That doesn't look like it accepts regex strings. I simply added ".cloudfront.net" to the end, and that fixed it.

Although I'm very tempted to turn the thing off, as its operation is completely opaque. However, how that I know about the console, I'll try to remember to look at that when something funny happens. I think there at least needs to be an addition to the NoScript pop-up menu - something like this:



I imagine it would be relatively easy to add such an option, which just adds or removes a domain in noscript.inclusionTypeChecking.exceptions.

[barbaz]

I just tried turning noscript.inclusionTypeChecking off, and that fixed it.

that's a bad idea... you've allowed all sites to abuse all files from other sites

Definitely needs to be in the options dialog, IMO.

+1

Question: My exclusions in noscript.inclusionTypeChecking.exceptions is simply this:

https://scache.vzw.com/ http://cache.vzw.com .sony-europe.com .amazonaws.com lesscss.googlecode.com/files/ .hp-ww.com .yandex.st

That doesn't look like it accepts regex strings.

it's an "AddressMatcher", which is a space-separated list of sites specified like this:

• ^https?://some\.site\.com/.*
regular expression
• *.some.site.com
(matches anything.some.site.com but not some.site.com) or
.some.site.com (matches anything.some.site.com and some.site.com)
glob expression; a glob expression starting with “.” will match both the subdomains having
it as a suffix and the domain stripped of the leading dot.
• www.some.site.com
domain literal
• http://www.somesite.com
URI literal with “starts with” matching

I simply added ".cloudfront.net" to the end, and that fixed it.

too inclusive IMO

I think there at least needs to be an addition to the NoScript pop-up menu - something like this:

this is *not* the XSS filter
there is no XSS
this feature simply checks whether the MIME type of cross-site requests is correct
that said, such an entry in the noscript menu could be a good idea, sometimes

[womble]

this is *not* the XSS filter
there is no XSS
this feature simply checks whether the MIME type of cross-site requests is correct
that said, such an entry in the noscript menu could be a good idea, sometimes

Thanks heaps for those details, I understand better now. If I add that entire regex for the cloudfront exception, will it slow things down much? I mean, does NoScript run those comparisons on every domain a site requests, or just in certain circumstances where it will apply? The reason I just added ".cloudfront.net" was firstly curiosity, but also to "keep it simple" in case doing too many regexs there creates a bottleneck. Depends how NoScript works.

ED: My TypeChecking exception string is currently this:

https://scache.vzw.com/ http://cache.vzw.com .sony-europe.com .amazonaws.com lesscss.googlecode.com/files/ .hp-ww.com .yandex.st .cloudfront.net

Notice ".amazonaws.com", ".hp-ww.com" and ".yandex.st" - how did those get in there? Are they the default that comes with NoScript? If so, they also seem too inclusive. Can you post what yours is at the moment for comparison?

[barbaz]

If I add that entire regex for the cloudfront exception, will it slow things down much?

NoScript converts the entire pref into one big regexp internally, so I doubt that one explicitly specified regular expression is going to slow things down significantly. Giorgio would know more though.

Notice ".amazonaws.com", ".hp-ww.com" and ".yandex.st" - how did those get in there? Are they the default that comes with NoScript? If so, they also seem too inclusive. Can you post what yours is at the moment for comparison?

Yes, they are default, and I've never bothered to edit that pref on my own setup. I agree with you that it does look like those are too inclusive, but since I don't know why they're there, I can't say for sure.

[Thrawn]

They have been added to NoScript due to threads like this one, where a legitimate site is found to break due to the filter.

[womble]

They have been added to NoScript due to threads like this one, where a legitimate site is found to break due to the filter.

Any chance of it being added to NoScript in this fashion?




(The above notice appears when ITC is actually blocking something, so we know what's going on = less threads like this)

[barbaz]

Any chance of it being added to NoScript in this fashion?

+1.
(Your RFE might get more attention if you post it as a new topic in the NoScript Development forum instead of adding it to the end of a support thread where the original issue is resolved..)

[womble]

(Your RFE might get more attention if you post it as a new topic in the NoScript Development forum instead of adding it to the end of a support thread where the original issue is resolved..)

Done.