- From: Glenn Maynard <glenn@zewt.org>
- Date: Mon, 7 Jan 2013 22:09:43 -0600
- 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 UTC