March 10, 2009 - 19:36 UTC   -   Tags: craftsman security testing escaping xss cross site scripting When I came into the office the next day, I immediately started rewriting the application to use prepared statements. An hour later I was done, and called Mr. X to go through it. By lunch time we had co-written the documentation, and code and documentation was sent over to the customer.

During lunch, David, a guy from the pentesting team, and Mr. X discussed a new cross site scripting bug on Facebook. I couldn't quite follow all the details, and David must have noticed, because he came by my office after lunch.

"Hi. One of your next tasks will be to check an application for cross site scripting bugs, and I thought it would be a good idea to bring you up to speed", he said.
"Thanks, I'd like that", I replied.
"So as you probably now, cross site scripting is often referred to as XSS, and is one of the most common mistakes developers make according to the OWASP Top 10."
"Yes, I some articles about it last night. It seems to have a lot in common with SQL-injection".
"That's true. Cross site scripting is also a meta character problem, so they belong to the same category. Let's start out with an example. Consider a search field on a page."
He grabbed my computer and wrote a small .jsp page.

"Now if I search for test, the page will display the following"
<div>You searched for 'test'</div>
"So the search term is replied back in the response. If I include some HTML-tags in the search terms, we get back something like this"
<div>You searched for '<h1>test</h1>'</div>
And in the browser it looked like this:

You searched for '
test
'

"I see", I said, "but why is it called cross site scripting. We are injecting HTML meta characters to add HTML, so shouldn't it be called HTML injection?"
"That's correct", David replied. "This is actually HTML injection. But HTML injection is usually a sign of a cross site scripting bug. But to fully explain the name, we need to talk about the same origin policy. Are you familiar with it?"
"Yes", I replied, "some of the developers at my old company referred to it as the cross site problem, because it blocked them from accessing data in one window or frame from another".
"Haha! Yes, that's very common. The same origin policy is very important in respect to web application security. It basically says that javascript is restricted to accessing frames and windows that are on URLs that have the same hostname, port and protocol. So a page fetched over https, cannot access a page fetched over http."
"But I thought it was possible to access frames on the same domain", I objected.
"Yes, that's true. If you set document.domain in both frames or windows, you can allow javascript to access data from a URI pointing to another server on the same domain. Currently this is not possible for AJAX requests, but there is going to be a change there as well. If we didn't have the same origin policy, an attacker would be able to fully remote control your browser as soon as he could trick you into visiting some site he controlled.
But back to cross site scripting. The reason why it's called cross site scripting, is because we are circumventing the same origin policy, by exploiting HTML injection or similar flaws to insert javascript code. We can insert script directly as a part of the payload, or we can insert a script tag pointing to the attackers server. As I'll show you later, we can also have cross site scripting without HTML-injection."

Continue to part 9...

Go back to: Part 1, Part 2, Part 3, Part 4, Part 5, Part 6, Part 7