[ext] NoScript 1.9 - Your Friendly Web Cop

[Giorgio Maone]

@bbbux:
the exception would be

Code: Select all

^https?://www\.evernote\.com/clip\.action$

but on NS 1.9 you shouldn't need it at all: I'm testing Evernote Web Clipper 3.0.0.126 + NS >= 1.8.9.6 with no problem on any site.

[bbbux]

Thank you very much for the code, it worked

[marder]

There's a problem in NoScript (well, it gives users the good feeling of beeing secure) regarding domains and minimal social reengineering.
I would like to discuss a possible attack vector, when attacker knows that victim runs firefox with NoScript implemented.
please, let me know how to discuss these.

[Giorgio Maone]

@marder:
feel free to drop me an email. My address is listed on my home page.

[therube]

ClearClick warning.
Kind of a false positive? Perhaps happening because of the frame & two domains?

http://www.nam.aocdisplay.com/aoc/index.html

Click on MONITORS or TELEVISIONS menu items.

[Giorgio Maone]

@therube:
yes, it's an edge case due to a very slim Flash embed contained in a cross-domain frameset.
It did not happen in previous version because the frame-checking code was slightly different.
I'm using that page to implement a work-around, thanks for the pointer.

[Giorgio Maone]

@therube:
Fixed in latest development build

[vyznev]

Would it be possible to add some special case handling for reCAPTCHA to NoScript? Currently, it seems that if recaptcha.net itself is blocked from running JavaScript, any pages that are whitelisted will not be able to use reCAPTCHA, and vice versa. In the former case (recaptcha.net forbidden, main site allowed) it simply fails silently, while in the latter (recaptcha.net allowed, main site forbidden) one gets the following error message:

You are at this page because you loaded the JavaScript free version of reCAPTCHA, but it looks like you have JavaScript. We need to prevent this for security reasons. If you are testing out the JavaScript-free version, turn off JavaScript in your browser.

I'm not sure what these "security reasons" are (I can't really think of any way in which this would deter me if I was trying to write a CAPTCHA-solving bot), but what it seems to accomplish is mostly needless annoyance. Offhand, I can think of two ways to fix it: a) either allow JS from recaptcha.net only if the page loading the CAPTCHA is whitelisted, or b) unconditionally forbid JavaScript from pages beginning with "http://api.recaptcha.net/noscript".

(Ps. I don't seem to be the only one with this problem.)

[luntrus]

Hi NoScript users,

As we move to a Web 2.0 widget web, where the goodies on your site may not necessarily come from your site, it's worth sparing a thought for security. Imagine this scenario you just got bit on Perl.com, which redirected to a porn site courtesy to a piece of remotely-included JavaScript. One of your advertisers was using an ads system that required your pages to load JavaScript from their site. It only takes three things to turn Perl.com into porn.com: (1) the advertiser's domain lapsed, (2) the porn company bought it, (3) they replaced the JavaScript that you were loading with a small obfuscated chunk that redirected to the porn site (note that nothing on or about Perl.com changed). Your first concern will be that you'd been hacked and "run this remote JavaScript" inserted from your servers without your knowledge, but that hasn't happened—your change records and RT logs show you've had that JavaScript and advertiser since May 2008.

You will realize now that in many ways you were lucky, and the users that visit your site using NoScript—namely once an attacker can run JavaScript on your browser, very bad things may happen and will happen. So here are the questions we're asking ourselves, questions that all of you who run sites that take a lot of advertising or load a lot of widgets would do well to consider: do you know all the JavaScript your pages load? When do those domains expire? What other risks have you identified around remote JavaScript, and what are you doing to mitigate those risks? Decentralized content means decentralized security—it's up to us to ensure our systems are stronger than their weakest components. That is why I next to NoScript also use RequestPolicy to see where these requests come from: https://addons.mozilla.org/en-US/firefox/addon/9727/

luntrus

[atagar]

My apologies if this is the wrong place to report this, but links suggested this is the forum for bug reports. When visiting MyWSU (site for students attending Washington State University) certain portions of the site seem to cause NoScript to freeze. Firefox produces the following dialog:



This occurs regardless of if scripts are forbidden or allowed. The referenced line (noscriptService.js:6222) references a call to "findInjection.exec(s)" but unfortunately I'm not familiar enough with JavaScript to follow what's going on (execute a constant?). Hope this helps! -Damian (http://www.atagar.com)

[Giorgio Maone]

@atagar:
could you post the exact URL where this happens?
Thanks.

[sycthos]

I'm still experiencing the icon bug in NoScript 1.9.
I'm referring to the status icon, not the yellow notification bar.
I have the yellow notification bar disabled.

[atagar]

@atagar:
could you post the exact URL where this happens?
Thanks.

It requires authentication - are you thinking that it might be a url parsing issue? It's:
https://sts.wsu.edu/adfs/ls/clientlogon ... tPage.aspx

[Giorgio Maone]

@sychtos:
The disabled notification thing may be related with your problem. Does it persist if you enable back the notifications?

@atagar:
yes, I'm thinking of an URL parsing issue, but the URL is NOT that.
Could you try to let the script run (not stopping it) and see if any error or XSS message is displayed in the end in Errror Console?

[atagar]

@atagar:
yes, I'm thinking of an URL parsing issue, but the URL is NOT that.
Could you try to let the script run (not stopping it) and see if any error or XSS message is displayed in the end in Errror Console?

Weird - it worked and I had to clear authenticated sessions/cookies to get the problem to manifest again. When I clicked continue Firefox clenched up for a few more seconds then worked properly (no new messages in the error console). Guess something's probably just triggering a time out first time the site's loaded, yes?