VK said:
As I pointed earlier, this is not an exploit of a particular bug
on a particular platform. This is an exploit of the core mechanics
of any ECMAScript-compliant code parser.
Nonsense. It relies entirely on a script parser electing not to impose
the syntax rules as specified in ECMA 262.
The curious ones may read through
the section 7 of ECMAScript 3rd ed.
And they easily may understand it better then you do. for example, where
ECMA 262 first edition says:-
Note that a LineTerminator character cannot appear in a string literal,
even if preceded by a backslash \. The correct way to cause a line
terminator character to be part of the string value of a string literal
is to use an escape sequence such as \n or \u000A.
- the second edition says:-
Note that a LineTerminator character cannot appear in a string literal,
even if preceded by a backslash \. The correct way to cause a line
terminator character to be part of the string value of a string literal
is to use an escape sequence such as \n or \u000A.
- and the third, and current, edition says:-
NOTE: A LineTerminator character cannot appear in a string literal, even
if preceded by a backslash \. The correct way to cause a line terminator
character to be part of the string value of a string literal is to use
an escape sequence such as \n or \u000A.
- they may realise that like terminators are _explicitly_ forbidden form
appearing in a string literal, even when preceded by a backslash
character.
This way any ECMAScript-compliant parser will demonstrate
this behavior - or it is not ECMAScript-compliant.
Nonsense. This cannot be expected to work in any ECMA 262 compliant
script engine.
This is why "backslashed strings" are equally supported by say
IE, Firefox, Opera and by going back in the history by Netscape
4.x, 3.x and 2.x
That is just 3 script environments.
Respectively "supported" is not really a correct term as there
is not an extra feature to support here. "Vulnerable" would be
more correct by too scary sounding
You have never been qualified to judge.
It also mean that the "hack" term is not fully applicable here.
Why not? When a construct cannot be expected to work at all using it
because it has been observed to work in some environments is a "hack".
It is no more hack then say return some other object from
the constructor instead of [this] or placing anonymous function
expression as with() argument. "Exploitation of mal-documented
engine features" is more suitable.
You just don't understand the specification, so you cannot judge what is
"mal-documented" and what is not. However, the note about line
terminators in string literals seems fairly unambiguous to me.
I am not propagandizing backslashed strings usage.
You are suggesting that it is a credible subject for consideration, when
it is something that should never have been expected to work, and so
should never have been attempted in a general context.
I just want to make clear the nature of this phenomenon,
You have already miss-attributed it.
because in a few follow up posts it was implicitly suggested
that it is some IE/JScript-only bug,
Not in my experience.
like "since it works in strings in IE".
It "works" for all existing/ever existed UAs with javascript
support.
It does not work in the NetFront browser, to name just one (and one is
sufficient to prove the assertion "It "works" for all existing/ever
existed UAs with javascript support" as being false). NetFront claims to
have an ECMA 262, 3rd Ed. compliant script engine, and its regarding an
ECMAScript syntax error as a syntax error does not contradict that.
Richard.