JavaScript for hackers(dev.opera.com)
dev.opera.com
JavaScript for hackers
http://dev.opera.com/articles/view/opera-javascript-for-hackers-1/
5 comments
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.
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.
Here's something I didn't know - you can use unicode escapes outside of strings. Code like `\u0061\u006c\u0065\u0072\u0074(1)` translates to `alert(1)` and runs just fine.
Reddit had a fun challenge where they did exactly this for their frontend position.
Its actually possible to encode your js entirely to whitespace, which is, imho, far more amazing.
Its actually possible to encode your js entirely to whitespace, which is, imho, far more amazing.
>JavaScript doesn't know the result of a function until it is executed, and obviously it has to call the function to return the variable type.
> +alert(1)--
That's a particularly poor example. There's no reason to expect `alert` to run there (in current Chrome, it doesn't) - a function can't return an l-value, so you don't have to wait for the return value to determine that it'll be invalid.
Also, I'm not sure what the unary + is supposed to achieve - it has the same precedence as post-decrement, with right to left associativity, so knowing that the post-increment will fail shows us that the + will never run.
> +alert(1)--
That's a particularly poor example. There's no reason to expect `alert` to run there (in current Chrome, it doesn't) - a function can't return an l-value, so you don't have to wait for the return value to determine that it'll be invalid.
Also, I'm not sure what the unary + is supposed to achieve - it has the same precedence as post-decrement, with right to left associativity, so knowing that the post-increment will fail shows us that the + will never run.
This doesn't work in Apple's JSC either.
This article is dated 2009. Are these still security holes in Opera?
These are more issues with how Javascript is handled on the web. I'd imagine that js sanitizers have gotten more sophisticated so the callback (first) example may be a bit weak; if you're accepting code from an unknown source, even if you're filtering it first, you're gonna have a bad time.
Opera using Chromium (v8) rather then Carakan. And these aren't really security holes so much as Javascript quirks that you should watch out for.
[deleted]
I doubt. I would like to go through the release notes.
This article is written by Gareth Heyes. He has a blog about JavaScript weirdness and hacking:
http://www.thespanner.co.uk/
http://www.thespanner.co.uk/
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.