Cross-site scripting (also known as XSS) is a web application vulnerability that occurs when user-provided data is insufficiently sanitized by an application. Since the data is often returned this allows for malicious actors to inject Javascript code. XSS can come in multiple forms and have a range of capabilities such as simple cookie stealing, user redirection and website defacement.
Different types of XSS
Cross-site scripting is a term which covers 3 main aspects of injecting Javascript code into a webpage, these 3 types are;
- Stored XSS
- Reflected XSS
- DOM-based XSS
Stored 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.
This is where the XSS vulnerability would occur. Since the review is passed to a database, if insufficient sanitization has taken place then it may be possible to include foreign Javascript code, this would be stored Cross-Site scripting.
Reflected XSS
Reflected XSS can occur when a web application outputs unsanitized data back to the web browser. The main aspect that sets reflected XSS apart from stored XSS is that any injected Javascript code is only reflected on the affected page, this is not saved anywhere.
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.
Next, we can see the actual page, search.php. This is where it gets interesting, the URL appears to have a single parameter query. When you search for something on a website it will typically store the search term within a URL parameter, this can then be referenced later on. If an application references the URL parameter without sufficiently sanitizing it then Javascript code can be supplied resulting in a reflected Cross-site scripting vulnerability.
DOM-based XSS
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.
DOM-based XSS often takes advantage of included Javascript functions such as innerHTML, window.location and document.write as these allow the application to make dynamic changes to the page. However, it’s important to keep in mind other such functions can be abused.
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.
