:::Innovative Security Insights:::

Javascript Blocker ‘NoScript’ may give you a false sense of security with default settings

The purpose of Javascript blockers such as “NoScript” for Firefox help to block javascript from running on untrusted sites. Using these add-ons give us a sense of comfort as we may assume that even if content from a domain serves us an intrusive or malicious javascript payload, we are protected (through the browser filtering out the untrusted domain’s Javascript calls).

However, with the default settings of “NoScript”, attackers can make use of trusted domains to host and deliver their javascript. Some examples where this is possible are for sites that allow the uploading of files or custom content. This includes sites storage, blogs, hosting and repository sites. i.e. Dropbox, WordPress, blogspot, etc.

Proof of Concept (POC)

For this article, I will be using DropBox, a popular file storage site, as an example.

Here, an untrusted domain attacker.com serving a javascript from DropBox. In this scenario, the user is a dropbox account user, and thus, has trusted dropbox.com.

Protective Measures (Edit)

[Thanks to Gorgio for highlighting this]

To prevent against such implementations of iframes, you may change the default settings under “NoScript Options|Embedded” and check the relevant “Forbid …” options.

If you have any insights into this, your findings and views are greatly welcome! 🙂

—————————————————————————————————————————————-
Note: The vulnerability and the versions of firefox and NoScript used are the most updated as of the time of this article (25/02/2012). 
—————————————————————————————————————————————–

Advertisements

2 responses

  1. Sorry, there’s no “vulnerability” here at work, just a limitation of Chrome’s script blocker which is unable to handle nested frames permissions independently from the top window.

    What’s the difference between opening attacker.com which frames the page at dropbox.com (trusted) and opening the page at dropbox.com directly? Actualy, the latter is easier than the former: hence there’s no attack surface extension in allowing scripts on *trusted* subframes.

    Anyway, if you’re concerned about iframes and frames, you can just open NoScript Options|Embedded and check the relevant “Forbid …” options.

    March 2, 2012 at 11:45 am

    • Hi Giorgio,

      Thanks for highlighting that. I was not aware of that setting in NoScript. I will update accordingly!

      Cheers!

      March 2, 2012 at 1:58 pm

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s