Types of XSS Attacks

[00:00:00]
>> Mike North: So there are three plus one kinds of cross-site scripting attack categories. I say three plus one cuz the last one here is debatable, like two or three penetration testing firms talk about this last one. I'm going to present it to you as a fourth category cuz it's interesting.

[00:00:19]
So stored cross-site scripting attacks, that means you're adding something to a database, right. I am registering an account and my user name has a script tag in it, that is a stored record. And so that data ends up living a long time, and it gets pulled out of the database for the purpose of rendering pages.

[00:00:39]
And so that is how that attack looks. A reflected cross-site scripting attack means that a temporary response from a server, you can trick that into having some code that executes on the page. So imagine if it was a validation error message saying, I'm sorry, you may not sign up for an account because script tag terrible is not a valid username, and it would allow that to execute.

[00:01:09]
DOM based cross-site scripting attacks, they don't involve a server, so this would be like a query param being rendered without any filtering of any kind, no filtering, no escaping into the DOM. Blind cross-site scripting, you could argue that this is basically the same as stored cross site scripting, but it is sort of an interesting subcategory.

[00:01:33]
So here's what that would look like. You worked really hard to shore up your public facing app. But I can create some logging out of that public facing app. You're tailoring the logs, maybe you're bringing it into a log aggregator. It's an internal project at your company. And I can basically trick the app into logging something out, that when it's read by your internal app, which likely gets far less scrutiny, far less protection then your public facing stuff.

[00:02:09]
Now I can basically get an app that I can't see to run this malicious code. And what's interesting about these is they can actually, the attack can happen years after that log gets put into place, right. So this would be, and it takes advantage of the fact that all of our internal apps, I know for a fact having worked with teams at Yahoo, at LinkedIn, at Microsoft, at Facebook, at Google.

[00:02:36]
When they have an internal app, there is far less review, far less scrutiny, you can take shortcuts, they have fewer tests, just because that's the mindset is that's for them. But if you're sucking public data into it, with that data can come, that is a vector for an attack.

[00:02:55]
And if you can trick that app into evaluating something, now you're attacking an app that you didn't even know was there. And you can take advantage of usually escalated, usually you have credentials to be able to do interesting things there because you are behind the firewall, right. And you usually have the freedom to read all data across the system that the application didn't have access to.