Posts by Giorgio Maone

Most browsers leave fingerprint that can ID users

Dan Goodin's uniqueness explained :)

Later I had some conversation with Dan, and we discovered that the culprit of his un-anonymity was a pretty unique HTTP header he was sending by accident, due to uncommon configuration bits of his. In fact, once you shut down JavaScript and plugins, the stuff giving your identity away (aside your IP) is almost all at the HTTP level, especially cookies, user agent string (double check that it's the default one coming with your vanilla browser - the Microsoft .NET Framework and other 3rd party software love to "customize" it making you more identifiable) and language information.

NoScript blocks both Java and JavaScript

And, in fact, NoScript disabling JavaScript, Java and plugins by default makes identification about 40 times harder on my Firefox (1/19000).

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...

cPanel, Netgear and Linksys susceptible to nasty attack

NoScript does fight CSRF

A couple of things need to be clarified.

1.

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

2.

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

Twitter overrun by weekend of powerful worm attacks

Why NoScript block this.

@Anonymous Coward:

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.

Facebook ignores huge security hole for four months

NoScript's Anti-XSS protection, James

@James Roper:

Please RTFM, before posting misinformed comments: http://noscript.net/features#xss

Department of Homeland Security website hacked!

Disaster Recovery Advices For IIS Admins

@OffBeatMammal:

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:

http://hackademix.net/2008/04/26/mass-attack-faq/#iis

Mass compromise powers massive drive-by download attack

Yes, NoScript is effective in this case too

@Tony W:

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.

When you allow the "trusted" page to execute JavaScript, NoScript still prevents 3rd party scripts from loading unless you explicitly allow them too one site by one: hence yes, NoScript is an effective protection in this case as well.

Mozilla security chief confirms data leakage bug in Firefox

@Chris: NoScript doesn't require any user decision in this case

If you read my first comment, you'd know this specific chrome script protection is independent from your whitelist, i.e. it applies to every site no matter if JavaScript is enabled or not (opposite to what Dan's article suggests).

@DJGM:

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.

See

http://hackademix.net/2008/01/23/old-noscript-tricks-blocking-new-vulnerabilities/

for details.

Mozilla confirms own URL handling bug

Already fixed

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 2.0.0.6 release candidates are immune.

Furthermore, latest NoScript release ( http://noscript.net/getit#direct ) offers early protection against this exploit for those stuck with stable 2.0.0.5.

--

There's a browser safer than Firefox... http://noscript.net

A serious browser vulnerability, but whose?

NoScript

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#1.1.4.9.070622

More in general, they're protected from chrome privilege escalation gained by opening non-chrome URLs in top-level chrome windows (Larholm's PoC) and from javascript: URLs being loaded in externally opened browser shells (Rios' "Universal XSS" PoC), no matter if attempted through the "firefoxurl:" handler (like in this specific case) or by other yet unknown means.

Hence, these protective features are here to stay, since the upcoming Firefox 2.0.0.5 just fixes the "firefoxurl:"/command line case.

Yahoo! fixes bug that gave free rein to user accounts

NoScript Screenshot :)

The IBM QuickSite hilarious flaw was already pictured 3 months ago in the screenshot at http://noscript.net/features#xss :)