Introduction to Cross-Site Scripting
Different types of XSS
- Stored XSS
- Reflected XSS
- DOM-based XSS
Stored XSS is when a web application stores the unsanitized data to be retrieved at a later date, this will usually occur with the use of a database. Although it’s less uncommon than the other methods we’ll discuss, stored XSS has a much greater impact on the target website due to the fact it’s run every time the page is loaded and the content retrieved.
For example, let’s say we have a bookstore website. This website contains listings and reviews for the world’s most popular books. For each book, a user can leave a review advising everyone that they should rush out to grab a copy.
To save all of these reviews the website makes use of a database. When the page loads, all of the reviews for that book are retrieved from the database and then listed for other users to read through.
Let’s take a look at another example. Here we have a typical example of how a search page URL would appear.
https://vulnerable-bookstore.com/search.php?query=<script>alert("cross site scripting")</script>
By breaking down the structure of the URL we can build a thorough understanding of how the XSS vulnerability works. Like normal, the URL contains the schema https:// which is then followed by the domain name vulnerable-bookstore.com.
DOM-based XSS can occur when unsanitized data is provided to the application. Should the application make any changes to the Document Object Model “DOM” then it introduces the opportunity for DOM-based XSS.
You’ll find that the most common source for DOM-based XSS is the URL, this is caused due to the number of applications that make use of window.location to have access to the user’s current location.
Protecting Against Cross-Site Scripting
When it comes to Cross-Site Scripting sometimes the simplest approach can prove to be the most effective, with this in mind following a few simple rules can make all the difference.
Rule number one, never trust user-supplied data. This can sound a little cynical but hear me out. Any information which originates from a remote location should be treated with suspicion until it has been verified. This verification process should include sanitization to remove or convert any unsafe characters.
Rule number two, ensure all web software such as WordPress or MyBB are running the latest version. Although new software can have vulnerabilities it is far more likely that these will be few and far between as their respective communities will have been hard at work patching and resolving any pre-existing issues.
Rule number three, make use of a Web Application Firewall “WAF” to monitor the traffic on your website which may be potentially harmful.