You're missing two different protections.Aspirant wrote: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)?
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/ ).
As I said, whitelisting has nothing to do with anti-XSS.Aspirant wrote: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.
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.Aspirant wrote: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.
LOL, do you really mean your bookmarks and preference are not persisted across browser restarts?Aspirant wrote: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.
And are your important documents on a different account?Aspirant wrote:I always run Firefox from a limited user account (LUA).
As I hoped to have clearly explained in my previous post, it can (incomplete list):Aspirant wrote:What evil can a JavaScript do (leveraging a Firefox privilege escalation vulnerability) on an LUA given the Defense+ access rights restrictions I mentioned above?
- Sniff the details of any financial transactions of yours and log them on a remote server
- Surely read your browser history, preferences and bookmarks, and log them on a remote server
- Almost surely write and be persisted in your browser profile (otherwise most of your browser functionalities, including bookmarks and preferences, would't work)
- 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
- Use your browser as a spam bot, as a click fraud bot, or both
- ... the sky is the limit