Is default-deny for JavaScript necessary for good security?

[Giorgio Maone]

I have the anti-XSS features enabled in NoScript, and I have my financial web sites in the whitelist. Does the present version of NoScript fail to provide the full anti-XSS protection when JavaScript is globally allowed because NoScript effectively whitelists all sites (including the evil remote payload sites)?

You're missing two different protections.
Anti-XSS guards against reflective XSS injections, and it works no matter what your whitelist is.
Script blocking (which you turn off) prevents 3rd party scripts from being included in your whitelisted site if their origins are not whitelisted as well.
This has nothing to do with Anti-XSS, but helps in most persistent XSS / SQL Injection scenarios, because using a remote inclusion is much more practical, and often the only feasible path for an attacker (e.g. if the injectable field has length constraints, see http://ha.ckers.org/blog/20080110/dimin ... st-wrapup/ ).

If so, please see http://forums.informaction.com/viewtopi ... =10&t=2714, where I requested the ability to globally allow JavaScript and to allow plugins only on selective sites, without effectively whitelisting all sites.

As I said, whitelisting has nothing to do with anti-XSS.

If you are considering a scenario where the evil JavaScript is injected into my financial site's server/domain, then the evil JavaScript is allowed to execute in my browser anyway because my financial site is in my NoScript whitelist, regardless of whether I globally allow JavaScript or not.

No, it most likely cannot execute anyway: see the considerations above about a persistent injection being highly impractical and often impossible to be made "self-contained", i.e. it will come from a different (non whitelisted) domain and it will fail to load because of NoScript script blocking.

I hope that having Defense+ block most of Firefox's access rights provides some protection, especially since one of those access rights being blocked is disk access.

LOL, do you really mean your bookmarks and preference are not persisted across browser restarts?

I always run Firefox from a limited user account (LUA).

And are your important documents on a different account?

What evil can a JavaScript do (leveraging a Firefox privilege escalation vulnerability) on an LUA given the Defense+ access rights restrictions I mentioned above?

As I hoped to have clearly explained in my previous post, it can (incomplete list):

1. Sniff the details of any financial transactions of yours and log them on a remote server
2. Surely read your browser history, preferences and bookmarks, and log them on a remote server
3. Almost surely write and be persisted in your browser profile (otherwise most of your browser functionalities, including bookmarks and preferences, would't work)
4. Probably read your important documents (unless they belong to a different account or you're using and correctly configuring a filesystem read sandbox) and log them on a remote server
5. Use your browser as a spam bot, as a click fraud bot, or both
6. ... the sky is the limit

Is this enough?

[Tom T.]

As I hoped to have clearly explained in my previous post, it can (incomplete list):

1. Sniff the details of any financial transactions of yours and log them on a remote server
2. Surely read your browser history, preferences and bookmarks, and log them on a remote server
3. Almost surely write and be persisted in your browser profile (otherwise most of your browser functionalities, including bookmarks and preferences, would't work)
4. Probably read your important documents (unless they belong to a different account or you're using and correctly configuring a filesystem read sandbox) and log them on a remote server
5. Use your browser as a spam bot, as a click fraud bot, or both
6. ... the sky is the limit

Is this enough?

You did explain it quite clearly in your previous post. The OP doesn't want to listen, because it's not what he wants to hear. (Like when you said "sniff" and he read "keylogger').

OP has made it plain that he intends to allow js globally, no matter what you say or what proofs or examples you provide to the contrary. It's hard to see how this thread can provide any more useful information, and only wastes your time. Would you consider locking it?

... the sky is the limit

And if OP persists in the face of that, perhaps OP should not be allowed here. IMHO. YMMV.

[GµårÐïåñ]

I believe the user to be a shill as well, since I don't believe anyone can be this dense. Regardless of the purpose of the post, sufficient positions have been presented and the subject has been thoroughly debated. I vote we simply ignore this topic and not continue to bump it.

[Tom T.]

I believe the user to be a shill as well, since I don't believe anyone can be this dense. Regardless of the purpose of the post, sufficient positions have been presented and the subject has been thoroughly debated. I vote we simply ignore this topic and not continue to bump it.

Agreed. But if OP persists.... ?

[GµårÐïåñ]

Lock the thread, ban the user. IMHO.

[SeanM]

I believe the user to be a shill as well, since I don't believe anyone can be this dense. Regardless of the purpose of the post, sufficient positions have been presented and the subject has been thoroughly debated. I vote we simply ignore this topic and not continue to bump it.

Agreed. But if OP persists.... ?

If the OP is indeed a "shill", he/she (perhaps inadvertently) allowed a stronger position to be presented, weakening the original argument. I personally have learned much in this thread, and yes, I did fall for Giorgio's "3-minute egg", hanging my FF out in Death valley. I am not sure whether additional debate or conjecture may sustain viability here. Although this forum is not a democracy, I personally would make this thread a "sticky" and must-reading. It is located in the "General" section, where noobs (like myself) can learn.

As to "locking the thread", he/she will just start another ramble. Banning him/her will just prompt the generation of another username.

.... I must get my tin hat .......

[Tom T.]

Sean, thank you very much for presenting an alternative opinion from a user's point of view.

...If the OP is indeed a "shill", he/she (perhaps inadvertently) allowed a stronger position to be presented, weakening the original argument.

Agree completely, and I did point that out to one user who thought that we were unwittingly being scammed by this shill.

I personally have learned much in this thread, <snip> I personally would make this thread a "sticky" and must-reading. It is located in the "General" section, where noobs (like myself) can learn.

That is a very strong argument for keeping it, possibly even making it sticky, although since it's a bit contentious, I think it might be better merely to include a link to it in the FAQ and/or Quick Start Guide, with a link title, "Is default-deny Javascript really necessary", or something similar.

and yes, I did fall for Giorgio's "3-minute egg", hanging my FF out in Death valley.

I didn't "fall for it", I ran it eagerly to see Giorgio's proof of concept. As he stated, and as I know very well, his ethics would prohibit him from posting any actual malicious code. The OP took advantage of those ethics to denigrate the demos as "mere annoyances", despite the fact that Giorgio said that he wrote both in three minutes, and any knowledgeable hacker (himself included) with a little more time to spare could do far greater evil.

I wouldn't run everyone's POC (proof of concept; demos of vulnerabilities), but you may rest assured that Giorgio would never post code that would actually harm your computer.

I am not sure whether additional debate or conjecture may sustain viability here.

As Guardian said, and I agreed, the subject has been debated thoroughly and sufficient arguments have been presented that there is little need for further discussion.

As to "locking the thread", he/she will just start another ramble. Banning him/her will just prompt the generation of another username.

We have the ability to block IPs as well. Of course, there are many ways to obtain a different IP. But banning takes only a few seconds of a moderator's time, so at some point, most spammers, trolls, flames, etc. usually get tired of the repeated efforts, and go annoy someone else.

.... I must get my tin hat .......

We should all wear them at all times!

Thanks again for a different perspective from a self-described "noob", although users at many levels could indeed learn from this thread.
I'll bring it up to the other moderators and to Giorgio as to whether the informational value justifies some kind of permanence or permanent link.

Cheers!

[Aspirant]

Giorgio,

First, I want to say thank you for having a fact-based technical dialog with me. I learned a lot, and it will be quite helpful to me in the future.

I have read opinions from many people (on several forums) who strongly recommend NoScript (with default-deny of JavaScript) over the years. But these same people have other serious security vulnerabilities, so I did not consider their recommendation well thought-out. I have experienced that a significant percentage of legitimate sites are only usable with JavaScript enabled. I realized that if I navigate to a site found on a search engine, which appears to be legitimate based on what I see with scripts blocked by NoScript, and I temporarily allow scripts to get the menus to work, then the site can attack my PC. Game over. This is why I put such effort into other forms of security.

You have helped me understand important vulnerabilities that are not addressed by any other security protection I have found so far. Your info helped motivate my wife and me to tolerate the inconvenience of default-deny for JavaScript. We have been using NoScript in this way for about a week, and we see little that could be improved in the way of usability. The years you spent incorporating user feedback and optimizing have certainly paid off.

Script blocking (which you turn off) prevents 3rd party scripts from being included in your whitelisted site if their origins are not whitelisted as well. This has nothing to do with Anti-XSS, but helps in most persistent XSS / SQL Injection scenarios, because using a remote inclusion is much more practical, and often the only feasible path for an attacker (e.g. if the injectable field has length constraints, see http://ha.ckers.org/blog/20080110/dimin ... st-wrapup/ ).

I didn't know this, even after reading all the NoScript FAQs, and I found it very helpful to understand why NoScript protection works. I still plan to close Firefox before and after going to financial web sites, but now I can see why NoScript's JavaScript default-deny helps protect me when a legitimate site is hacked. I believe it would be helpful to others to put the factual information from this thread into the NoScript FAQs.

Kind regards

Edit: spelling corrected