In Defense of HTML5(thesecuritypractice.com)
thesecuritypractice.com
In Defense of HTML5
http://www.thesecuritypractice.com/the_security_practice/2012/11/in-defense-of-html5-1.html
3 comments
You could attach ActiveX controls to CSS properties?!? Gott in Himmel, what manner of madness was this?
The feature was called DHTML Behaviors. Here's an introduction from 2000:
http://msdn.microsoft.com/en-us/subscriptions/ms531079(v=vs....
Back then everything needed to tie into Win32 somehow, so of course they introduced Binary Behaviors:
http://msdn.microsoft.com/en-us/library/aa753685(v=vs.85).as...
"A Binary Element Behavior (or binary behavior) is a Component Object Model (COM) object loaded by a Web page and assigned to an element type in the page—either a custom element tag or an existing HTML tag. The COM object is then able to customize the behavior of the tag by implementing the IElementBehavior interface. Customizations include any options available to scripted behaviors and more advanced behaviors such as Windows Graphics Device Interface (GDI) rendering.
Because a binary behavior is a COM object, a binary behavior can execute any code after loading. For that reason, the security profile of a binary behavior is very similar to that of a Microsoft ActiveX control, and the same security considerations apply. Binary behaviors, like ActiveX controls, run with the security credentials of the user running the browser process. This means a binary behavior cannot only render to the screen, it can also potentially access local files, configuration settings, or network resources. Accessing a page that loads a malicious binary behavior presents a considerable security risk."
http://msdn.microsoft.com/en-us/subscriptions/ms531079(v=vs....
Back then everything needed to tie into Win32 somehow, so of course they introduced Binary Behaviors:
http://msdn.microsoft.com/en-us/library/aa753685(v=vs.85).as...
"A Binary Element Behavior (or binary behavior) is a Component Object Model (COM) object loaded by a Web page and assigned to an element type in the page—either a custom element tag or an existing HTML tag. The COM object is then able to customize the behavior of the tag by implementing the IElementBehavior interface. Customizations include any options available to scripted behaviors and more advanced behaviors such as Windows Graphics Device Interface (GDI) rendering.
Because a binary behavior is a COM object, a binary behavior can execute any code after loading. For that reason, the security profile of a binary behavior is very similar to that of a Microsoft ActiveX control, and the same security considerations apply. Binary behaviors, like ActiveX controls, run with the security credentials of the user running the browser process. This means a binary behavior cannot only render to the screen, it can also potentially access local files, configuration settings, or network resources. Accessing a page that loads a malicious binary behavior presents a considerable security risk."
The same that now are allowing WebGL Shaders to be attached to CSS properties:
http://www.w3.org/Graphics/fx/wiki/CSS_Shaders_Security
http://www.w3.org/Graphics/fx/wiki/CSS_Shaders_Security
I appreciate the cynicism as much as anyone, but to be fair:
A. The two groups are in reality about as disjoint as any sets of CSS functionality implementers could be.
B. The premise of WebGL is that it implements a security boundary. ActiveX did not.
A. The two groups are in reality about as disjoint as any sets of CSS functionality implementers could be.
B. The premise of WebGL is that it implements a security boundary. ActiveX did not.
Maybe things were worse ten years ago, for those that remember. But I remember five years ago, and things were better then. ActiveX was dead in the water; it was browser+flash+java.
Java was designed from the ground up to be secure. It had a ponderous standards process (though not quite as slow as the W3C) and got new features years after other languages, but the result was a rock-solid environment. You still occasionally see flaws that let things escape the sandbox, but only very rarely. And while java-the-language gets larger, the JVM itself is simple and well-specified; the attack surface is the eye of a well-defined needle that you have to thread to go from the managed JVM into the OS outside.
Flash didn't have the benefit of so much design and specification, but the sheer pressure of attacks forced adobe to reach something close to Java's level of security. It's certainly possible to form a clear separation between the "VM" and "sandboxed" areas of Flash. Not to mention that you had the option, as many "advanced" computer users did, of disabling flash except for some whitelisted sites - at which point you could be sure, since it was a separate process, that no flash code could possibly be used to attack your system.
Maybe IE itself was a badly-written program and is now a better one - we'll have to take the author's word for that - but that's an argument for Microsoft writing better code, not for HTML5.
Retrofitting security onto an existing codebase is basically impossible. So no, I really would sooner trust HTML4+Java+Flash - where the active behaviours are fully decoupled from the browser, and Java at least has a well-designed sandbox that was there from the start - over HTML5, where you have this enormous monolithic codebase dating from 1993 and full of all kinds of behaviours.
Java was designed from the ground up to be secure. It had a ponderous standards process (though not quite as slow as the W3C) and got new features years after other languages, but the result was a rock-solid environment. You still occasionally see flaws that let things escape the sandbox, but only very rarely. And while java-the-language gets larger, the JVM itself is simple and well-specified; the attack surface is the eye of a well-defined needle that you have to thread to go from the managed JVM into the OS outside.
Flash didn't have the benefit of so much design and specification, but the sheer pressure of attacks forced adobe to reach something close to Java's level of security. It's certainly possible to form a clear separation between the "VM" and "sandboxed" areas of Flash. Not to mention that you had the option, as many "advanced" computer users did, of disabling flash except for some whitelisted sites - at which point you could be sure, since it was a separate process, that no flash code could possibly be used to attack your system.
Maybe IE itself was a badly-written program and is now a better one - we'll have to take the author's word for that - but that's an argument for Microsoft writing better code, not for HTML5.
Retrofitting security onto an existing codebase is basically impossible. So no, I really would sooner trust HTML4+Java+Flash - where the active behaviours are fully decoupled from the browser, and Java at least has a well-designed sandbox that was there from the start - over HTML5, where you have this enormous monolithic codebase dating from 1993 and full of all kinds of behaviours.
The new Chrome and sandboxed IE web browsers seem to have a better track record on security than Oracle Java after a decade or more.
I guess the main lessons here are 1) you need your web platforms in another sandbox for defense in depth, and 2) you won't get there without obsessive attention to security, proactive fuzzing, and luck.
I guess the main lessons here are 1) you need your web platforms in another sandbox for defense in depth, and 2) you won't get there without obsessive attention to security, proactive fuzzing, and luck.
However I used to run IE6 + Flash on WinXP without any anti-virus and never remember any significant problems with malware on my computer (witnessed a lot on other people's though).