Loading ...
Sorry, an error occurred while loading the content.

282Re: [caplet] Code that lexes differently in ES3 vs ES3.1

Expand Messages
  • Mike Samuel
    Feb 10, 2009
      2009/2/10 David-Sarah Hopwood <david.hopwood@...>:
      > Marcel Laverdet wrote:
      >> From what I remember this started out as a bug in IE and then Firefox
      >> followed suit for compatibility which left the other browsers with no
      >> choice. I can't find the original bug but `/[/]/` only started parsing
      >> in FF1.5, in FF1.0 it would throw a syntax error.
      >> You could throw out any malformed regexp literals (any that differ
      >> between ES3 \ ES3.1) which is a fairly small subset and you would be ok.
      > I could, if I knew that there were no more bugs like this. Note that
      > lexical confusion attacks of this kind can easily be turned into complete
      > breaks of a subset implementation:
      > [ /[/]/ /alert('toast')]/ + 1
      > Verifier sees valid, harmless code:
      > [ new RegExp("[") ] / new RegExp("alert('toast')]") + 1
      > Browser runs exploit code:
      > [ new RegExp("[\/]") / alert('toast') ] / +1
      > Since there's no way that I could reliably have known about the IE lexer
      > bug, it's just too risky.
      > Anyone know of other bugs where common JS implementations lex or parse
      > valid ES3 code with a different meaning than specified? (The only one
      > I can think of right now is \v in IE, but at least that doesn't result
      > in a parse with a different structure.)

      Plenty. But I suspect you know of them. There's conditional
      compilation comments /* @cc_on */,
      and there's the newlines in block comments thing return /*
      */ foo();
      and there's format control characters between pairs like */ and \".
      There's other tricks you can do with \u escapes in identifiers and NUL
      and BOM characters in source.

      > --
      > David-Sarah Hopwood ⚥
    • Show all 13 messages in this topic