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).
What is 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?
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 "">
<script> var name = ’john’;alert(1);''; </script>
Types of XSS
Last but not least it is also worth mentioning the types of XSS:
- Stored XSS (AKA Persistent or Type I): We’ll talk about this type when the payload has been stored in a database on the server side. In practice, anyone can trigger this XSS under the right conditions. The MySpace worm in the example was this type of payload.
- Reflected XSS (AKA Non-Persistent or Type II): This type immediately runs on the victim’s site, but it won’t be saved anywhere else. This type is not a serious case, but it can also cause surprises.
- DOM Based XSS (AKA Type-0): This type is a special case. This incident occurs when the payload can build itself into the DOM. In this case, XSS can manipulate the structure of the page without making any changes to the source, in terms of the server side.
How can you defend it?
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.
How can BitNinja protect against it?
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 firstname.lastname@example.org
Did you miss the previous parts? Catch up now: