<div class="gmail_quote">
<div>Hi! I am a new member of this mailing list, and I wish to contribute with a couple of specific requirements that I believe should be discussed and perhaps implemented in the final specification. I am unsure if this is the correct place to post my ideas (or if my ideas are even new), but if it is not, then I am sure somebody will instruct me. :) One person told me that the specification was finished and no new features would be added from now on - but hopefully that is not true.</div>
<div> </div>
<div> </div>
<div>The challenge:</div>
<div> </div>
<div>More and more websites have features where users can contribute with user generated content - often in the form of audio, video, images or wiki-articles. An older type of content contribution is normal text such as posts in a discussion forum, a mailing list such as this and comments on blog articles.</div>
<div> </div>
<div>A major challenge for many web developers is validating "untrusted" content such as the message body of a blog comment. Unless the developer has a flawless and future proof algorithm for ensuring that the message body does not contain any script, web developers have to resort to text only - or bbCode-style markup languages to allow users to post text content with richer formatting. If the developer wants to enable rich formatting using bbCode, it also needs fairly advanced methods of ensuring that no scripts are executed. Consider this bbCode example: [img]some_image.jpg'onmouseover=maliciousScript()[/img]. The bbCode parser must ensure that there is absolutely no method of injecting scripts in user posts - and that is very difficult when at the same time there exists parsing errors in browsers. The example could easily be validating by not allowing apostrophes or quotation marks in urls - but then we have multiple entities that could be used: ' or '. To make matters worse, some browsers parse ' which is an incomplete html entity and all these variations must be considered by the bbCode parser author.</div>
<div> </div>
<div>Another problem which makes future proofing this type of security is that standards evolve. A few years ago you could safely allow users to apply css-styles to tags. Example bbCode tag [color=blue]Blue text[/color] would be translated to <span style='color: blue'>Blue text</span>. In this example an exploit could be [color=expression(maliciousCode())]Text[/color]. When the algorithm was made, it was considered secure, since no script could ever be executed inside a style attribute. With the invention of expressions and behaviours etc the knowledge required by web developers are ever increasing, and web developers have to review all old code whenever new technologies emerge - because what once was secure suddenly is not secure anymore.</div>
<div> </div>
<div> </div>
<div>One solution:</div>
<div> </div>
<div><htmlarea>User generated content</htmlarea></div>
<div> </div>
<div> </div>
<div>No scripts would ever be allowed to be executed inside this tag. Malicious users could potentially submit "</htmlarea> unsafe content <htmlarea>" and get around this. There are as I can see it two solutions to this:</div>
<div> </div>
<div>User generated content inside the tag must be escaped using html entities (but still rendered as html by the user agent), or the author must prevent users from submitting the string "</htmlarea>" and all possible variations of the tag.</div>
<div> </div>
<div>If the first solution is used, then browsers should display a strong security warning if unescaped content is seen between htmlarea-tags on a website (to educated web developers).</div>
<div> </div>
<div> </div>
<div>A sidenote: The tag name I chose is based on the <textarea>-tags which should also be entity escaped to prevent users from inserting the text </textarea>. This currently breaks a lot of web pages - so perhaps a strong security warning is in place if unescaped content is found after the textarea start tag also?</div>
<div><br clear="all"><br>-- <br>Best regards / Med vennlig hilsen<br>Frode Børli<br>Seria.no<br><br>Mobile:<br>+47 406 16 637<br>Company: <br>+47 216 90 000<br>Fax: <br>+47 216 91 000<br><br><br>Think about the environment. Do not print this e-mail unless you really need to.<br>
<br>Tenk miljø. Ikke skriv ut denne e-posten dersom det ikke er nødvendig. </div></div><br><br clear="all"><br>-- <br>Best regards / Med vennlig hilsen<br>Frode Børli<br>Seria.no<br><br>Mobile:<br>+47 406 16 637<br>Company: <br>
+47 216 90 000<br>Fax: <br>+47 216 91 000<br><br><br>Think about the environment. Do not print this e-mail unless you really need to.<br><br>Tenk miljø. Ikke skriv ut denne e-posten dersom det ikke er nødvendig.