Java vs JavaScript

J

Joerg Meier

Well, if you hover on the link, Firefox, at least, will display
the link as being according to the href= phrase, but the actual
destination will be according to the onclick= phrase.

If you don't hover, the href link might differ from the text link: <a
href="http://www.evil.org">www.google.com</a>. Have I now conclusively
proven that HTML has a giant, gaping security hole ?

If Firefox display and execution differ, then that seems to be a Firefox
issue. Neither HTML nor JavaScript somehow require Firefox to display the
href content instead of the onclick content and then execute the onclick
content instead of the href content. This disparity seems to be squarely at
the feet of whoever maintains that particular behaviour.

Liebe Gruesse,
Joerg
 
J

Joshua Cranmer ðŸ§

Security is about the person using the browser, not the browser itself, nor the
page that the browser is displaying. /They/ aren't going to loose money, get
infected, be advertised at unwantedly, whatever... The person is -- or may be.
If the whole settup (Java/Flash/JavaScript/HTML/etc) is such that an actual
user is mislead, then that is security failure, and then it's just a matter of
finger-pointing as to which part of the system takes how much blame.

I prefer to draw a distinction between "attacks" that rely on confusing
the user to direct them to a fake site (I'll call this phishing for lack
of a better name) and attacks that actively harm you (more traditional
security exploits). To some degree, phishing attacks are unavoidable due
to stupid users, and you can make a case that many would be better
handled not by informing the user of the malicious page switch
beforehand but rather by indicating that the target of the link is not
what the link claimed it was. Although success in the latter arena isn't
great, either.
I expect I'll be able to make the same claim about HTNL5 soon, if I can't
already.

One point of pedantry I want to bring up: JavaScript the language is not
the same as the set of JavaScript libraries used in web programming
(often known as DOM). The set of new additions to this repertoire over
the past several years has fallen under the terminology of "HTML5"
(although I know many web engine developers who dislike that term).
HTML has problems. JavaScript makes it easier to exploit those problems, and
adds new ones of its own. Java, FLash, and any other pluggin can be expected
to add yet more problems -- it's inherent in the nature of a plugin (by which I
mean exernal compiled code) that it may open too many doors (NACL aside,
perhaps).

The source of vulnerabilities is often in libraries, not languages; most
of the security problems in Java that I can think up are not in the core
VM but rather in the expansive set of libraries that make up the
standard library. Similarly, JS's core language isn't the source of most
problems but rather the DOM. In a similar vein, Flash and NaCl have
problems simply because they allow access to rather less well-secured
libraries.

The only way you could get rid of these vulnerabilities would be to
freeze the allowed access and the implementation except for bug and
security fixes and then wait for 20 years (think TeX). And that's not
going to happen.
 
T

Tim Slattery

One point of pedantry I want to bring up: JavaScript the language is not
the same as the set of JavaScript libraries used in web programming
(often known as DOM).

The DOM (Document Object Model) is NOT a set of Javascript libraries.
It's the way the browser makes the currently loaded document (usually
an HTML page) available to the Javascript routines.
The set of new additions to this repertoire over
the past several years has fallen under the terminology of "HTML5"
(although I know many web engine developers who dislike that term).

HTML5 encompasses a number of things, see http://diveintohtml5.info
for a look at the whole thing. It's not more JS libraries. There are
certainly more JS commands and abilities to take advantage of the new
features in HTML5.
 
J

Joshua Cranmer ðŸ§

The DOM (Document Object Model) is NOT a set of Javascript libraries.
It's the way the browser makes the currently loaded document (usually
an HTML page) available to the Javascript routines.

The DOM is not part of the core JavaScript language. Ergo, it's a
library as far as JavaScript is concerned. It certainly includes more
than the reflection of the document to JS; DOM promises is an example
(although it has since moved from a DOM feature to a core JS feature).
HTML5 encompasses a number of things, see http://diveintohtml5.info
for a look at the whole thing. It's not more JS libraries. There are
certainly more JS commands and abilities to take advantage of the new
features in HTML5.

When most people talk excitedly about HTML5, they often refer not to the
additions to the declarative syntax of HTML but rather to the APIs like
Geolocation, IndexedDB, WebWorker, etc. that are basically all JS
library work. The document you linked to is quite guilty of this: only 4
of its 11 chapters actually discuss HTML features. Whatever the original
intent of the terminology, it has become a catchall term in common
parlance for "everything added to the web platform since the demise of
Netscape."
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,733
Messages
2,569,440
Members
44,831
Latest member
HealthSmartketoReviews

Latest Threads

Top