12 posts • joined Saturday 16th June 2007 08:22 GMT
Dan Goodin's uniqueness explained :)
I'm not sure why Dan Goodin reportedly had his browser identified as unique notwithstanding NoScript, but I suspect he's got "Globally allow mode" or he failed to correctly repeat the test...
NoScript does fight CSRF
A couple of things need to be clarified.
NoScript contains a module called ABE (Application Boundaries Enforcer) enabled by default, which is specifically designed to fight CSRF.
It's similar to a web-application firewall, but working on the client side.
Its built-in rules block all the CSRF attacks from the internet to your private network (such as those against your router or your intranet servers), but it can be configured either by the user, by the web site owners or by trusted organizations to prevent any kind of CSRF scenario.
More info here: http://noscript.net/abe
On the other hand, Mozilla's "Content Security Policy" proposal which the article talks about, while effective in the long term to help web authors at mitigating their XSS vulnerabilities, can't do anything about CSRF, because it's just out of its scope: https://wiki.mozilla.org/Security/CSP/Spec
Why NoScript block this.
NoScript blocks this even if your son wants to use Twitter and enables scripting on twitter.com and googleapis.com (where Twitter's "good" scripts come from).
This is because the malicious code comes from a different site (mikeyy.uuuq.com), which you've got no interest in allowing and is disabled by default.
NoScript's Anti-XSS protection, James
Please RTFM, before posting misinformed comments: http://noscript.net/features#xss
Disaster Recovery Advices For IIS Admins
you posted your link everywhere (included comments on my blog and on Brian Krebs'), but I couldn't find the "small tweak to remove the crap" you talk about.
On the other hand, I did publish an (untested) paraphrase of the original attack which should help in cleaning up your database (unless you've got a good backup, of course), together with other advices here:
Yes, NoScript is effective in this case too
in all these attacks the malicious scripts, even if embedded in "trusted" pages, are actually loaded from sites you're very unlikely to have ever heard of, hosted in obscure Chinese servers.
@Chris: NoScript doesn't require any user decision in this case
yes, it applies to SeaMonkey as well.
NoScript Protection Works Anyway
NoScript users are protected against exploitation of this bug anyway, no matter if the attacker site is on their trusted whitelist or not.
It should be noted that, while Microsoft denied this problem, Mozilla admitted its error, filed a bug ( https://bugzilla.mozilla.org/show_bug.cgi?id=389106 ) and already fixed it 2 days ago.
This means that already available Minefield builds and Firefox 184.108.40.206 release candidates are immune.
Furthermore, latest NoScript release ( http://noscript.net/getit#direct ) offers early protection against this exploit for those stuck with stable 220.127.116.11.
There's a browser safer than Firefox... http://noscript.net
Notice that Firefox users with the NoScript add-on installed have been already protected both from MacManus/Larholm remote code execution and from Rios "Universal XSS" since June, the 22th, see http://noscript.net/changelog#18.104.22.168.070622
Hence, these protective features are here to stay, since the upcoming Firefox 22.214.171.124 just fixes the "firefoxurl:"/command line case.
NoScript Screenshot :)
The IBM QuickSite hilarious flaw was already pictured 3 months ago in the screenshot at http://noscript.net/features#xss :)
- World's OLDEST human DNA found in leg bone – but that's not the only boning going on...
- Lightning strikes USB bosses: Next-gen jacks will be REVERSIBLE
- Pics Brit inventors' GRAVITY POWERED LIGHT ships out after just 1 year
- Microsoft teams up with Feds, Europol in ZeroAccess botnet zombie hunt
- Storagebod Oh no, RBS has gone titsup again... but is it JUST BAD LUCK?