| |||||||||||||
Gnash, Lightspark, and ShumwayGnash, Lightspark, and ShumwayPosted Nov 24, 2012 23:45 UTC (Sat) by intgr (subscriber, #39733)In reply to: Gnash, Lightspark, and Shumway by khim Parent article: Gnash, Lightspark, and Shumway
> What awful additional "security hazards" exist in C++?Undefined behavior. It's the number 1 reason why computers are so insecure today.
(Log in to post comments)
Gnash, Lightspark, and Shumway Posted Nov 25, 2012 10:01 UTC (Sun) by khim (subscriber, #9252) [Link] Undefined behavior is a problem, yes, but JS and PHP have it's own answer to his problem: non-transitive comparisons. Practically speaking these produce similar number of vulnerabilities (well, PHP has SQL-injections which, of course dwarf both C and JS problems, but we are not comparing PHP and C, but JS and C).
Gnash, Lightspark, and Shumway Posted Nov 25, 2012 14:02 UTC (Sun) by intgr (subscriber, #39733) [Link]
I agree that it's ugly, but... WTF, a similar number of vulnerabilities? I can see how PHP's comparison rules can cause vulnerabilities, but JavaScript is a great deal better.
On the other hand, NEARLY ALL security announcements these days are a result of undefined behavior in C code. In many cases, C undefined behavior leads to code execution, whereas that just cannot happen in JavaScript unless the coder explicitly calls eval() -- which is used almost never in real code.
Undefined behavior and intransitive comparisons aren't even in the same league.
Gnash, Lightspark, and Shumway Posted Nov 25, 2012 21:38 UTC (Sun) by khim (subscriber, #9252) [Link] I agree that it's ugly, but... WTF, a similar number of vulnerabilities? I can see how PHP's comparison rules can cause vulnerabilities, but JavaScript is a great deal better. No, it's not. There are about bazillion vulnerabilities found on web sites every day. I mean, XSS, data leaks, etc. Vulnerabilities which affect the web application itself, not the rest of the system. Rest of the system is not affected by JS vulnerabilities because web apps are sandboxed. Well, you can sandbox C++ application, too, so what's the big deal? On the other hand, NEARLY ALL security announcements these days are a result of undefined behavior in C code. Well, sure. That's because security-sensitive unsandboxed applications are written in C++. How many of them are written in JavaScript? In many cases, C undefined behavior leads to code execution, whereas that just cannot happen in JavaScript unless the coder explicitly calls eval() -- which is used almost never in real code. Is this a joke or are you really that dumb? Javascript programs have bazillion places where eval() can be injected. Do you add some data from user to the page? Thank you, thank you - that's eval right there, just add <script></script>. Do you change innerHTML? Thank you, thank you - that's another place for eval, just add "<script></script>". And so on. Javascript programs are actually more vulnerable then their C++ counterparts, but most problems are contained because of browser's sandbox. Well, you can add sandbox to C++, so what's the big deal?
Gnash, Lightspark, and Shumway Posted Nov 26, 2012 9:21 UTC (Mon) by intgr (subscriber, #39733) [Link]
Dafuq? In the last post you were trying to convince me how non-transitive comparisons in JavaScript *the language* is the worst security flaw ever.
Now you suddenly changed topic to HTML and web technologies and claim I'm "dumb" for not reading your mind? Remember, you were comparing C++ with JavaScript, not C++ with HTML or "the web" (does that even make sense?).
JavaScript is also used in Node.JS, Mozilla's XUL GUI, Gnome 3, PostgreSQL stored procedures, etc etc. None of these are vulnerable to the HTML vulnerabilities you describe.
And don't get me wrong -- I certainly agree that the way how web applications and JavaScript interact with HTML is a very generous place for security problems. But these aren't a problem of JavaScript *the language*.
> Do you change innerHTML?
|
|||||||||||||