Since your hosts file takes precedence over your DNS in domain name resolution, you can redirect undesired domain to invalid IP addresses, saving both bandwidth and CPU because resolved IPs are cached.

Unluckily, most information sources about this useful technique, including the Wikipedia article above, instruct the reader to use 127.0.0.1 (the local loopback IP) as the dead-end destination, rather than a truly invalid address such as 255.255.255.0. This is not very smart, especially if you installed a web server on the loopback interface (like many web developers do), because you’re spamming it with dummy requests whenever you browse an ad-laden web site.

Furthermore, I’m currently receiving several reports about ABE warnings popping up everywhere. If you read my post about ABE yesterday, you know that it ships with a built in “SYSTEM” ruleset containing just one rule which alone implements the whole LocalRodeo functionality:

# Prevent Internet sites from requesting LAN resources.
Site LOCAL
Accept from LOCAL
Deny

Such a rule blocks any HTTP request for resources placed in your local network, including localhost (127.0.0.1) and any other LAN IP, unless it is originated from your local network as well. This protects your internal servers and devices (e.g. routers and firewalls exposing web interfaces) against CSRF and XSS attacks performed from the internet.

As a side effect, though, if you’re redirecting arbitrary hosts to 127.0.0.1, you’ll get bombed by a storm of ABE warnings whenever those sites are linked from external web sites. The solution is simple: just open your host file and replace 127.0.0.1 with 255.255.255.0 everywhere it’s used to block something, but being careful to keep 127.0.0.1 on the localhost entry and other really local domains, if any.

It’s been quite a long development journey since my first announcement, made possible by NLNet’s foresight, and it required more than one month of beta testing: among the thousands of testers victims I inflicted twenty builds upon, I must especially thank therube, GµårÐïåñ, Tom T., Alan Baxter, dhown and the other friends at the NoScript forum, who devoted their time to aid debugging and optimization. A special thanks goes also to Edoardo “Sirdarckcat” Vela, talented hacker and loyal NoScript fan, who offered many useful suggestions to model the threats which ABE can counter react.

Great but.. now that I’ve got ABE, what can it do for me?

If you’ve got latest NoScript version installed on Firefox 3.0.11 or another compatible Gecko >= 1.9 browser, you’ll notice a new “ABE” tab in NoScript Options|Advanced. There you can find a list of the loaded “Rulesets”, i.e. groups of firewall-like rules (syntax specification PDF).
Rulesets can be:

1. Built-in like the “SYSTEM” ruleset, shipping with ABE and meant to provide automatic protection against “general” threats; you don’t want to edit them unless you know exactly what you’re doing.
2. User-defined like the “USER” ruleset, which is empty for you to customize according to your needs.
3. Subscription-provided, coming from a centralized location which delivers “trusted” rules (not supported yet).
4. Site-specific, created and made automatically available by site developers or administrators to protect their own web applications.

All these rulesets (built-in, yours, centralized and site-specific) cooperate to properly insulate your most sensitive web applications and prevent them from being abused by unrelated malicious web sites.

Drop-in LocalRodeo replacement

The “SYSTEM” built-in ruleset currently contains just one rule definition:

Site LOCAL
Accept from LOCAL
Deny

This simple rule protects your local network from CSRF attacks coming from outside, for instance from a malicious web page trying to hack your router. If this scenario does not sound new to you, maybe you’ve heard of LocalRodeo, an experimental Firefox extension which was meant to defeat exactly this kind of internet-to-intranet threats. In facts, the default ABE configuration shipping with NoScript 1.9.5 and above is as effective as LocalRodeo at least, but more performant, especially when DNS queries are involved, and much more flexible, since it’s not limited to this specific attack scenario: if you’re using both NoScript and LocalRodeo, it’s time to uninstall the latter.

ABE for web authors

While centralized subscriptions aimed to protect the most popular web applications have been planned but are not implemented yet, you as a web author can already start experimenting how to protect your own web application by enforcing your own rules.
Just deploy your rules.abe file at the root of your HTTPS site and be sure to check Allow sites to push their own rules in the ABE options panel. This preference is initially disabled in 1.9.5, but this default will be likely inverted in next stable iteration, as soon as it gets enough testing.
More details here.

Here’s the Slashdot’s routine Apple+Java bashing with linked source articles.

At this moment, the easiest way to protect your Mac web browser is either turning off Java globally or… you know what ;)

Update Jun 15th

Three weeks later, Apple finally patched..

One of the limitations was their ability to mitigate a subset of reflective (AKA type 1) XSS vulnerabilities only, leaving them totally useless against DOM-based (AKA type 0) XSS attacks which, instead, are effectively defeated by NoScript.

Today I noticed via sla.ckers.org that such a DOM-based XSS attack is currently possible against Paypal and Ebay, no less, allowing the attacker to steal authentication info and other sensitive data, or even perform financial transactions on the behalf of the victim.

Even more interesting, modern browsers* except IE properly encode request URLs before sending them on the wire, but exploitation of this specific Paypal vulnerability requires the “double quotes” character to pass through with no encoding: therefore, while the vast majority of XSS exploits are cross-browser, this one affects exclusively IE**. Embrace and XSStend?

1. * Latest versions of Firefox, Safari, Opera and Chrome.
2. ** Variants could affect any browser, since IE’s encoding bug is generally not required for DOM-based XSS. Firefox users can protect themselves by using NoScript, even in the permissive and not recommended “Allow Scripts Globally” mode.

To accomplish this goal, NoScript persists all its preferences, whitelist and blacklist included, in a special bookmark every time they change. Then starts watching for external modifications of this bookmark, and if it detects any, loads the new configuration.

Therefore you can use any bookmark synchronization system (such as Mozilla Weave or XMarks, the two currently tested) to share your NoScript configuration changes with as many Internet-connected browser profiles as you need.

The implementation is quite simple, thanks to the Places API, but this means that it requires Firefox 3 or better.

How can you start?

• On your “master” workstation:

  1. Install NoScript 1.9.2.8 or above.
  2. Install Mozilla Weave or the XMarks extension and configure a bookmark synchronization profile. Notice that both these systems allow you to host your data on a server of your own, even though Weave offers encryption both for transport and storage.
  3. Open the NoScript Options dialog and tick the General|Backup NoScript configuration in a bookmark for easy synchronization checkbox, then click “OK”. A new bookmark folder named [NoScript] should have been created inside your Bookmarks menu.
  4. Right click the XMarks or Weave icon and select Sync now.

• On each “slave” workstation:

  1. Install NoScript 1.9.2.8 or above.
  2. Install Weave or XMarks and configure the same synchronization profile you created on your “master” workstation.
  3. Right click the Weave or XMark icon and select Sync Now.
  4. As soon as the synchronization completes, open NoScript Options and tick the General|Backup NoScript configuration in a bookmark for easy synchronization checkbox, then click “OK”.
  5. A confirmation prompt will ask you if you really want to overwrite your configuration with the content of the synchronized bookmark. Answer “OK”.

Now “master” and “slave(s)” share an identical NoScript configuration. From now on, every time you change any preference or permission, the special bookmark will be updated and can be synchronized by Weave or XMark, either manually or automatically, e.g. when you start or exit the browser, transparently and with no more confirmations.

If you find any bug, need support or have suggestions to improve this feature, you can join the discussion here.

startpanic.com

Mozilla is already working on this, but please do not comment on the bug report, already too much noise there…

I did something extremely wrong, which I will regret forever.
I abused the power and wasted the enormous trust capital gained by the NoScript add-on through the years to prevent Adblock Plus from blocking stuff on four internet domains of mine, without asking an explicit preemptive user consent.

This is absolutely inexcusable. Something I would never conceive again for the life of me.

Please let me apologize first, then briefly explain what happened from a slightly different point of view than Wladimir Palant’s, then apologize again.

You may ask why it took me so long to post something about the infamous Adblock Plus whitelisting incident here.
I’ve been quite busy all Friday night up to 11 AM of Saturday, apologizing with NoScript users one by one through facts, by hurrying out the 1.9.2.6 update which automatically removes any Adblock Plus related configuration with no questions asked. Then, after a couple hours of sleeping, I tried to answer some questions left open in the public forum thread where discussion about my admittedly stealthy and borderline reaction to EasyList’s attack on my web sites had been politely going on and leading to an acceptable solution, before Wladimir decided to invite Reddit, Slashdot and Digg to the party. Furthermore I’m still coping with a huge backlog of email messages: I’ve never left a NoScript-related email unanswered, and the fact some are (legitimately) less kind than usual now is not a good reason to give up.

Preamble

The development of NoScript is sustained both by donations and advertisements published on a few related web sites in four domains (noscript.net, flashgot.net, informaction.com and hackademix.net). I’ve never tried to hide the latter revenue stream, as you can see in this very old FAQ about NoScript’s default whitelist, which Wladimir loves to rehash every time he has a chance to depict me as a hypocrite driven by greed. What I really think is that while ads are important to support NoScript development, users’ ability to block anything displeasing them is much more important. Deciding what is their prerogative.

Adblock Plus is meant to block ads, but it doesn’t block anything by default. In facts, according to its own author, it’s meant to block obnoxious ads, implying it’s up to users to choose which ads are acceptable and which deserve to be annihilated. I couldn’t agree more with this “user choice is the king” principle, even though I recently abdicated to it myself by doing the odious thing we’re talking about here.

When users install Adblock Plus, though, they are encouraged at subscribing so called filtersets, which choose for them what’s good and what’s bad. EasyList is the most popular of these filterset subscriptions. When something is blocked by a filterset like EasyList, stuff just disappears from the page without notice. There’s a “blockable items panel” you can open to check what’s going on, but you never get any notification. This is still good as long as either what disappears has been a choice of yours, or the filter subscription did a perfect job guessing what can interest you and what cannot. Otherwise you don’t even get to know something is missing and why.

For some time my sites used a publicly known Adblock Plus bug to work-around EasyList’s generic filters against Adsense and display their Google Ads boxes, even though Adblock Plus users could still easily block them if they wished to by adding their own custom filter. Furthermore, NoScript users could even more easily remove those ads all at once by just forbidding googlesyndication.com. In other words, this “trick”, as Wladimir calls it, put the choice back in users’ hands.

About 2 weeks ago Wladimir decided this had been going on long enough: the Google boxes supporting NoScript had to be shut down for good. So, rather than fixing his Adblock Plus bug, he asked Ares2 (the new Easylist maintainer, after Rick752 passed away) to nuke them by specifically targeting NoScript sites. When I noticed this, I thought it was Ares2’s own initiative (new person, new mentality), but Wladimir finally clarified this point in his Friday’s post:

I suggested that EasyList should be extended by a filter to block ads specifically on NoScript’s domains. This finally happened two weeks ago.

All this time I couldn’t imagine that he had been behind Ares2 from the start, otherwise I would have just asked Wladimir why he was sniping my sites, rather than coding a more reliable Adblock Plus version. Instead I began tracking EasyList changes and counterreacting. Of course Ares2 didn’t stop, nor I did, so we engaged in an escalation through more than 30 EasyList updates (even 4-5 per day) specifically aimed at my sites, with filters like these (yes, stacked all together):

