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

Mon Jun 20 11:01:12 PDT 2011

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