It’s been a while since I wrote the previous episode of my blog series. If you are interested in Remote Code Execution, then I definitely recommend reading the previous part.
So, here we are again, the moment has come for my final article about cross-site scripting (XSS).
Usually, XSS vulnerability occurs when there are untreated inputs and bad cookie usage. So, please let me tell you about a case that happened in 2005 on Myspace.
A MySpace user found an XSS vulnerability on the site, and he wrote a payload called „Samy Worm.” This payload was a stored XSS, which was first uploaded by him on his own profile. When a user visited his infected profile, then the visitors saw the following text: „but most of all, Samy is my hero.” Meanwhile, the vulnerability was able to copy itself to the victim's profile and the infection of „Samy Worm” continue to spread without being stopped. The creator had found it funny until his house was surrounded by police and he was arrested.
And it wasn't even an extreme case because Samy had no serious intentions. But it raises the question, what kind of problems can be caused by exploiting such a vulnerability like XSS?
An attacker can easily inject an XSS payload through an untreated input like GET parameter in URL, or POST parameter as a form input if you didn’t sanitize angle brackets, single or double quotes and he can infect your HTML or Javascript code, for example, by using this classic payload :
<script>alert(1)</script>
Single and double quotes can cause XSS vulnerability because these can influence the closing and opening of the expression.
Example for HTML:
<input type="text" name="username" value="john" onfocus=alert(1) autofocus "">
Example for Javascript:
<script> var name = ’john’;alert(1);''; </script>
If your website is vulnerable to XSS, this short javascript code will cause an alert pop up on your site. If this is running, it means that anyone can run any javascript code on your webpage. In most cases, these payloads run on the client side so you can rightly ask, why is it causing more trouble?
If an attacker can run any javascript on a vulnerable page, among other things, he can steal certain data about the user. It's a classic case when the site uses cookies in the wrong way. If the httpOnly flag is not used for cookies on your site, then it means these can be read on the client side. An attacker can steal session information from cookies with an XSS which can be given access an account.
Last but not least it is also worth mentioning the types of XSS:
Most of all, we have to pay attention to cookie handling. If we can, use the httpOnly flag to store confidential data (e.g., sessionID). If you are careful and do this it means that these cookies can’t be read with this flag on the client side.
And last but not least filtered the inputs. Pay attention to HTML tags, opening and closing signs.
Our ultimate WAF solution with ModSecurity could be just what you need to solve all of your XSS problems. We have a whole set of rules to protect you against this vulnerability. Before you start turning all these rules, remember these are atomic and can cause false positive results if you turn them on when you’re on a badly written webpage. But if you are confident and you know what you are doing, then just go ahead. The Ninja has been with you 🙂
Need a little help to get familiar with our WAF? Check out our article serious about How to use BitNinja WAF (especially on WordPress but it contains useful information in general). Do you still have questions or need assistance? Contact our ninjas at info@bitninja.io
Did you miss the previous parts? Catch up now:
