The Ghost in the Browser: Analysis of Web-Based Malware [pdf]
usenix.org
usenix.org
...adversaries take advantage of powerful scripting languages such as Javascript
to determine exactly which vulnerabilities are present on a user’s computer and
use that information to request appropriate exploits from a central server.
Even though this has been a well-known problem for a long time now, we still have a HUGE number of people here on HN that trash talk the very idea of not using javascript. An industry is in a very bad place when using the latest fad tool (e.g. Angular) trumps user safety.I don't particularly see this as an indictment of the industry, rather, it's an indication of the risk-benefit trade-off that most people are willing to make. A little risk, a lot of functionality.
Put a different way; driving is WAY more of a risk, but it doesn't seem to stop people doing it.
We've mostly gotten rid of Java and Flash at this point. That seems rational. The investment in browser (and JS engine) security at this point is massive. If you've got missile launch codes on your computer or something, by all means, don't browse! (or browse with JS disabled, or use Qubes, or otherwise sandbox your browser).
Realistically, at any given point in time my browser IS vulnerable - but on the other hand, my CC details and DOX aren't worth burning a reliable 0day on, so I'm cool with JS enabled.
> 1%
That just proves my point about how widespread this disregard for safety is in this industry. Saying "but those people make broken products as well!" isn't a justification to do so yourself.
> driving
is off topic, and in no way comparable. I am not being forced to accept risk from driving to read document or submit a simple form.
> Java and Flash
Not documents. More importantly, this is another example where saying "but he did it to!" isn't a justification.
> missile launch codes
This is just cheap hyperbole intended to distract.
> don't browse [unless you let us force risk on you]
At least you admit that you agree with this ultimatum.
> my browser IS vulnerable
Yes, it probably is - so maybe you should start to work on fixing that situation. A good place to start would be limiting the use of the main vectors for infection... which is javascript. The paper even discusses (and I quoted) how the use of javascript enables auto-selection of attacks.
> my CC details and DOX aren't worth
Ahh, the "but I'm not interesting enough to be a target" fallacy, where you only consider targeted attacks.
P.S: I write browser exploits (mostly FF, I'm not pro enough to do Chrome!). Usually use-after-free. Myself and my colleagues still browse with JS on. BTW, NoScript bypass is do-able.
SVG is another good source of bugs that comes to mind.
I don't think FF code quality is particularly worse than other browsers. Part of the problem is that it is simply a very large very public project. Some of the code is very old. Mainly though, they have been a bit slow to implement architectural features (e.g. privilege separation / sandboxing) which would improve resilience.