- From: Tab Atkins Jr. <jackalmage@gmail.com>
- Date: Mon, 20 Jun 2011 11:01:12 -0700
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