How to reliably block embedded web content without making the blocker vulnerable??

Discussion in 'other software & services' started by Gullible Jones, Aug 4, 2014.

Thread Status:
Not open for further replies.
  1. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    Here is the problem:

    Whitelisting web content is a good way to prevent browser attacks. What your browser doesn't render can't hurt it, right?

    However, HTML is very complex and requires complex software to parse it. And complex parsing software tends to be vulnerable.

    Furthermore there are all kinds of ways to obfuscate HTML and embedded Javascript, which should make embedded script blockers even more complicated - they might have to parse malformed HTML correctly, on the off chance that the browser might too (and thereby allow an exploit). Kind of like how antivirus software puts itself at risk by parsing deliberately malformed data formats, so that some more naive application doesn't get there first.

    Now, take a look at a script blocker like NoScript. I will note that I rely heavily on this extension, and it has saved my bacon on several occasions. However, I cannot help but note that it is
    a) crammed with features for blocking different types of embedded content, including methods for distinguishing specific types of attacks like clickjacking
    b) very reliable about blocking embedded scripts
    c) composed of a couple megabytes worth of Javascript

    IOW it is a fairly complex piece of software itself. And while I (very thankfully!) don't see anyone targeting NoScript and other script blockers in the wild, I do wonder if all that Javascript is itself vulnerable. How much of embedded script blocking is security, and how much is obscurity? Am I misunderstanding something crucial about how embedded content blocking works?

    NB, I am interested in responses from people who actually write these tools. (gorhill? Georgio Maone?)

    Edit: whoops, two question marks there, yay.

    Anyway it just struck me that one could maybe reliably do per-domain blocking by looking at browser requests. (I think I saw something about this on the RequestPolicy bug tracker?) In fact that could be done with a firewall (such as iptables) with proper configuration. :) However it would not be able to block specific content per domain, only any and all requests to a domain not on the whitelist.

    IOW I think you could duplicate RequestPolicy behavior in a way that might be less exploitable, but not Noscript behavior.

    Edit 2: it also seems to me that this might be a good case for whitelisting JS by whole pages (in the fashion of Opera or Chrome), rather than domains (like Noscript). If you have JS whitelisting by page, without any discrimination between different origins, you don't need to do any HTML processing. It's less power, but it might also be less attack surface.

    (But again I'm very interested in feedback on this from people who actually develop blocker extensions.)
     
    Last edited: Aug 4, 2014
  2. MrBrian

    MrBrian Registered Member

    Joined:
    Feb 24, 2008
    Posts:
    6,032
    Location:
    USA
    NoScript v2.6.8.31 has two new user preferences
     
  3. oneeyed25

    oneeyed25 Registered Member

    Joined:
    Nov 26, 2013
    Posts:
    21
    Ermm...

    Not sure about Chrome, but I've created a script blocker on old Opera (presto) and the blocker doesn't parse anything.... It's the browser engine that does the job and the blocker access it via event listeners. Every time the browser processes an event (script, click, or whatever other DOM object you want), the blocker then enters in action, with the possibility to cancel the same event, thereby blocking scripts, image loading, etc...

    For example in opera :

    opera.addEventListener('BeforeScript', function(e) { e.preventDefault(); }, false);

    the event 'BeforeScript' is started everytime the browser encounters a script DOM element, but before actually processing it.
    preventDefault tells the engine to cancel the event, preventing even the downloading of external scripts.

    This simple line blocks all scripts from executing, and as you see there's absolutely no parsing involved.

    I guess NoScript is so heavy because of all the other features to prevent XSS, not because of script blocking which is rather easy and fast to implement.
     
    Last edited: Aug 5, 2014
  4. Gullible Jones

    Gullible Jones Registered Member

    Joined:
    May 16, 2013
    Posts:
    1,461
    So it's all done in the browser, and the blocker just uses the API? Thanks @oneeyed25, that makes more sense.
     
  5. tlu

    tlu Guest

    Perhaps this is helpful.
     
  6. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    8,038
    Location:
    The Netherlands
    If I may ask, can you perhaps tell which one you made for Opera? :)
     
  7. oneeyed25

    oneeyed25 Registered Member

    Joined:
    Nov 26, 2013
    Posts:
    21
    It's a User Javascript, not an extension. I found it best to do it that way to be able to still use the built in way of Opera to disable JS globally or locally (via manage site preferences).

    You can find it at : http://extendopera.org/userjs/content/external-script-blocker

    It's also available on openuserjs.org and greasefork.org and maybe others.
     
  8. Rasheed187

    Rasheed187 Registered Member

    Joined:
    Jul 10, 2004
    Posts:
    8,038
    Location:
    The Netherlands
Loading...
Thread Status:
Not open for further replies.