April 22, 2009 - 17:28 UTC - Tags: craftsman security testing escaping xss cross site scripting javascript
"That does not mean, however, that blocking < and > when ouputting user data in javascript isn't necessary", David said.
I was confused. How could those characters change the interpretation of a string?
"But for a javascript string, aren't quotes and backslash the only meta characters that can change the way it's interpreted?", I replied.
"Good question", David replied. "And while that is true for an isolated javascript, it is not true, when javascript and HTML are mixed in an HTML page. Consider the following..."
David grabbed the keyboard, and wrote the following HTML page:
"What do you think will happen here?", David asked.
So the attacker was able to insert a script tag in a javascript variable. That's it. That shouldn't matter, right? I opened the HTML in my browser. I was wrong...
"Ehm..", I replied intelligently.
"Now why do you think that happened?"
"I have no clue... How are we breaking out of the variable?", I asked.
"As mentioned, this happens because we are running javascript as a part of an HTML page. The HTML parser runs first, so what the browser ends up with, is something like this...", he replied, and opened the HTML in Firefox with the firebug add-in.
"HTML is in blue, javascript in black. The browser interprets the contents as some HTML, then an unclosed javascript variable 'a', then some script that creates a popup, then a quote and a semicolon as HTML - it's now outside the script tags, right - and last it sees an attempt to close a script tag that has never been opened. So as you see, we need to escape the < and > characters anyways. But we need to escape them for javascript instead of HTML. So we could do something like this."
Go back to: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, Part 8, Part 9
I was confused. How could those characters change the interpretation of a string?
"But for a javascript string, aren't quotes and backslash the only meta characters that can change the way it's interpreted?", I replied.
"Good question", David replied. "And while that is true for an isolated javascript, it is not true, when javascript and HTML are mixed in an HTML page. Consider the following..."
David grabbed the keyboard, and wrote the following HTML page:
<html>
<body>
<script>
var a = "</script><script>alert('xss');</script>";
</script>
</body>
</html>"What do you think will happen here?", David asked.
So the attacker was able to insert a script tag in a javascript variable. That's it. That shouldn't matter, right? I opened the HTML in my browser. I was wrong...
"Ehm..", I replied intelligently.
"Now why do you think that happened?"
"I have no clue... How are we breaking out of the variable?", I asked.
"As mentioned, this happens because we are running javascript as a part of an HTML page. The HTML parser runs first, so what the browser ends up with, is something like this...", he replied, and opened the HTML in Firefox with the firebug add-in.
"HTML is in blue, javascript in black. The browser interprets the contents as some HTML, then an unclosed javascript variable 'a', then some script that creates a popup, then a quote and a semicolon as HTML - it's now outside the script tags, right - and last it sees an attempt to close a script tag that has never been opened. So as you see, we need to escape the < and > characters anyways. But we need to escape them for javascript instead of HTML. So we could do something like this."
<html>
<body>
<script>
var a = "\x3C/script\x3E\x3Cscript\x3Ealert('xss');\x3C/script\x3E";
</script>
</body>
</html>Go back to: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, Part 8, Part 9
June 27, 2011 - 19:05 UTC
Lance
Lance
nice series, I like how you're covering the topic. Keep up the good work.
June 28, 2011 - 10:05 UTC
@Lance: Thanks. Will do.
November 17, 2011 - 13:05 UTC
Nice one - informative and enjoyable :).
About Erlend
Security guy with some thoughts on secure development.
Tag cloud
Categories
Blogroll
