W3C home > Mailing lists > Public > whatwg@whatwg.org > January 2013

Re: [whatwg] Script-related feedback

From: Glenn Maynard <glenn@zewt.org>
Date: Mon, 7 Jan 2013 22:09:43 -0600
Message-ID: <CABirCh9wqSne+vibFPUkcpLs-6b7pyW2DiS1+nXc2K5TcSOxZA@mail.gmail.com>
To: Adam Barth <w3c@adambarth.com>
Cc: whatwg@whatwg.org, Ian Hickson <ian@hixie.ch>
On Mon, Jan 7, 2013 at 7:20 PM, Adam Barth <w3c@adambarth.com> wrote:

>  > This could even be done in a backwards-compatible fashion by having the
> > syntax to do this be something that down-level clients ignore, e.g.:
> >
>


> >    /*@BREAK*/
> >
> > ...or some such.
>
> That approach is an in-band signal, which means it's vulnerable to
> injection attacks.  For example, consider a server that produces a
> JavaScript file of the following form:
>
> [...]
> var userData = "<?php echo santize($userData) ?>";
> [...]
>
> Currently, the rules for sanitizing using input are relatively
> straightforward (essentially, you just need to worry about a few
> special characters).  However, if we implemented an in-band signaling
> we might well break these sanitation algorithms.
>
> To make this secure, we'd probably want some sort of randomized
> delimiter (perhaps declared via a pragma at the top of the file), but
> then we would have just re-invented multipart/mixed.
>

The suggestion was the comment /*@BREAK*/, which the string literal
"/*@BREAK*/" wouldn't match, being a string token, not a comment, right?

-- 
Glenn Maynard
Received on Tuesday, 8 January 2013 04:10:06 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:12 GMT