Preventing Cross Site Scripting

Please note, the following information is intended for education purposes to aid in preventing such security threats.

Cross site scripting (also known as XSS) is a web application vulnerability that occurs when input is incorrectly sanitized by a web application allowing for the execution of foreign HTML and 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 wide term which covers 3 main aspects of injecting HTML and JavaScript code into a webpage, the 3 main types are;

• Stored XSS
• Reflected XSS
• DOM-based XSS

Stored XSS

Stored XSS is when a web application stores the unsanitized data to be displayed back at a later date, this will usually occur with the use of a database. Although much more uncommon, stored XSS has a much greater impact on the target website due to the fact its ran every time a member of the public visits the effected page.

Perhaps an example would make this easier to understand, lets say we have a book website. This website contains reviews on the worlds most popular books, users are able to sign up and tell the book loving community how much they loved reading Tolkiens "The Hobbit". To save all of these reviews our website makes use of a database and when the page loads, all of the reviews are retrieved from the database after which they're displayed in a fancy design for the website user to enjoy. Now, here's where the vulnerability would occur. When you've finished writing your review the submitted text is passed to the database to be stored, however, if any HTML or JavaScript code has not been thoroughly sanitized then this code would then be ran then its retrieved from the database resulting in a stored cross site scripting vulnerability

Reflected XSS

Reflected XSS can occur when a web application outputs submitted and unsanitized data back to the web browser. The main aspect that sets reflected XSS apart from other such as "DOM-based XSS" is that an attacker has the ability to send effected URL's to potential victims, here's one such example that shows how an injected search URL would appear on a vulnerable website.

https://vulnerable-website.com/search.php?query=

So, what's happening here? Well, lets take a look. As you can probably tell, this is a URL that would usually appear when you search something on a website, here's the bits that are interesting. First we can see a URL parameter called query, this is followed by the search term. Often you'll find that the item you search for on a website will be displayed back in the search field or a page header, this is exactly the sort of situation when reflected XSS can occur. If the search term is not correctly sanitized then once the page loads any code which has been entered in the search field can also run, just as if it was apart of the website. In the example above an alert box would appear in the middle of the browser window showing their cookies as text.

DOM-based XSS

DOM-based XSS can occur when JavaScript accepts data from an untrusted source, this code is often ran using innerHTML to replace some of the content on the page. The fact that this code is added directly to the page means the attacker is able to run their own malicious JavaScript code. Another such example would be is a website uses document.write as this allows for scipt tags to be used and further JavaScript code to be ran.

You'll find that the most common source for DOM-based XSS is the URL, this is caused due to a number of applications make use of window.location to have access to the users current location.

Protecting against cross site scripting

When it comes to cross site scripting sometime the simplest approach can prove to be the most effective which is why we recommend following a simple rule, never trust data which is provided by the user and or their browser. I realize this can sound a little cynical, however, any information which originates from another location should be treated with suspicion and should always be thoroughly sanitized.

• Ensure all web software such as WordPress or MyBB is running the latest version
  
  • Although new software can have vulnerabilities it is far more likely that these will be few an far between as their respective communities will have been hard at work patching and resolving any pre-existing issues.

• Make use of a Web Application Firewall (WAF)
  
  • Web application firewalls help monitor the traffic on your website using a number of techniques.

• Conduct regular website scans using arctil
  
  • The arctil web security assessment tool exists to help give web admins and security testers a free, simple and convenient way to check for security bugs. Why not make use of this by downloading your free copy today.

Still need help?

Are you having trouble using arctil? Why not try reaching out to our Community Forum.

Alternatively, you can try contacting us through the Contact page.