[jdaley]

I don't get it. His first example is that since the string replace method takes a callback as its second argument, you can use it to run code. So if you happen to find an app that injects unescaped user input into Javascript, you could enter the string alert(1)".replace(/.+/,eval)// and have it run the alert.

But if the app is injecting unescaped user input into code, wouldn't a simple ";alert(1);// achieve the same thing? Why do you need to be tricky?

The examples seem to be based on the premise that web apps commonly forgo the simple escaping of quotes, and instead implement a complex parsing and analysis of user input as code to identify malicious statements, which can be defeated as long as you obfuscate enough.

[raganwald]

The examples seem to be based on the premise that web apps commonly forgo the simple escaping of quotes, and instead implement a complex parsing and analysis of user input as code to identify malicious statements, which can be defeated as long as you obfuscate enough.

He gives an example of such a system.

The larger issue is that the premise behind the design of web browsers is itself flawed with respect to displaying user content. As long as it is acceptable to execute JavaScript that is embedded directly in a web page (such as within script tags or as the target of an HREF), and as long as you are also trying to display user-supplied content, security is going to be extremely fragile.

We are perpetually one careless oversight away from pwnage, and we are vulnerable to mistakes that might creep into our libraries as well as into our own code.