Script Defender for Chrome

Discussion in 'other software & services' started by ichito, Oct 31, 2013.

Thread Status:
Not open for further replies.
  1. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
  2. CoolWebSearch

    CoolWebSearch Registered Member

    Joined:
    Sep 30, 2007
    Posts:
    1,247
    I have read what you and moontan have to say about Script Defender and I have decided to install and use Script Defender for my Google Chrome.
    Big thanks to both for your advices.
     
  3. tlu

    tlu Guest

    No. First of all, Chrome has a built-in XSS filter called XSSAuditor on which the planned Firefox XSS filter is actually based. If it is better or worse than the XSS filter of Noscript - who knows?

    And there is Content Security Policy (CSP) mentioned by Windows_Security (and originally developed by Mozilla). It improves the security of websites if they add a Content-Security-Policy HTTP header:

    This mitigates XSS threats considerably - if properly implemented by the website programmers.

    I think all modern browsers support CSP now. But again, the crucial thing is that website authors have to take action.
     
    Last edited by a moderator: Nov 6, 2013
  4. wat0114

    wat0114 Registered Member

    Joined:
    Aug 5, 2012
    Posts:
    4,063
    Location:
    Canada
    You're welcome and I hope it works out for you :)

    Please do realize, however, it is definitely not on the same level as NoScript, particularly in terms of user friendliness and functionaility. However, I have yet to notice it failing to block unauthorized scripts, so it seems to be doing its job well in that very important category.


    You mention giant lists, well I just checked my most up-to-date NoScript list and it's 81 kb in size, compared to Script Defenders list at only 14 kb. Admittedly the SD list is not as complete as NS', but it's definitely not 60+ kb in size behind.
     
  5. tlu

    tlu Guest

    Sure, but if all rules are saved in ScriptDefender (even for sites you open just once in your life) the list will grow and will get confusing - and lots of entries will be irrelevant. In Noscript or ScriptBlock I whitelist many sites only temporarily if I'm sure that I won't need them again. Thus, the list remains rather short.
     
  6. tlu

    tlu Guest

    Yes, I agree. I would say, ScriptDefender is more reliable and ScriptBlock is more usable (because of temporary rules and editable lists) right now. Hopefully ScriptDefender will improve further.
     
  7. moontan

    moontan Registered Member

    Joined:
    Sep 11, 2010
    Posts:
    3,931
    Location:
    Québec
    i like NoScript better but Script Defender does the job quite nicely for a new addon.

    if Firefox had a native sandbox i would use Firefox with NS.
    the next best thing is Chrome with a quite decent javascript blocker like SD.

    finally, i can have my cake and eat it too. :p

    hopefully, the developer of SD will continue to support and improve it.
     
  8. wat0114

    wat0114 Registered Member

    Joined:
    Aug 5, 2012
    Posts:
    4,063
    Location:
    Canada
    I'm revisiting Scriptblock and it seems pretty good, nice features that you mentioned, but one thing annoying is that it reloads the page on every single script change I make even though I have the "reload tabs when permissions change" Off! That said, it's a nice effort for sure. Thanks for mentioning it :)

    *EDIT*

    never mind, just noticed the checkbox "multi-select sites" :D :oops:

    Absolutely, and so far it's off to a nice start :)
     
  9. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    Right now this provides a nice way to manage a Javascript whitelist, but does it really matter? The nice thing about NoScript is the XSS and CSRF. On Chrome the Javascript renderer is so heavily sandboxed it really isn't important to limit Javascript on a page at all.

    If NoScript existed for Chrome I'd use it and whitelist by the top level domain, and I'd focus much more on the XSS/CSRF protections.

    As it stands, I don't see much reason to block Javascript on Chrome, at least not on Linux. Too much pain for too little reward.
     
  10. moontan

    moontan Registered Member

    Joined:
    Sep 11, 2010
    Posts:
    3,931
    Location:
    Québec
    i like that the pages load a load faster when you cut down on the bandwidth-gobbling sludge. ;)
     
  11. wat0114

    wat0114 Registered Member

    Joined:
    Aug 5, 2012
    Posts:
    4,063
    Location:
    Canada
    No doubt good points for sure HM, though what about Windows users visiting a compromised site with malicious js that downloads (drive by) a trojan such as the latest Cryptolocker. Does this script control not help much with Chrome? I realize other protection mechanisims in place such as anti-execs and lua will help immensely, but at least the trojan doesn't even "set foot" on the potential victim's machine, correct? Or would it be fully contained in Chrome's sandbox?
     
  12. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    If we're talking about a Trojan then we're talking about social engineering, so this won't help (it involves getting a user to download and install the program).

    If we're talking about an exploit, it'll be trapped in the sandbox. Now, on Windows, if it's a very advanced attack, it could break out of the sandbox. That is an unreasonable goal on a hardened Linux system though, attacking Chrome is just too expensive on a properly hardened Linux.

    On Windows you may want to use JavaScript controls like this, but attacks are still not easy on Chrome, especially when it comes to getting out of the Javascript renderer sandbox.

    It's not a bad thing to run it (though, of course, you have to consider that it is additional attack surface) but it may not be worth the pain.
     
  13. Daveski17

    Daveski17 Registered Member

    Joined:
    Nov 11, 2008
    Posts:
    10,239
    Location:
    Lloegyr
    Is this strictly true in all cases though? I was under the impression that a trojan could be contracted through running flash that had been infected (buffer overflow?). This could be anything from a running a compromised video to an animated flash advert.
     
  14. wat0114

    wat0114 Registered Member

    Joined:
    Aug 5, 2012
    Posts:
    4,063
    Location:
    Canada
    Thanks. I guess I was thinking about a compromised website where an attacker discovers a weakness in the server's improperly sanitizing requests, so the attacker injects a malicious script which upon the victim visiting the page triggers it, which in turn downloads and attempts to install a trojan - iow a drive-by download. It seems pretty advanced, but isn't this more or less, in my very simplistic description, how they work? You mention TLD's, but as far as I know these aren't the problems; it's the potentially malicious sub-scripts that could be the problem, so I figure the scripting control even with Chrome on Windows is beneficial, but i'm guessing I'm wrong here. For Linux, Yeah I know, it's overkill, but I've done it just because. Windows Security (kees) might sweat bullets when he envies my setup :D :p ...seriously, maybe I'll remove it but I also support moontan's reason for using it.
     
  15. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    I suppose Trojans can use drive-by's. The distinction between malware is more convoluted than ever as complexity of attacks increases.

    Regardless, what it comes down to is that, with Chrome, an attacker who attacks the exposed components is going to be left in a very tight sandbox. On Linux it is unreasonable to expect attacks on Chrome when the system is properly hardened, the costs are simply too high. On Windows it's still not exactly reasonable, but certainly moreso than Linux, so it may make sense to use something like ScriptDefender, but, because it's going to interfere with day-to-day activities, it may not be worth it.

    @Wat,
    Yes, that's how an attack will typically work. And, yes, it's the third party scripts to be worried about - but either way the attack is on unprivileged components with few rights, certainly not enough rights to install a package, or even write to the disk.

    You can protect against very advanced attacks that will break out of the sandbox this way, you just have to ask if it's worth it, due to the cumbersome nature of the extension. On Linux I think it's not really worth it, you can get much better security gains through something like Apparmor or kernel hardening.
     
  16. Daveski17

    Daveski17 Registered Member

    Joined:
    Nov 11, 2008
    Posts:
    10,239
    Location:
    Lloegyr
    Five years ago I contracted a trojan from a Russian webpage. I am pretty convinced it was from a flash advert. Interestingly it was Google (I was running SeaMonkey & utilising its Google translator at the time) that alerted me to the trojan & then proceeded to block the page. It took SUPERAntiSpyware to remove the offending malware after Norton & SpyBot failed to detect it. I also downloaded MBAM for the first time to run that as well. I haven't trusted AV's since to be honest. No doubt Chrome's sandbox would have caught the trojan. I think that sandboxing should be developed on all browsers eventually.
     
  17. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    Yes, unfortunately I find AV to be very lacking at the moment. They're very misguided. I like the concept of determining that a file is suspicious, but it's implemented all wrong.
     
  18. wat0114

    wat0114 Registered Member

    Joined:
    Aug 5, 2012
    Posts:
    4,063
    Location:
    Canada
    Excellent, thanks again!
     
  19. Daveski17

    Daveski17 Registered Member

    Joined:
    Nov 11, 2008
    Posts:
    10,239
    Location:
    Lloegyr
    Yes, AV is an outdated solution I believe. My faith these days is in browser hardening, common sense, MBAM & VirusTotal in that order. LOL!
     
  20. moontan

    moontan Registered Member

    Joined:
    Sep 11, 2010
    Posts:
    3,931
    Location:
    Québec
    well,

    the developer sure seems busy.
    another version was released today:

    Version: 3.4
    Updated: 6 November 2013
    Size: 63.53KB
     
  21. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    It would be nice to know what these changes are and if this code were hosted somewhere that we could see it and review it.
     
  22. moontan

    moontan Registered Member

    Joined:
    Sep 11, 2010
    Posts:
    3,931
    Location:
    Québec
    yes, it would.

    not sure, but i don't think the code for NoScript is open either...
     
  23. Hungry Man

    Hungry Man Registered Member

    Joined:
    May 11, 2011
    Posts:
    9,146
    Both are open source. I don't know where NoScript is hosted though.
     
  24. moontan

    moontan Registered Member

    Joined:
    Sep 11, 2010
    Posts:
    3,931
    Location:
    Québec
    i see, tnx m8!
     
  25. twl845

    twl845 Registered Member

    Joined:
    Apr 12, 2005
    Posts:
    4,186
    Location:
    USA
    Thanks for the heads up! :)
     
Thread Status:
Not open for further replies.
  1. This site uses cookies to help personalise content, tailor your experience and to keep you logged in if you register.
    By continuing to use this site, you are consenting to our use of cookies.