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

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:01:12 UTC