> Is your address really street"/><script>doStuff();</script>?

Cross-Site Scripting attacks are tremendously prevalent, which I find surprising because it is an easy problem to detect and to remediate. There are even a lot of decent mitigation alternatives out there as well.

What is Cross-Site Scripting (or XSS, if you prefer)?

Cross-Site Scripting occurs whenever someone else is able to run JavaScript within your site. This could, of course, happen if someone can upload HTML files (containing scripts), but the dominating attack vector is regular input fields.

For example, a web application might have a search feature:

/search.php?search=test

The resulting page might then contain:

<h1>Search results for: test</h1>

From this basic example we can assert that the user is in control of two things regarding the content:
1. What search results are present on the search page
2. A section of the body is directly correlated to the search term (parameter search)

So searching for "asdkhafohgsoudghs" would possibly yield zero results. Searching for "e" might match every single entry. That makes sense, but is not that useful to us at the very moment.

The fact that whatever we supply as the search parameter is directly reflected is very interesting. The intended behaviour is to reflect the search query, but what if we enter HTML?

search.php?search=test<img src=test/>

It would probably look something like:

So we managed to inject a broken image by entering the corresponding HTML. Nice. Now, what about that Cross-Site Scripting?

search.php?search=test<img src=test onerror="alert(':)')"/>

At this point, we have the ability to inject and run JavaScript.

So why is this a bad thing?

> ... After all, it's just alert boxes!

Everyone likes to bash JavaScript for being horrible. While some (most?) criticism is legitimate, keep in mind that it's possible to do pretty much anything once you can run it.

There are some restrictions in place, one of them being that some stuff can only be performed within the current domain. That's why we need to inject the scripts on the victim site. Otherwise it would be REALLY easy wreak havoc on the internet.

Because when you have access to inject JavaScript, you can:
1. Steal the cookies, nom nom
2. Hijack the current session (either cookies or other tokens)
3. Modify the cookies, if that is useful
4. Modify or completely replace the current page
5. Steal credentials, keystrokes, and so on
6. Redirect the users

What flavour do you want?

XSS comes in different varieties, as is to be expected.

Reflected Cross-Site Scripting
So the example we had above was a reflected cross-site scripting. You input something, the site reflects it, and the attack triggers. If you do this attack, then you XSS yourself. Not that effective.

Usually, you would want to forge some URL that you can send to a victim, preferably disguise it as well. In some cases (e.g. POST-request) you need to leverage a CSRF-attack in order to get the script in there.

Persistent Cross-Site Scripting
While there is no difference for what you can do, persistence makes further attacks easier. Depending on where the script is presented, it might also make exploitation easier.

For a Persistent Cross-Site Scripting to occur, a script that is injected once must be stored and then consistently be presented by the web application. For example, a user might change their display name to "Derp<script>...</script>"

Semi-Persistent Cross-Site Scripting
Reflected and Persistent pretty much had a baby. Important to note here is the scope of the attack, for how long is the attack persistent? X page loads? X minutes? Per session? Day? Until something else happens?

DOM-Based Cross-Site Scripting
I'll leave this for another day, but you could of course go ahead and read OWASPs stuff!
https://www.owasp.org/index.php/DOM_Based_XSS

Essentially, code can be supplied to and run within the front-end application, with no server interaction.