[whatwg] Basic defense at the client against common XSS attack types

Thanks for the clarification; had completely overlooked the @srcdoc attribute, but just read up on it and it seems like a far better solution to the whole issue.

Cheers,

Jacques


-----Original Message-----
From: Tab Atkins Jr. [jackalmage@gmail.com] 

On Mon, Jun 20, 2011 at 10:47 AM, Jacques Jongerden <jacques_jongerden at hotmail.com> wrote:
> I'd like your thoughts on an idea concerning a basic defense mechanism 
> on the client against several types of common XSS attacks, 
> complementing the existing array of (mainly server-side) security 
> measures. Now I'll be the first to admit that this is hardly my area 
> of expertise, so I could really use some feedback on the feasibility 
> of this proposal and perhaps it might serve as a source of inspiration 
> to others that are more versed in the subject matter.
>
> The concept itself is simple: enable web developers to delimit parts 
> of an HTML document that ought not declare scripting elements. The 
> browser would then not execute any scripting content that originates 
> within the delimited area. The execution is somewhat tricky though. A 
> custom attribute (or element for that matter) would not cut it; an 
> attacker could simply inject a closing tag for the decorated element 
> together with the rest of the malicious payload.
>
> One way to tackle the issue is to use an element with a randomly 
> generated (at the server) token value that is repeated in the closing 
> tag. Because the attacker cannot predict the value of the token at the 
> time of injection, the block restricting the use of script content 
> cannot be escaped. Unfortunately it might require a new type of 
> construct, for example similar to the way conditional comments are 
> defined within Internet Explorer. Consider the following example:
>
> <!doctype html>
> <html lang="en">
> <head>
>   <meta charset="UTF-8">
>   <title>Some page that includes user input</title>
>   <link rel="stylesheet" href="css/style.css">
>   <script src="js/script.js"></script> </head> <body>
>   <div id="container">
>
>      <div id="main" role="main">
>         <article><!--[start-ignore-script:MyToken]-->
>
>            <!-- content here includes user input; the browser should 
> ignore
>                 any scripted content originating in this area, 
> including
>                 script blocks, event handlers, css expressions, etc. 
> -->
>
>         <!--[end-ignore-script:MyToken]--></article>
>      </div>
>
>      <script type="text/javascript">
>
>         /* This script is executed though, because the element is not
>            inside of a restricted execution area. */
>
>      </script>
>
>   </div>
> </body>
> </html>

This is already handled in HTML by sandboxed iframes.  The @seamless and @srcdoc attributes make the use of iframes less painful.  Your page would look like:

<!doctype html>
<html lang="en">
<head>
  <meta charset="UTF-8">
  <title>Some page that includes user input</title>
  <link rel="stylesheet" href="css/style.css">
  <script src="js/script.js"></script>
</head>
<body>
  <div id="container">
     <div id="main" role="main">
       <iframe sandbox seamless srcdoc="[user input here, with quotes and ampersands escaped]"></iframe>
     </div>
     <script type="text/javascript">
        /* This script is executed though, because the element is not
           inside of a restricted execution area. */
     </script>
  </div>
</body>
</html>

If you would like some context about why this solution was eventually chosen, and why approaches like what you outline were rejected, search the mailing list archives for the word "sandbox".

~TJ

Received on Monday, 20 June 2011 11:40:43 UTC