Page 1 of 1
NoJava
Posted: Sun May 17, 2009 9:11 am
by `nar
Maybe what we need is a more general form of noscript. One that can protect across browsers, anything that runs Java. Too bad it really isn't "Java" per se. But after seeing this:
http://www.pcworld.com/businesscenter/a ... _know.html I wonder if we can protect Adobe Reader somehow. Or just convince people they don't need Adobe and just use Foxit, I do. Why do we need java imbedded in Adobe Reader anyway? I was wonder why that silly program has gotten so bloated.
Re: NoJava
Posted: Sun May 17, 2009 9:26 am
by Giorgio Maone
Well, at least as long as you run NoScript (even better with NoScript Options|Plugins|Apply these restrictions to trusted sites as well) you don't risk to be pwned by a rogue and silent PDF while browsing the web.
Yes, you can always screw yourself by opening the wrong email attachment, but you surely have more control on that...
Re: NoJava
Posted: Sun May 17, 2009 10:09 am
by `nar
I think just disabling java in the adobe reader is the best answer. But in response to you, if I apply those restrictions to trusted sites, why trust them in the first place? Simple scripting still works but no "plugins?" Isn't it usually the plugin's that people want to see in the first place, such as video? Maybe drop-downs and other moving page elements I suppose. Those could be script or CSS right? Steve Gibson made a big deal about coding his site to not require scripting a while back.
www.grc.com But that's getting off topic now.
Re: NoJava
Posted: Sun May 17, 2009 12:17 pm
by Giorgio Maone
`nar wrote:I think just disabling java in the adobe reader is the best answer.
Generally speaking,
no it's not.
`nar wrote:But in response to you, if I apply those restrictions to trusted sites, why trust them in the first place? Simple scripting still works but no "plugins?" Isn't it usually the plugin's that people want to see in the first place, such as video?
Yes, but NoScript gets you to choose which video clip you want to run, one by one (clicking on its placeholder and having a chance to verify its URL and content type).
This means that if a site you trust gets compromised by a (fairly common place)
SQL injection attack, even in the remote case (never seen in the wild yet) that the malicious JavaScript is entirely hosted on-site, it cannot exploit plugin vulnerabilities for privilege escalation and/or heap spraying.