CID's protection against Javascript malware

Hi,

Does CID already protect against Javascript malware?
With HTML5, CSS3 and its selectors, javascript could be used more and more as a clientside application which has direct disc access via webworkers and what not

I know this is not yet the case, but it would say that it will be in the near future.
Is this a threat? does CID need to be adjusted so it had more CF-like protection from within the browser against this.

Noscript allows javascript per domain to be disabled of enabled, but most sites require javascript. What if the malware is infested in the mail site you are visiting? noscript would be of no use if i enabled javascript for that domain

If this is (or would) become a serious security issue, CID would have a great 'sellingpoint ’ (i know it is free)
CID would be more secure on this front than others

Is this a weird thought or does it make sense?

Hi,

Not weird at all. It certainly makes sense. :slight_smile:

I think the solution is quite obvious, but it requires a lot of work, and Mozilla has to do it. :wink:

Yep, Firefox has to be rebuilt from the ground up. Multi-process architecture, where the content-processes are sandboxed (like in Chromium), is the solution.

Here is an old blog-post: goals for multi-process firefox.

NoScript is, IMO, not a security-solution.

So would you say that Comodo Dragon is way better protected against these type of future Javascript malware.

If that is the case, is IceDragon going to get anywhere near the security level of Dragon?

Yes. :slight_smile:

The way Dragon/Chromium is built is superior. Windows has sandboxing-techniques that can be combined to a powerful sandbox:

  • Restricted Token (great for XP-users with administrator-account)
  • Job Objects (several restrictions can be applied, such as clipboard-access (read/write), process-launch)
  • Alternate desktop (disallows sending of window-messages to processes on the user’s desktop)
  • Untrusted integrity-level (Vista and later; denies access to any resource at low or higher level)

IceDragon/Firefox does none of that. (Internet Explorer on Vista and later does some of it.) On Vista and later, Restricted Token is applied, as it is for all non-elevated processes, and it is run at medium integrity-level. (All user-files are medium level.)

Unless the architecture is changed into a sandboxed multi-process one, I cannot see how it could possibly be as secure as Dragon.

you definately know your stuff :slight_smile:
thanks for your input. I might just use CD instead of CID and skip NoScript all together

I just use that to be protected against threats coming from those external ad servers
Legit sites which use those ad services could become a danger to anyone visiting ths sites once the ad services got hacked.

This has happend and many pc’s got infected. I skipped the dance because noscript disabled the script by default and I only enabled the domian’s JS
Would CD also have kept me safe? even though the malware script was allowed to run

But this is more of a Dragon question instead of an IceDragon one :slight_smile:

You’re welcome. :slight_smile:

That is what it is meant to protect against. :slight_smile: But no security-solution can block every attack, since no software is perfect. Recently, at Pwnium 2, a bug in WebKit combined with a bug in the IPC-layer made it possible to escape the Chrome-sandbox.

I doubt that a one-bug-exploit could be successful.

The problem with NoScript is that it breaks the majority of the internet by default.

As long as you’re not visiting questionable sites, it’s a pretty safe bet that any navigational Javascript on a site isn’t going to be malicious, so it just doesn’t make much sense from a usability standpoint to disallow all scripts by default. Then as you’ve noticed, you need to whitelist a domain to get site functionality.

I prefer to use the AdBlock Plus extension and use a filter to block third-party scripts, (Such as external adservers) because external scripts are something that the site owner has no control over. This way, most site functionality is not broken because the locally hosted scripts are allowed to run, yet I have protection from external scripts.

You can do this with the filter:

*$script,third-party

If you do encounter a site that you’d like to allow external scripts, such as YouTube that requires external scripts for load balancing/content serving, you can add domain exceptions to the filter.

*$script,third-party,domain=~youtube.com

If you want to add more domains, you can string them together using the “Pipe” symbol. (|)

*$script,third-party,domain=~youtube.com|~whatever.com