Archive for the Security Category

Am I alone in fearing that lust for shrinking down the browser will get us in more troubles like this (or just make plain old-school phishing more effective)?

NSA endorses NoScript
Some weeks ago I read on Forbes’ technology blog that

Access Now, a non-profit that’s focused on digital civil liberties in the Middle East, has published a concise guide to staying safe online, aimed at “citizens in the Middle East, North Africa, and beyond.”
Aside from the usual advice about running antivirus, using strong passwords, and staying wary of USB drives, it delves into a few less obvious practices:

  • Run the NoScript plug-in for Firefox, which can block scripts on Web pages that you don’t authorize.

I don’t know if this puts me in any middle-eastern dictator’s blacklist, but it seems “internet security guides” with various political spins are flourishing, and they obviously share most of their endorsements, no matter the ideology.

USA’s National Security Agency (NSA) is doing its part as well, as I found out yesterday: look at page 7 (“Enhanced Protection Recommendations”) of this Best Practices for Keeping Your Home Network Secure PDF…

Amazing coincidence, just a few hours earlier my own NSA project had exited “stealth mode” to official become NoScript 3.0a1 for Firefox Mobile.
Adventurous Android Alpha (AAA) testers are welcome :)

It’s getting boring.

Current Flash Player version ( for the general public, for Chrome users) is affected by a remote code execution vulnerability which is reported as being exploited in the wild.

Since Adobe Reader X (the newest version with “protected” mode) is vulnerable but not exploitable, Adobe doesn’t plan an out-of-band patch: looks like browser users are second-class citizens.

As usual, you can outright disable the Flash plugin or use NoScript’s active content blocking (not FlashBlock, please).


Nir Goldhsanger asked me to share with my audience a nice privilege escalation through parameter pollution he found, allowing the attacker to become administrator of any Blogger blog, which he dutifully reported to Google and deserved him the famous $1337 bug bounty.

I’m quite impressed by the first step of the attack, where the application gets fouled by a double “blogID” parameter: the first gets validated (it actually refers to a blog owned by the attacker) but then the second is actually used to perform the “add authors” action. Looking at the URL, it would seem they use Struts or some other Java-based framework. Since I’m quite rusty with them (these days I mainly use PHP and Ruby on the server side), would anyone attempt a reverse engineering and explain which kind of code could get messed by this? Did they maybe parse their parameters twice, with two different parsers?!

As you probably know, ClearClick is the only effective client-side protection against Clickjacking (AKA UI Redressing).

A couple of weeks ago, Atul Agarwal of Secfence privately reported me a ClearClick bypass based on tracking user’s mouse movements and dynamically putting an extremely small click target just under his pointer. Even though it required the attacker’s page to be whitelisted and run JavaScript, I deemed this bug deserved to be fixed ASAP because ClearClick, like most web application security countermeasures offered by NoScript (e.g. anti-XSS, ABE or HTTPS enforcement) is guaranteed to work independently from script permissions, i.e. even if you allow scripts globally. Atul kindly accepted to coordinate the disclosure, so I immediately released the development build with the bug fix, and all the user base was automatically updated with the stable release about one week later.

BTW, looks like Sophos likes ClearClick and dirty female teachers very much :)

Bad Behavior has blocked 2731 access attempts in the last 7 days.