Java vs JavaScript

Discussion in 'Java' started by Roedy Green, Apr 23, 2014.

  1. Roedy Green

    Roedy Green Guest

    There is something odd going on.

    I have always thought the Java sandbox was so restrictive, there was
    nothing a user need worry about. There is no way an unsigned applet
    could do any damage.

    But Oracle and the browsers are acting like unsigned Applets are
    highly dangerous, making you do override after override to run them.

    On the other hand I don't think JavaScript has any sort of sandbox at
    all, and everyone blissfully runs scripts that can do anything.

    Why the double standard? Is JavaScript safer than I thought?
    --
    Roedy Green Canadian Mind Products http://mindprod.com
    "Don't worry about people stealing an idea; if it's original, you'll
    have to shove it down their throats."
    ~ Howard Aiken (born: 1900-03-08 died: 1973-03-14 at age: 73)
     
    Roedy Green, Apr 23, 2014
    #1
    1. Advertisements

  2. Roedy Green

    markspace Guest

    On 4/23/2014 8:39 AM, Roedy Green wrote:
    > On the other hand I don't think JavaScript has any sort of sandbox at
    > all, and everyone blissfully runs scripts that can do anything.


    JavaScript runs in a sandbox, but as far as I know it isn't very
    restrictive. I think there's like a 4 megabyte limit *per site* for the
    amount of data it can store on your hard drive, for example.

    But yes I agree "something is going on." FireFox OS is what is going
    on, and anything that runs in a browser that competes with it is being
    extinguished by Brenden Eich and company.
     
    markspace, Apr 23, 2014
    #2
    1. Advertisements

  3. On 4/23/2014 10:39 AM, Roedy Green wrote:
    > There is something odd going on.
    >
    > I have always thought the Java sandbox was so restrictive, there was
    > nothing a user need worry about. There is no way an unsigned applet
    > could do any damage.


    Unless the Java VM and/or runtime had security holes.

    > On the other hand I don't think JavaScript has any sort of sandbox at
    > all, and everyone blissfully runs scripts that can do anything.


    "anything" is a bit of a misnomer here. The standard JavaScript runtime
    profile doesn't allow you to:

    1. Access the local filesystems
    2. Spawn, communicate, or interact with other processes
    3. Open generic network sockets
    4. Execute arbitrary native code

    All of these are possible with part of the standard Java library.

    In general, the security model of Java appears to me to be more of an
    afterthought, with ad-hoc securing of APIs. In contrast, the development
    of JavaScript has tended towards not admitting new APIs until after
    security reviews have been done on the APIs. Legacy APIs can be
    problematic sometimes, but the mighty hammer of things like CORS or CSP
    has reduced the scope of problems here.

    Certainly, in the past several months, the browser developers appear to
    have been taking security more seriously than Oracle has with Java.

    --
    Beware of bugs in the above code; I have only proved it correct, not
    tried it. -- Donald E. Knuth
     
    Joshua Cranmer ðŸ§, Apr 23, 2014
    #3
  4. Roedy Green

    Silvio Guest

    On 04/23/2014 05:39 PM, Roedy Green wrote:
    > There is something odd going on.
    >
    > I have always thought the Java sandbox was so restrictive, there was
    > nothing a user need worry about. There is no way an unsigned applet
    > could do any damage.
    >
    > But Oracle and the browsers are acting like unsigned Applets are
    > highly dangerous, making you do override after override to run them.
    >
    > On the other hand I don't think JavaScript has any sort of sandbox at
    > all, and everyone blissfully runs scripts that can do anything.
    >
    > Why the double standard? Is JavaScript safer than I thought?
    >


    In short: yes. Java was not designed to be safe in any particular way in
    that it does not restrict you from doing anything potentially dangerous
    (accessing file systems, doing socket level IO, executing native
    code...). The runtime that executes your code is responsible for taking
    away capabilities from the code as an afterthought. This is very hard to
    do thoroughly and exhaustively.

    JavaScript and it's traditional runtime profile (inside a browser
    embedded in a web page) is very limited in what it can do.No need for
    the browser to enforce much restriction (barring stuff like XSS).
    Insecurity has to be added via libraries provided by the runtime.

    Of course JavaScript still sucks as a programming language...

    Silvio
     
    Silvio, Apr 23, 2014
    #4
  5. Roedy Green

    Arne Vajhøj Guest

    On 4/23/2014 11:39 AM, Roedy Green wrote:
    > I have always thought the Java sandbox was so restrictive, there was
    > nothing a user need worry about. There is no way an unsigned applet
    > could do any damage.


    That is true assuming there are no bugs in the Java applet security
    implementation.

    I think they have found 200-300 bugs during the last 2-3 years.

    > But Oracle and the browsers are acting like unsigned Applets are
    > highly dangerous, making you do override after override to run them.


    If a bug in Java allows an unsigned applet to gain privs, then it is
    extremely dangerous as a malicious site could run a 1 pixel applet
    that infected the PC without the user not even knowing that Java was
    running.

    Apparently Oracle does no longer believe that they can fix all
    security bugs.

    Given the recent history, then that seems realistic.

    > On the other hand I don't think JavaScript has any sort of sandbox at
    > all, and everyone blissfully runs scripts that can do anything.


    Not true.

    JavaScript is sandboxed and has about the same access as an unsigned
    applet.

    And because there are no concept of signed JavaScript with granted
    privs then it is probably easier to avoid bugs as the code must be
    a lot simpler.

    > Why the double standard? Is JavaScript safer than I thought?


    There has been found plenty of JavaScript bugs over the years.

    But JavaScript has done better than Java in recent years.

    Arne
     
    Arne Vajhøj, Apr 24, 2014
    #5
  6. On 4/23/2014 11:39 PM, Roedy Green wrote:
    > There is something odd going on.
    >
    > I have always thought the Java sandbox was so restrictive, there was
    > nothing a user need worry about. There is no way an unsigned applet
    > could do any damage.
    >
    > But Oracle and the browsers are acting like unsigned Applets are
    > highly dangerous, making you do override after override to run them.


    I have commented in detail to your various other posts; the truth is out
    there!
    >
    > On the other hand I don't think JavaScript has any sort of sandbox at
    > all, and everyone blissfully runs scripts that can do anything.


    I suggest/recommend/insist the dinosaurs here at java-IS-the-new-cobol
    read the following several times over: -

    https://wiki.mozilla.org/WebAPI

    As usual the cognoscente here do not know what they are talking about
    :-( WebApps have moved on but they'll never replace the functionality
    Applets provide out-of-the-box!
    >
    > Why the double standard? Is JavaScript safer than I thought?
    >


    Google, Apple, and Microsoft say Larry is a fat lazy vain old bitch who
    is too tired to defend his patch.
     
    Richard Maher, Apr 24, 2014
    #6
  7. On 4/24/2014 10:22 AM, Arne Vajhøj wrote:
    > On 4/23/2014 11:39 AM, Roedy Green wrote:
    >> I have always thought the Java sandbox was so restrictive, there was
    >> nothing a user need worry about. There is no way an unsigned applet
    >> could do any damage.

    >
    > That is true assuming there are no bugs in the Java applet security
    > implementation.
    >
    > I think they have found 200-300 bugs during the last 2-3 years.


    So what? How does the imapact-meter rate with the likes of Heart-Bleed
    and OpenSSL?
    >
    >> But Oracle and the browsers are acting like unsigned Applets are
    >> highly dangerous, making you do override after override to run them.

    >
    > If a bug in Java allows an unsigned applet to gain privs, then it is
    > extremely dangerous as a malicious site could run a 1 pixel applet
    > that infected the PC without the user not even knowing that Java was
    > running.


    You don't need a 1px applet; 0x0 is just fine. Once again, look at the
    following link to BSD Socket functionality and Contacts lookup and so on
    and then ask the Applet Slaggers to shut their fucking mouths!

    https://wiki.mozilla.org/WebAPI
    >
    > Apparently Oracle does no longer believe that they can fix all
    > security bugs.


    Just the incompetent people they've hired.

    >
    > Given the recent history, then that seems realistic.


    Given you're a knob I need not respond.
    >
    >> On the other hand I don't think JavaScript has any sort of sandbox at
    >> all, and everyone blissfully runs scripts that can do anything.

    >
    > Not true.
    >
    > JavaScript is sandboxed and has about the same access as an unsigned
    > applet.


    Wake up to modern Web-Apps!

    >
    > And because there are no concept of signed JavaScript with granted
    > privs then it is probably easier to avoid bugs as the code must be
    > a lot simpler.
    >
    >> Why the double standard? Is JavaScript safer than I thought?

    >
    > There has been found plenty of JavaScript bugs over the years.
    >
    > But JavaScript has done better than Java in recent years.


    There are none so blind as those who will not see.

    >
    > Arne
    >
     
    Richard Maher, Apr 24, 2014
    #7
  8. On 4/27/2014 7:20 PM, Chris Uppal wrote:
    >
    > Agreed that this is not the way to design a security arhutecture if you have
    > the opportunity to build the thing from the ground up. (Of course, the
    > designers were in a tearing hurry at the time this stuff was set in stone).


    Really?
    >
    >
    > Agreed that JS gains some security from the fact that it just doesn't have the
    > ability to touch as much as the Java runtime


    https://wiki.mozilla.org/WebAPI
     
    Richard Maher, Apr 27, 2014
    #8
  9. On 4/27/2014 4:00 PM, lipska the kat wrote:
    >
    > Have you seen what some people can do with HTML5?
    >
    >


    I've certainly seen it and done it (see the link I've posted several
    times); many here haven't!

    Show me true multi-threading with that Worker-Thread crap . . .

    Show me true BSD sockets instead of that WebSocket shit that was tacken
    out of the HTML5 standard because it was so functionally and security
    deficient . . .

    Show me global memory between multiple browser tabs and the intrinsic
    segue to single-sign-n out of the box . . .

    Show me someone who can think outside of Larry's bollocks JavaFX and
    reel at the wonton functionality destruction at the hands of Eric
    Costlow. . .

    Show me someone who has lived in awe of Adobe Flex Charting for almost
    10 years. . .

    And I'll show you a sad and sorry newsgroup full of arse-wipes who see
    life through lambda coloured glasses :-(
     
    Richard Maher, Apr 27, 2014
    #9
  10. Roedy Green

    Stefan Ram Guest

    "Chris Uppal" <-THIS.org> writes:
    >Agreed that JS gains some security from the fact that it just doesn't have the


    I believe that JavaScript was and still is the main entry
    surface for infections via Browsers. (Some of the following
    URIs might be outdated, because I recorded the some time ago.)

    »according to an alert issued Thursday by the U.S.
    Computer Emergency Readiness Team (US-CERT), a division of
    the Department of Homeland Security (...) A CERT alert
    said Explorer users also can protect themselves by turning
    off the JavaScript function in their browsers. «

    http://www.washingtonpost.com/wp-dyn/articles/A6746-2004Jun25.html

    »If JavaScript is enabled in these applications, then the
    system is vulnerable to exploitation.«

    http://www.uscert.gov/current/current_activity.html#iis5

    Even Microsoft recommends to disable JavaScript:

    »Under Security level for this zone, move the slider to High.«

    http://www.microsoft.com/athome/security/online/browsing_safety.mspx

    And Microsoft recommends not to click on links (Yes!) but to
    type in URIs because of security risks by »javascript:«-links.

    »Do not click any hyperlinks that you do not trust.
    Type them in the Address bar yourself.«

    http://support.microsoft.com/?id=833786

    A web based computer magazine I read usually reports about
    2 - 4 browser exploits and security holes a month and about
    80 % of the time the advice is »until the manufacturer has a
    patch finished, the problem can be avoided by disabling JavaScript«.

    Some years ago, I started to collect such reports as a proof.
    But then I ceased to collect more such reports, because I
    needed my time for other things. Thus, when my records are
    dated now, this does not mean that there are no more such
    reports today; I just do not collect them anymore. If I
    would have continued, the list would be very much longer.
    (These reports are in German language.)

    http://www.heise.de/newsticker/meldung/48769
    http://www.heise.de/newsticker/meldung/48725
    http://www.heise.de/newsticker/meldung/63430
    http://www.heise.de/newsticker/meldung/48589
    http://www.heise.de/newsticker/meldung/48016
    http://www.heise.de/newsticker/meldung/48016
    http://www.heise.de/newsticker/meldung/47993
    http://www.heise.de/newsticker/meldung/60340
    http://www.heise.de/newsticker/meldung/47998
    http://www.heise.de/newsticker/meldung/47494
    http://www.heise.de/newsticker/meldung/47282
    http://www.heise.de/newsticker/meldung/46923
    http://www.heise.de/newsticker/meldung/61499
    http://www.heise.de/newsticker/meldung/60240
    http://www.heise.de/newsticker/meldung/69558
    http://www.heise.de/newsticker/meldung/66952
    http://www.heise.de/newsticker/meldung/66943
    http://www.heise.de/newsticker/meldung/66511
    http://www.heise.de/newsticker/meldung/67698
    http://www.heise.de/newsticker/meldung/67132
    http://www.heise.de/newsticker/meldung/69894
    http://www.heise.de/newsticker/meldung/68579
    http://www.heise.de/newsticker/meldung/69225
    http://www.heise.de/newsticker/meldung/66846
    http://www.heise.de/newsticker/meldung/68391
    http://www.heise.de/newsticker/meldung/69015
    http://www.heise.de/newsticker/meldung/66480
    http://www.heise.de/newsticker/meldung/66928
    http://www.heise.de/newsticker/meldung/66350
    http://www.heise.de/newsticker/meldung/64771
    http://www.heise.de/newsticker/meldung/58788
    http://www.heise.de/newsticker/meldung/61350
    http://www.heise.de/newsticker/meldung/59374
    http://www.heise.de/newsticker/meldung/60644
    http://www.heise.de/newsticker/meldung/60855
    http://www.heise.de/newsticker/meldung/64426
    http://www.heise.de/newsticker/meldung/60615
    http://www.heise.de/newsticker/meldung/68394
    http://www.heise.de/newsticker/meldung/58228
    http://www.heise.de/newsticker/meldung/61700
    http://www.heise.de/newsticker/meldung/61646
    http://www.heise.de/newsticker/meldung/61828
    http://www.heise.de/newsticker/meldung/57578
    http://www.heise.de/newsticker/meldung/56354
    http://www.heise.de/newsticker/meldung/54973
    http://www.heise.de/newsticker/meldung/59330
    http://www.heise.de/newsticker/meldung/56795
    http://www.heise.de/newsticker/meldung/56323
    http://www.heise.de/newsticker/meldung/53382
    http://www.heise.de/newsticker/meldung/59449
    http://www.heise.de/newsticker/meldung/54272
    http://www.heise.de/newsticker/meldung/56646
    http://www.heise.de/newsticker/meldung/53186
    http://www.heise.de/newsticker/meldung/53042
    http://www.heise.de/newsticker/meldung/54063
    http://www.heise.de/newsticker/meldung/52995
    http://www.heise.de/newsticker/meldung/52935
    http://www.heise.de/newsticker/meldung/55138
    http://www.heise.de/newsticker/meldung/54716
    http://www.heise.de/newsticker/meldung/52844
    http://www.heise.de/newsticker/meldung/54431
    http://www.heise.de/newsticker/meldung/54734
    http://www.heise.de/newsticker/meldung/54487
    http://www.heise.de/newsticker/meldung/54605
    http://www.heise.de/newsticker/meldung/55396
    http://www.heise.de/newsticker/meldung/53582
    http://www.heise.de/newsticker/meldung/52776
    http://www.heise.de/newsticker/meldung/52752
    http://www.heise.de/newsticker/meldung/61245
    http://www.heise.de/newsticker/meldung/52365
    http://www.heise.de/newsticker/meldung/52377
    http://www.heise.de/newsticker/meldung/54636
    http://www.heise.de/newsticker/meldung/54719
    http://www.heise.de/newsticker/meldung/54714
    http://www.heise.de/newsticker/meldung/54697
    http://www.heise.de/newsticker/meldung/52377
    http://www.heise.de/newsticker/meldung/54582
    http://www.heise.de/newsticker/meldung/52390
    http://www.heise.de/newsticker/meldung/52255
    http://www.heise.de/newsticker/meldung/54352
    http://www.heise.de/newsticker/meldung/51995
    http://www.heise.de/newsticker/meldung/51751
    http://www.heise.de/newsticker/meldung/53644
    http://www.heise.de/newsticker/meldung/60908
    http://www.heise.de/newsticker/meldung/51511
    http://www.heise.de/newsticker/meldung/50968
    http://www.heise.de/newsticker/meldung/50363
    http://www.heise.de/newsticker/meldung/50128
    http://www.heise.de/newsticker/meldung/50111
    http://www.heise.de/newsticker/meldung/50179
    http://www.heise.de/newsticker/meldung/53489
    http://www.heise.de/newsticker/meldung/52018
    http://www.heise.de/newsticker/meldung/54188
    http://www.heise.de/newsticker/meldung/49517
    http://www.heise.de/newsticker/meldung/53499
    http://www.heise.de/newsticker/meldung/49219
    http://www.heise.de/newsticker/meldung/49219
    http://www.heise.de/newsticker/meldung/49240
    http://www.heise.de/newsticker/meldung/49240
    http://www.heise.de/newsticker/meldung/49240
    http://www.heise.de/newsticker/meldung/48877
    http://www.heise.de/newsticker/meldung/48793
    http://www.heise.de/newsticker/meldung/48892
    http://www.heise.de/newsticker/meldung/53964
    http://www.heise.de/newsticker/meldung/53519
    http://www.heise.de/newsticker/meldung/53544
     
    Stefan Ram, Apr 27, 2014
    #10
  11. Roedy Green

    Joerg Meier Guest

    On 27 Apr 2014 18:09:28 GMT, Stefan Ram wrote:

    > "Chris Uppal" <-THIS.org> writes:
    >>Agreed that JS gains some security from the fact that it just doesn't have the

    > I believe that JavaScript was and still is the main entry
    > surface for infections via Browsers. (Some of the following
    > URIs might be outdated, because I recorded the some time ago.)


    Nobody is doubting that JavaScript was a big offender ten years ago, but it
    seems like it has been doing a lot better in more recent years.

    Liebe Gruesse,
    Joerg

    --
    Ich lese meine Emails nicht, replies to Email bleiben also leider
    ungelesen.
     
    Joerg Meier, Apr 27, 2014
    #11
  12. Roedy Green

    Stefan Ram Guest

    -berlin.de (Stefan Ram) writes:
    >»according to an alert issued Thursday by the U.S.
    >Computer Emergency Readiness Team (US-CERT), a division of
    >the Department of Homeland Security (...) A CERT alert
    >said Explorer users also can protect themselves by turning
    >off the JavaScript function in their browsers. «
    >http://www.washingtonpost.com/wp-dyn/articles/A6746-2004Jun25.html


    And just today, many press stories are breaking about a
    new zero-day drive-by security hole

    http://www.us-cert.gov/ncas/current...t-Explorer-Use-After-Free-Vulnerability-Being

    , and the suggestion sometimes given for this new hole is to
    disable JavaScript in the IE by setting the Security Level
    to »High«. They don't write it his way. They just write to
    set the Security Level to »High«, but they usually do not
    mention »JavaScript«.

    A source says:

    »The attack vector is quite ingenious in loading a Flash SWF
    file, using it to selectively spray memory, and looping back
    to a JavaScript program in IE.«
    ¯¯¯¯¯¯¯¯¯¯

    The usual cuplrits: Flash and JavaScript.

    However, nowadays, the press will not mention »JavaScript«
    and often not even »Flash«, they avoid this, the security
    problem is ascribed to the browser - after all the browser
    hosts the JavaScript implementation and is the actual
    program a person can install or deinstall. But »Java« is
    mentioned each time when there is a security problem in the
    JRE because »Java« /is/ an installable entity itself.

    So, JavaScript is not mentionend in the press because it is
    a technical details of the browser, while Java is a
    freestanding product, not part of the browser. Because of
    this avoidance of the mentioning of JavaScript, some people
    do believe that JavaScript today has become more secure. But
    you can find the technical details I quoted above if you
    search for them.
     
    Stefan Ram, Apr 29, 2014
    #12
  13. Roedy Green

    Arne Vajhøj Guest

    On 4/24/2014 4:20 AM, Richard Maher wrote:
    > On 4/24/2014 10:22 AM, Arne Vajhøj wrote:
    >> On 4/23/2014 11:39 AM, Roedy Green wrote:
    >>> I have always thought the Java sandbox was so restrictive, there was
    >>> nothing a user need worry about. There is no way an unsigned applet
    >>> could do any damage.

    >>
    >> That is true assuming there are no bugs in the Java applet security
    >> implementation.
    >>
    >> I think they have found 200-300 bugs during the last 2-3 years.

    >
    > So what? How does the imapact-meter rate with the likes of Heart-Bleed
    > and OpenSSL?


    For number of actual impacted users: much higher.

    >>> But Oracle and the browsers are acting like unsigned Applets are
    >>> highly dangerous, making you do override after override to run them.

    >>
    >> If a bug in Java allows an unsigned applet to gain privs, then it is
    >> extremely dangerous as a malicious site could run a 1 pixel applet
    >> that infected the PC without the user not even knowing that Java was
    >> running.

    >
    > You don't need a 1px applet; 0x0 is just fine.


    That just makes it worse.

    > Once again, look at the
    > following link to BSD Socket functionality and Contacts lookup and so on
    > and then ask the Applet Slaggers to shut their fucking mouths!
    >
    > https://wiki.mozilla.org/WebAPI


    That does not remedy observed Java security problems.

    >> Apparently Oracle does no longer believe that they can fix all
    >> security bugs.

    >
    > Just the incompetent people they've hired.
    >
    >> Given the recent history, then that seems realistic.

    >
    > Given you're a knob I need not respond.
    >>
    >>> On the other hand I don't think JavaScript has any sort of sandbox at
    >>> all, and everyone blissfully runs scripts that can do anything.

    >>
    >> Not true.
    >>
    >> JavaScript is sandboxed and has about the same access as an unsigned
    >> applet.

    >
    > Wake up to modern Web-Apps!
    >
    >> And because there are no concept of signed JavaScript with granted
    >> privs then it is probably easier to avoid bugs as the code must be
    >> a lot simpler.
    >>
    >>> Why the double standard? Is JavaScript safer than I thought?

    >>
    >> There has been found plenty of JavaScript bugs over the years.
    >>
    >> But JavaScript has done better than Java in recent years.

    >
    > There are none so blind as those who will not see.


    The stats are rather hard on Java:

    October 2010 - 6u22 - 29 security fixes
    February 2011 - 6u24 - 21 security fixes
    June 2011 - 6u26 - 17 security fixes
    October 2011 - 6u29/7u1 - 20 security fixes
    Februar 2012 - 6u31/7u3 - 14 security fixes
    June 2012 - 6u33-7u5 - 14 security fixes
    August 2012 - 6u35/7u7 - 1/4 security fixes
    October 2012 - 6u37/7u9 - 30 security fixes
    February 2013 - 6u39/7u13 - 50 security fixes
    February 2013 - 6u41/7u15 - 5 security fixes
    March 2013 - 6u43 /7u17- 2 security fixes
    April 2013 - 6u45/7u21 - 42 security fixes
    June 2013 - 7u25 - 40 security fixes
    October 2013 - 7u45 - 51 security fixes
    January 2014 - 7u51 - 36 security fixes
    April 2014 - 7u55/8u5 - 37 security fixes

    Arne
     
    Arne Vajhøj, Apr 30, 2014
    #13
  14. Roedy Green

    Silvio Guest

    On 05/01/2014 09:52 AM, Chris Uppal wrote:
    > Stefan Ram wrote:
    >
    >> So, JavaScript is not mentionend in the press because it is
    >> a technical details of the browser, while Java is a
    >> freestanding product, not part of the browser. Because of
    >> this avoidance of the mentioning of JavaScript, some people
    >> do believe that JavaScript today has become more secure. But
    >> you can find the technical details I quoted above if you
    >> search for them.

    >
    > I think there's a lot of truth to that. A few years back, JavaScript was still
    > viewed with suspicion (justifiably), and as such it was a "live issue" and so,
    > when it was involved in security problems, it got mentioned. These days many
    > people take it for granted, and are no more likely to think of it as
    > "contributing to" an exploit where it is used than the surrounding HTML (if
    > any) is.
    >
    > -- chris
    >
    >


    That is because JavaScript IS part of the HTML page and it can not
    contain a security hole by definition. Only the browser displaying the
    page can.

    The same would hold for Java IF the browser would be the one running the
    Java code. But instead the code is run by a third party plugin which
    leaves the browser limited room to control what the code can do. Even
    stuff like the standard library (which is where all the bombs are) comes
    with the plugin so no way for the browser to take away or restrict
    things there.

    It is much easier to not provide a File/URL class than to provide a
    third party one and then try to keep them constrained.
     
    Silvio, May 1, 2014
    #14
  15. On Thu, 01 May 2014 10:26:25 +0200, Silvio <>
    wrote:

    [snip]

    >That is because JavaScript IS part of the HTML page and it can not
    >contain a security hole by definition. Only the browser displaying the
    >page can.


    Oh, nonsense. Put an onclick= in an <a> tag to go to a different
    URL than specified in the href=, and you have a security issue due to
    JavaScript.

    [snip]

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, May 1, 2014
    #15
  16. Roedy Green

    Arne Vajhøj Guest

    On 5/1/2014 4:26 AM, Silvio wrote:
    > On 05/01/2014 09:52 AM, Chris Uppal wrote:
    >> Stefan Ram wrote:
    >>> So, JavaScript is not mentionend in the press because it is
    >>> a technical details of the browser, while Java is a
    >>> freestanding product, not part of the browser. Because of
    >>> this avoidance of the mentioning of JavaScript, some people
    >>> do believe that JavaScript today has become more secure. But
    >>> you can find the technical details I quoted above if you
    >>> search for them.

    >>
    >> I think there's a lot of truth to that. A few years back, JavaScript
    >> was still
    >> viewed with suspicion (justifiably), and as such it was a "live issue"
    >> and so,
    >> when it was involved in security problems, it got mentioned. These
    >> days many
    >> people take it for granted, and are no more likely to think of it as
    >> "contributing to" an exploit where it is used than the surrounding
    >> HTML (if
    >> any) is.

    >
    > That is because JavaScript IS part of the HTML page and it can not
    > contain a security hole by definition. Only the browser displaying the
    > page can.


    Today a browser typical comes with distinct:
    - layout/render engine
    - JavaScript engine

    And the two do not necessarily come from the same source.

    JS engine is still more tightly coupled with the browser, because
    it cannot (as far as I know) be replaced by the user. It may even
    be linked into the same executable as the rest. But somewhere
    at the source code level it is distinct.

    Arne
     
    Arne Vajhøj, May 2, 2014
    #16
  17. Roedy Green

    Silvio Guest

    On 05/01/2014 11:10 PM, Gene Wirchenko wrote:
    > On Thu, 01 May 2014 10:26:25 +0200, Silvio <>
    > wrote:
    >
    > [snip]
    >
    >> That is because JavaScript IS part of the HTML page and it can not
    >> contain a security hole by definition. Only the browser displaying the
    >> page can.

    >
    > Oh, nonsense. Put an onclick= in an <a> tag to go to a different
    > URL than specified in the href=, and you have a security issue due to
    > JavaScript.
    >
    > [snip]
    >
    > Sincerely,
    >
    > Gene Wirchenko
    >


    Now that is nonsense. Why is it a security issue if that is what the
    HTML page says it should do? It is something that can be discovered from
    the page itself and anything the JS instructs the browser to do it can
    decide to refuse.

    On the other hand IE allows the loading of ActiveX controls from
    JavaScript and call native code on them which runs completely outside
    the browsers control. Depending on the users security settings and how
    correct these have been implemented in IE this is certainly an area of
    concern. But that is only because IE deliberately implements this
    functionality. That makes IE dangerous, not JS. BTW: ActiveX object can
    also be loaded with HTML only.
     
    Silvio, May 2, 2014
    #17
  18. Roedy Green

    Silvio Guest

    On 05/02/2014 03:16 AM, Arne Vajhøj wrote:
    > On 5/1/2014 4:26 AM, Silvio wrote:
    >> On 05/01/2014 09:52 AM, Chris Uppal wrote:
    >>> Stefan Ram wrote:
    >>>> So, JavaScript is not mentionend in the press because it is
    >>>> a technical details of the browser, while Java is a
    >>>> freestanding product, not part of the browser. Because of
    >>>> this avoidance of the mentioning of JavaScript, some people
    >>>> do believe that JavaScript today has become more secure. But
    >>>> you can find the technical details I quoted above if you
    >>>> search for them.
    >>>
    >>> I think there's a lot of truth to that. A few years back, JavaScript
    >>> was still
    >>> viewed with suspicion (justifiably), and as such it was a "live issue"
    >>> and so,
    >>> when it was involved in security problems, it got mentioned. These
    >>> days many
    >>> people take it for granted, and are no more likely to think of it as
    >>> "contributing to" an exploit where it is used than the surrounding
    >>> HTML (if
    >>> any) is.

    >>
    >> That is because JavaScript IS part of the HTML page and it can not
    >> contain a security hole by definition. Only the browser displaying the
    >> page can.

    >
    > Today a browser typical comes with distinct:
    > - layout/render engine
    > - JavaScript engine
    >
    > And the two do not necessarily come from the same source.
    >
    > JS engine is still more tightly coupled with the browser, because
    > it cannot (as far as I know) be replaced by the user. It may even
    > be linked into the same executable as the rest. But somewhere
    > at the source code level it is distinct.
    >
    > Arne
    >
    >
    >


    The fact that browsers may choose to use common libraries changes
    nothing to the fact that it ultimately the browsers concern what these
    libraries do. Webkit could have a major security hole in it. Does that
    make HTML insecure?

    As soon as the JS engine would become a user replaceable plugin I agree
    things could become risky.

    But then we would have created exactly the same situation as we have
    with Java.
     
    Silvio, May 2, 2014
    #18
  19. Roedy Green

    Simon Lewis Guest

    Gene Wirchenko <> writes:

    > On Thu, 01 May 2014 10:26:25 +0200, Silvio <>
    > wrote:
    >
    > [snip]
    >
    >>That is because JavaScript IS part of the HTML page and it can not
    >>contain a security hole by definition. Only the browser displaying the
    >>page can.

    >
    > Oh, nonsense. Put an onclick= in an <a> tag to go to a different
    > URL than specified in the href=, and you have a security issue due to
    > JavaScript.
    >
    > [snip]
    >
    > Sincerely,
    >
    > Gene Wirchenko


    What total and utter ignorant bullshit.
     
    Simon Lewis, May 2, 2014
    #19
  20. On Fri, 02 May 2014 11:10:07 +0200, Silvio <>
    wrote:

    >On 05/01/2014 11:10 PM, Gene Wirchenko wrote:
    >> On Thu, 01 May 2014 10:26:25 +0200, Silvio <>
    >> wrote:
    >>
    >> [snip]
    >>
    >>> That is because JavaScript IS part of the HTML page and it can not
    >>> contain a security hole by definition. Only the browser displaying the
    >>> page can.

    >>
    >> Oh, nonsense. Put an onclick= in an <a> tag to go to a different
    >> URL than specified in the href=, and you have a security issue due to
    >> JavaScript.
    >>
    >> [snip]


    >Now that is nonsense. Why is it a security issue if that is what the
    >HTML page says it should do? It is something that can be discovered from
    >the page itself and anything the JS instructs the browser to do it can
    >decide to refuse.


    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.

    Why should someone have to examine the page code to see what will
    be done? Does that not suggest to you that someone might be trying to
    pull a fast one? That situation is a security issue.

    >On the other hand IE allows the loading of ActiveX controls from
    >JavaScript and call native code on them which runs completely outside
    >the browsers control. Depending on the users security settings and how
    >correct these have been implemented in IE this is certainly an area of
    >concern. But that is only because IE deliberately implements this
    >functionality. That makes IE dangerous, not JS. BTW: ActiveX object can
    >also be loaded with HTML only.


    This is also dangerous.

    There is more than one mine in this security minefield.

    Sincerely,

    Gene Wirchenko
     
    Gene Wirchenko, May 2, 2014
    #20
    1. Advertisements

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Michael Kintner
    Replies:
    0
    Views:
    1,107
    Michael Kintner
    Nov 30, 2003
  2. Ilias Lazaridis
    Replies:
    0
    Views:
    929
    Ilias Lazaridis
    Feb 1, 2005
  3. mcdeveloper
    Replies:
    1
    Views:
    4,689
    mcdeveloper
    Jun 13, 2006
  4. CRON
    Replies:
    25
    Views:
    223,403
    davidb
    May 29, 2015
  5. Mark Rae

    JavaScript or not JavaScript

    Mark Rae, Sep 5, 2006, in forum: ASP .Net
    Replies:
    36
    Views:
    1,565
    Paul Sture
    Sep 9, 2006
  6. Nathan Sokalski
    Replies:
    4
    Views:
    924
    PJ on Development
    Nov 8, 2007
  7. manish sahu
    Replies:
    3
    Views:
    1,352
  8. Isaac
    Replies:
    0
    Views:
    638
    Isaac
    Jan 20, 2011
Loading...