They see the worst result of an XSS as something that can steal their client’s cookies, that’s it. No biggie. After all, is it up to the system admin to protect everyone in his or her userbase? Well — within reason — the answer is yes.
What Causes Cross-Site Scripting (XSS) or HTML Iinjection?
XSS can be a very tricky vulnerability and on complex websites with rich user-based experiences, these vulnerabilities can pop up in the strangest of places. And sadly, sanitizing all of your server-side inputs can still leave you exposed to certain types of XSS attacks. Let’s not get ahead of ourselves though and start panicking. Let’s first discuss the three different types of XSS, take a brief look at their causes and also the risk they impose on both the visitor and the administrator.
A simple code example of a non-persistent XSS:
This is a simple search function illustrating a non-persistent XSS vulnerability. The search code is below, but the actual vulnerability is above. If this site was a password protected, you could feed a link to your victim like the one below (simplified):
The result? A password prompt to a potential victim:
Another option — the one that XSS is probably best known for — is cookie theft. We could also craft a link that forwards the victim’s session cookie to a script we have running on our own server:
To retrieve the cookie on our own backend we’d have our givemecookie.php script running:
$cookie = $_GET["cookie"];
$loc = $_GET[‘location’];
fwrite(“log.txt”, $cookie . "\n");
fwrite(“log.txt”, $loc. “\n\n”);
This code will receive the cookies when the victim clicks the link and store them in a file called log.txt.
Persistent or Stored XSS
Adding the simple proof of concept code below:
<script>alert(String.fromCharCode(72, 65, 67, 75, 69, 68));</script>
And whenever the page is loaded this code will reload again and again until someone purges the payload from the database.
How Do We Protect Ourselves?
Back to our simplified examples. As mentioned, we can mitigate our vulnerabilities programmatically with PHP’s HTMLentities or HTMLspecialchars. You will have to decide which is best depending on whether you’re planning on returning a string value or using just basic string sanitization.
Our Non Persistent XSS mitigated:
Our Persistent XSS mitigated:
The result is our persistent XSS payload is now just displayed text:
The same goes for our non-persistent XSS payload:
What about Document Object Model (DOM) Based XSS?
To understand DOM-based XSS, you really need to have (at the least) a basic understanding of the DOM or Document Object Model. The DOM is a bit outside our scope today, but I’ll do my best to give you an ultra-high level run through. Before we discuss the DOM, it’s important to know that DOM-based XSS exists on the client-side.
Well, this concludes the last part of this series. Be sure to keep a look out for my WAF and filter bypass articles. I will explain why your security posture must be spread out (somewhat) equally on multiple fronts. I’ll show you how WAFs and strong filters can be bypassed by determined attackers to execute code. As usual, we will look at the code and regexp filters on the backend, break it down programmatically, then find the flaw that gives us access to the goods. Until then, keep learning. The only way to be efficient at security is to understand both sides of it.