In this email I sketch my personal view on the future of HTML, I do not<br>claim I have invented a solution to all security issues on the web; I merely <br>hope that this email will be the starting point of a real discussion on web-
<br>security instead of browser security. Since this is my first email to any of<br>these mailinglists, please correct me if I sent this to the wrong one.<br><br><br>The current design of the integration of JS and HTML is fundamentally flawed.
<br>One of the major issues which should be learned from a long history of buffer <br>overflows etc is that one should never mix up data and code.<br>The consequences of this design flaw show itself by the XSS-exploits reported
<br>on a daily basis. In my view the browser/standards developers can do 2 things:<br> - They can ignore it and state that it is a problem of the web-developers<br> - They can fix it in a similar manner the "No Exec" is implemented in current
<br> CPU architectures.<br><br>The first approach will never work: The average webdeveloper simply cannot <br>oversee possible XSS exploits, this method was attempted for numerous years <br>in the buffer overflow world... IMHOI the average webdeveloper is less
<br>skilled then the average aplication developer.<br><br>The second solution might seem an utopia, but I think this is realizable. I <br>hope in 2/5 years browsers will have a special "Secure Mode" which ensures
<br>webdesigners that their website is not vulnerable to XSS in these browsers.<br><br>The first step in implementing this "No Exec" strategie is that there needs <br>to be a clear distinction between JS and HTML. This can be achieved quite easily
<br> by preventing any JS operation inside a HTML/CSS file. All stuff related to <br>events and code executions should be in JS files.<br><br>Thus instead of creating<br><br>index.html<br> <a href=# onclick="DoFunction()" id=123 >
<br><br>we write <br>index.html<br> <a href=# id=123 ><br><br>index.js<br> document.getElementById('123').onclick="DoFunction()"<br><br>All JS functions in HTML files should not be executed, the JS-code should be rendered visually
<br><br><br>The next step is that we make a clear distinction in our DOM tree which code is
<br> executable and which is not. We might even consider creating 2 trees, one with<br> the executable code in it (retrieved from JS files), the other one with the <br>data (HTML, CSS files). None of the objects in the data tree should ever be executed.
<br><br>At this moment I cannot oversee the exact consequences
<br>and limitations on the communications between these 2 trees.<br><br>Most XSS exploits might be prevented by this design, but there are still some <br>debatable issues:<br> - What if JS uses eval on a data block?<br>
* Prohibit the use of eval?<br> - What if the JS file contain some user generated content? <br> e.g. a PHP script will generate the JS code and write a line like <br> JSusername=$PHPusername;<br><br> If I select the username <alert(hello)> then this script is still
<br> vulnerable to XSS<br><br> * A solution might be that only specially-signed scripts can be run in this<br> "Secure mode"; One can get this signature for free, but has to wait for 2<br> hours. In practice this will prevent people from doing these nasty
<br> serverside things.<br> <br> The solution to this practical username example would be to include a <br> special div <div id=username>$PHPusername</div> and then read the content <br> of the div in the JS file.
<br><br><br>One might wonder how to integrate this into the currently available websites. I<br>think a opt-in option would be sufficient; this might be taken into account into HTML5, <br>but we have to give the web-developer some candy for doing the effort of adjusting
<br>his website. The new tool we will give him is the cross domain XmlHttpRequest.<br>Since we can exclude all XSS attacks most of the fundamental problems with <br>cross site XHR are automatically solved.<br><br>Separating code and data will simplify the parsers for both filetypes and thus
<br>improve render performance and maybe even decrease render bugs...<br><br>Regards,<br>Pieter<br><br>