Java is supposed to be limited to a "security sandbox" if it's a web applet (as opposed to a standalone program). I was under the impression that Javascript was designed partly to get around such "inconveniences" as the sandbox. If I'm mistaken, I hope someone will correct me.
Java and Javascript have almost nothing in common, aside from both being syntactically C-like. The name similarity was a marketing thing.
Both Java and Javascript run sandboxed if you get them from an untrusted source. There is, AFAIK, no cross-platform way of doing anything outside the sandbox in JS. (In Mozilla, a JS program can ask to leave the sandbox-- the user gets a dialogue asking whether to let it do so-- and once that's done, it can do almost anything. However, all the things it can do are based on Netscape/Mozilla's own technologies (XPCOM, and the objects under netscape.security, etc) so I'd be surprised if any of them worked in Explorer.
But even running Javascript on web pages is a security risk.
AFAIK, the main risk with having arbitrary JS on web pages is with things inside the browser, like cookies. If I could put a piece of JS on a page you were receiving from LJ, I could read your login cookie and send it to any site I chose. But unless your browser was very broken, I wouldn't have any way of getting at your files.
"Java and Javascript have almost nothing in common [...]"
*nod* Deliberate name similarity, and one of the uses for Java is also similar to what Javascript was designed for. I didn't mean to imply greater connection that that.
"Both Java and Javascript run sandboxed if you get them from an untrusted source."
That was a clue I lacked -- that Javascript is also sandboxed.
"AFAIK, the main risk with having arbitrary JS on web pages is with things inside the browser, like cookies."
Okay, another question: was this always the case, or did security get added/improved? Doing a web search for "malicious javascript" shows a lot of other people being concerned for reasons similar to mine, but most of the hits are for things written in 2001. So was this an improvement in the language and/or implementations since then, or just more writers finding out it wasn't as bad as they'd thought?
"[...] unless your browser was very broken, I wouldn't have any way of getting at your files."
And, of course, various implementations of both Java and Javascript have been found to be buggy in various ways ... Apparently the Nimda worm used Javascript holes, didn't it?
What I've seen today suggests (though I need to do a lot more research) that Javascript is far less dangerous than I'd thought but not quite safe in the real world (i.e. buggy real-world browsers); and Java is far more dangerous than I'd thought, about as bad as Javascript.
(Before I turned off Javascript, I had more reliability problems from Javascript -- browser crashes from buggy scripts -- and a greater performance hit from Java. But Java is a) less common and b) less likely to be used for random silly "dancing bears" types of things. I probably should have turned off Java as well.)
Hmm. It seems one of the big risks of Javascript is having passwords compromised ... so if the browsers I use now are less prone to crashing when faced with bad scripts (or because of memory leaks in their Javascript implementations), perhaps I could designate one machine to access my bank accounts, eBay, PayPal, etc., and turn Javascript back on on the others. I'll think about it. Running untrusted code still makes me a bit nervous in general, reasonable or not.
Okay, another question: was this always the case, or did security get added/improved?
I don't know... I think it was always the case in theory, but problems have appeared over the years. I'm not well up on all the history, though (but I'd like to be). For example:
Apparently the Nimda worm used Javascript holes, didn't it?
AIUI the JS part of Nimda loaded the rest using window.open("filename-of-evil-stuff"). I think that's a browser problem rather than JS; it's pretty reasonable that JS on one page should be able to tell the browser to go to another page, but the browser shouldn't respond to being given a URL whether by JS or by the user, by just downloading and running anything. At least not without lots and lots of persuading from the user.
(no subject)
Java and Javascript have almost nothing in common, aside from both being syntactically C-like. The name similarity was a marketing thing.
Both Java and Javascript run sandboxed if you get them from an untrusted source. There is, AFAIK, no cross-platform way of doing anything outside the sandbox in JS. (In Mozilla, a JS program can ask to leave the sandbox-- the user gets a dialogue asking whether to let it do so-- and once that's done, it can do almost anything. However, all the things it can do are based on Netscape/Mozilla's own technologies (XPCOM, and the objects under netscape.security, etc) so I'd be surprised if any of them worked in Explorer.
But even running Javascript on web pages is a security risk.
AFAIK, the main risk with having arbitrary JS on web pages is with things inside the browser, like cookies. If I could put a piece of JS on a page you were receiving from LJ, I could read your login cookie and send it to any site I chose. But unless your browser was very broken, I wouldn't have any way of getting at your files.
(no subject)
*nod* Deliberate name similarity, and one of the uses for Java is also similar to what Javascript was designed for. I didn't mean to imply greater connection that that.
"Both Java and Javascript run sandboxed if you get them from an untrusted source."
That was a clue I lacked -- that Javascript is also sandboxed.
"AFAIK, the main risk with having arbitrary JS on web pages is with things inside the browser, like cookies."
Okay, another question: was this always the case, or did security get added/improved? Doing a web search for "malicious javascript" shows a lot of other people being concerned for reasons similar to mine, but most of the hits are for things written in 2001. So was this an improvement in the language and/or implementations since then, or just more writers finding out it wasn't as bad as they'd thought?
"[...] unless your browser was very broken, I wouldn't have any way of getting at your files."
And, of course, various implementations of both Java and Javascript have been found to be buggy in various ways ... Apparently the Nimda worm used Javascript holes, didn't it?
What I've seen today suggests (though I need to do a lot more research) that Javascript is far less dangerous than I'd thought but not quite safe in the real world (i.e. buggy real-world browsers); and Java is far more dangerous than I'd thought, about as bad as Javascript.
(Before I turned off Javascript, I had more reliability problems from Javascript -- browser crashes from buggy scripts -- and a greater performance hit from Java. But Java is a) less common and b) less likely to be used for random silly "dancing bears" types of things. I probably should have turned off Java as well.)
Hmm. It seems one of the big risks of Javascript is having passwords compromised ... so if the browsers I use now are less prone to crashing when faced with bad scripts (or because of memory leaks in their Javascript implementations), perhaps I could designate one machine to access my bank accounts, eBay, PayPal, etc., and turn Javascript back on on the others. I'll think about it. Running untrusted code still makes me a bit nervous in general, reasonable or not.
And thanks for the dose of Clue.
(no subject)
I don't know... I think it was always the case in theory, but problems have appeared over the years. I'm not well up on all the history, though (but I'd like to be). For example:
Apparently the Nimda worm used Javascript holes, didn't it?
AIUI the JS part of Nimda loaded the rest using window.open("filename-of-evil-stuff"). I think that's a browser problem rather than JS; it's pretty reasonable that JS on one page should be able to tell the browser to go to another page, but the browser shouldn't respond to being given a URL whether by JS or by the user, by just downloading and running anything. At least not without lots and lots of persuading from the user.