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 ⚥