/flashgot.net/*$script,subdocument,xmlhttprequest
/hackademix.net/*$script
/noscript.net/*$script,subdocument,xmlhttprequest
/oss.informaction.com/*
informaction.com/*$script,subdocument,xmlhttprequest,domain=flashgot.net|noscript.net|software.informaction.com
flashgot.net#*(href*=informaction)(href*=com)(href*=%62)
flashgot.net#*(href*=informaction)(href*=com)(href*=flashgot)
flashgot.net#*(href*=oss)(href*=informaction)(href*=com)
flashgot.net#ul(class=tla)
noscript.net#*(href*=informaction)(href*=com)(href*=%62)
noscript.net#*(href*=informaction)(href*=com)(href*=noscript)
noscript.net#*(href*=oss)(href*=informaction)(href*=com)

If you’ve got some familiarity with Adblock Plus filters, you’ll notice any standard web technology beyond basic HTML/CSS (scripting, frames, AJAX) was completely disabled.
They got to the point where users could no longer even see the regular links to install NoScript or FlashGot.

Crossing the Dirty Line

As you can imagine I was quite pissed off then. Blocking my ads was one thing (it’s EasyList’s job, after all — I was just surprised of being so popular to deserve such a dedicated treatment), but disabling any dynamic feature and destroying essential site functionality such as install and development build links was a different story.

Mind you, I’m not trying to justify my actions here. They are unjustifiable, and anger is hardly a justification for anything, but since I’ve been accused of having acted out of pure greed I need to clarify that it was not my prevalent feeling at all, even though I won’t hide that EasyList’s crusade had actually cut the NoScript development funding by a substantial amount.

So I had this crazy idea of retaliating against EasyList “from the inside”, and in my blindness I did not grasp that I was really retaliating against my own users and the Mozilla community at large. Even worse, my hacker attitude led me to dig directly in the low level Adblock Plus internals where filters are enforced, assuming there was no “interesting” API to hook (more on this later). Therefore, while I was about to release a long awaited feature (bookmark-based synchronization), I took 10 minutes to add a small piece of code (mrd.js) which implemented my own “hand made” whitelist, working around those filters targeted to my sites but leaving the Adblock Plus functionality otherwise intact.

I included also an about:config preference (noscript.mrd) to deactivate this “feature”: it was meant for an user interface to follow up, but I’ve been foolish enough to defer its implementation and perform a stealthy “test drive” instead, while trying to figure out the best way to go public afterward.

When I pushed the “release” button, my soul was already damned.

Digression 1: AMO

Some of the thousands who commented on this issue so far argued that AMO should have reviewed the code or at least test the package before releasing it to the public. This did not happen, and I want to clarify it’s not AMO’s fault. Nobody from AMO even saw the release passing by, because the extension was considered “trusted”, i.e. not needing any approval for exiting the so called “Sandbox”.

This kind of “trust” is not related to malware, but to quality assurance: if an extension demonstrates to be tested enough (e.g. because it has already many beta testers) it gets approved automatically, alleviating AMO editors’ huge workload. Either way, with my insanity I betrayed this “trust” as well and put AMO in an awkward position.

I apologize with to the AMO staff people, whose hard and continuous work constantly improves the Mozilla ecosystem, and with all the other add-on developers: now I realize that the general security of the Mozilla extensibility system is being questioned because of this incident. Believe me: I didn’t even considered such a fallout as a remote risk. I’ve been too much enraged and stupid to think about all these consequences. Please forgive me.

Digression 2: Obfuscated(!)

Wladimir wrote:

When I investigated this issue I couldn’t believe my eyes. NoScript was extended by a piece of obfuscated (!) code to specifically target Adblock Plus and disable parts of its functionality.

There are several parts of his post and comments who would need an accurate rebuttal, either because overstretched, subtly smearing, spreading FUD or just plainly false. But this post is about my sins, repent and begging forgiveness, so that will have to wait.

However the “obfuscation” argument deserves to be treated right now, because it’s very pertinent to the facts we’re discussing here and hinting about the real nature and extent of my intentions (while no way this is meant to mitigate the judgment on my actions). I already answered in the forum to direct questions about this so called obfuscation, but let me summarize here.

While writing readable code may not be my primary skill, the code Wladimir analyzed was hardly obfuscated, not at least in the traditional computer-related meaning of “making it unreadable to fellow coders”: in facts it’s even nicely indented, and identifiers (function and variable names) are concise but yet meaningful enough. Some data had been actually made harder to read (i.e. ABP’s id and the CSS rules template for element unhiding) even though by a very simple and recognizable method (unicode hex encoding), not to target code reviewers (who would understand it at first spot, like Wladimir did) or users (who would not read it anyway): the quite self-evident recipients of this “obfuscation” were EasyList maintainers and Ares2 specifically. My (ingenuous and stupid) intent was checking how the system worked “live” but far from his eyes, and in the meanwhile searching for the best way to turn it into a public “feature”, e.g. by building an user interface around the noscript.mrd preference.

NoScript’s Black Friday

The rest of this story is quite well known and documented: while I was on a disconnected weekend trip, I took some time looking more broadly at Adblock Plus code, and I slapped my head when I found a public API meant to allow just that after all: adding external filtersets from another extension (it was meant for Filterset.G, apparently) and making them visible and easily manageable from Adblock Plus’ own user interface. So when Wladimir contacted me with a friendly mail about my alleged malware, I offered using that API as a quick solution. He answered that it was OK by principle, but since NoScript was a security add-on users should have been asked and a prominent disclaimer about this “feature” be added on the AMO description. Since I had no problem with giving users all the information in the open, included detailed removal instructions (two clicks), but was concerned about the annoyance of a blocking nag box on startup, I replied

I’ll inform users about the added whitelist filter both in the AMO description and on the landing release notes page [automatically shown after updates], where I’ll provide them also with instructions to remove it.

He did not answer anymore, so I assumed he had no objections. And this was my second big mistake.

This “open” approach went in a beta (1.9.2.3) and then in a stable release (1.9.2.4). But almost immediately after releasing it, I realized that this was not enough and expressed my intention to add to NoScript an explicit startup prompt asking once forever if user wanted to keep/install or permanently remove (also retroactively) the filterlist. This was announced on friday morning (Italy time), and was planned to be done in 24-36 hours (on Saturday), but unfortunately 10 hours later was already too late. The email from an AMO representative, suggesting to add an opt-in dialog in the next version, found me (at 3 AM local time) already working like a night owl to hurry out NoScript 1.9.2.5 which implemented it retroactively (more than what AMO was actually asking for). At 7.05 AM I finally announced to him 1.9.2.5 was in the AMO Sandbox, waiting for approval. Unfortunately in the meantime too much stuff had already hit the proverbial fan, so he informed me that adding the opt-in dialog was not enough anymore (something I had been realizing myself while I was coding and my inbox kept growing with a bad smell):

We’ve given this some thought and came up with the following policy after internal discussion as well as discussion with the community:

http://blog.mozilla.com/addons/2009/05/01/no-surprises/

From what we understand of your filterset install, your filter change is unrelated to the functionality of your add-on and will be rejected. I’m asking you to remove this functionality and retain the retroactive box. You can include a link to the filterset on your first run page but as far as in-extension functionality, we won’t allow this on AMO. Please let me know your thoughts.

At that point my answer was immediate and almost relieved, because 1.9.2.5 was already available on my site, but 1.9.2.6 (with much more drastic cleanup measures) was already in my mind as the most honorable offer to make my users as a sign of repent:

I’m OK with removing the functionality.
If you don’t mind, could you explain what exactly you mean by “retaining the retroactive box”? Could I just delete the filterset on startup, or I need to do something else?
Sorry to waste your time, but I’d want to be sure before creating other useless code at 7:34 AM after having spent all the night on this issue (for my fault, of course).

Many thanks!

After receiving an enthusiastic OK on this resolution, I wrote the apology that every NoScript user (even those who didn’t know about all this mess yet and/or had no Adblock Plus installed) was meant to read on automatic update page, dared a (painful) look at Slashdot, Reddit, Digg, NoScript’s AMO page and my own forums, had a much needed shower, kissed my spouse and my child and finally headed to bed (about at 11AM) to sleep a couple of hours.

Saturday Night Fever

When I woke up, the sky was still falling (especially on AMO, where NoScript had received more ratings than in 4 full years of life). But I also noticed some unexpectedly encouraging email was coming in and, incredibly, donations were skyrocketing. Maybe the sincerity of my sorrow for this incident was arriving to someone. So I started multitasking between the forum and this very writing, and here we are.

Obviously there are still many things to do, but I desperately hope abandoning NoScript development is not among them.
One is this blog post, which I should finally be able to publish in minutes.
Another is setting up a publicly accessible code repository for my extensions, something I procrastinated too long but suddenly became a top openness priority.
Other ways to try regaining NoScript’s user base’s trust will probably come to my mind later, and any suggestion is welcome.

But back to the main topic of this post.
I beg you to accept my most sincere apologies and believe in my shame and contrition.
I know I’ve done something horrible, creating a scandal like the Mozilla community never had faced before and betraying the trust of many, many people.
Please help me to repair the damage I’ve caused with my errors.

This plague is the brainchild of a 17 years old named Mikeyy, who created it as a publicity stunt to promote his own Twitter clone, StalkDaily.com. A good technical description of its rather simple inner workings has been kindly provided by Damon Cortesi. As you can see, unless the mikeyylolz.uuuq.com doman is allowed to run JavaScript (very unlikely for NoScript users) you’re immune from infection.

This worm having been active so long is quite a surprise to me, since the exploited vulnerability (missing output encoding on users’ profile web page URL) requires less than one minute to be fixed, if you know what you’re doing. The existence of a mildly obfuscated version authorizes a scary suspect: have Twitter guys just been trying to block the original strain by signature, rather than fixing their website error? This is would be ridiculous*, since any script kiddie can create his own slightly modified version for fun or profit (and is probably doing that). And while the initial code just logs your session cookie on a remote server (which is already bad enough) and replicates itself as spam, nothing restrains a more malicious attacker from taking over your account with all its profile data right away.

The morale of this story? Never tweet without NoScript.

* Update

Ridicolous, but apparently true: in Twitter’s first hand account of the countermeasures taken over the weekend, there’s a lot of “cleaning up and locking down profiles”, but nothing about fixing the website’s bugs which allow infections like this to be spread.

The general mood does not sound defamatory, but the online audio quality is not gentle enough to my untrained Italian ears :P
Would any English native speaker (better if of pure British lineage) be so kind to contribute a transcription? Many thanks!!!
Long time noscripter therube, less lazy than me, found BBC’s own official transcription:

NoScript

noscript.net

Browser plug-ins like Java, Flash and Silverlight offer functionality, compatibility, and a load of other bells and whistles we have come to expect from our web browsing experience nowadays. But they have their downsides too.

You’ll no doubt have heard talk about malicious code embedded in certain plug-ins, so if you want to be sure of being totally safe online, this nice little plug-in I found for Mozilla-based browsers should help you sleep better at night. It physically blocks any codes from running unless you give your express permission to do so.

It can also be handy if you’re running on a slow connection and don’t want loads of movies and animations trying to launch into the page you’re accessing. Equally, many marketing organisations will run applets in the background that tell them when you’re using their site, and how.

Download and install take literally seconds and then you’ll see a noscript icon in the bottom right hand corner of your browser window. Each time you visit a new web page, if it tries to load any scripts the applet will block these and alert you. Clicking the noscript icon now will allow you to block or allow certain scripts on the page. Individual panels in the web page which are blocked can also be right clicked to allow you to set the permissions for that particular script.