The number of serious vulnerabilities per web application is rising each year. Often developers also have to tackle vulnerabilities that they've never seen before. These Zero Day attacks are the reason why development teams need to proactively search for vulnerabilities within their web application before releasing new features to the public.
We are starting a blog series explaining the most common web application vulnerabilities. This series will help you to understand the risks you might be exposed to - starting with the most likely vulnerabilities first. It will also help you with remediation advice to fix existing vulnerabilities as fast as possible.
In this article, we will focus on Cross-Site Scripting (XSS). According to the WhiteHat Security Report, the likelihood of an XSS Attack is at 37.7%, making it the third most likely vulnerability to come up in your web application. And there are some risks associated with XSS that have an impact on both you and your users!
...so, what is XSS?
Cross-Site Scripting is the injection of malicious scripts into a normally trusted web application. This is possible whenever user input (for example on a website) is not sufficiently validated either on the client- or the server-side. These scripts contain malware that enables the hacker to perform a variety of attacks. This includes the alteration of all actions the user takes on that website since the user’s browser does not know that this script can’t be trusted. Because this script is trusted, it can access e.g. cookies or session tokens or even alter the content of an HTML Page. It can be injected persistently or non-persistently depending on the type of XSS that is being used. Usual vehicles of cross-site scripting attacks include search forms, forums or comment sections.
What different types of XSS are there?
There are three types of XSS attacks, depending on the location of the malicious code:
Stored Cross-Site Scripting
Through a stored XSS attack, the hacker can inject the malicious script persistently into a web application.
That script can be submitted via an input field on the web application and infect the web server which stores it in its database. This means that from then on, any new user retrieves this script whilst accessing information and therefore their session cookie might be accessible.
Reflected Cross-Site Scripting
A reflected XSS vulnerability shows the malicious input directly to the user of the web application. This might include that a search form reflects the unvalidated input and shows what the search key was. An attacker could use this to create a URL containing malicious script and spread it. Users opening the link are getting to a web application where the malicious script is run in the user’s web browser.
DOM-Based Cross-Site Scripting
DOM stands for Document Object Model and is an interface to web pages. It is essentially an API to the page, allowing programs to read and manipulate the page's content, structure, and styles.
What happens to your application and the user?
Because a Cross-Site Scripting attack infects the user's browser you might think that it is quite harmless to your web application. Nothing could be further from the truth:
Through the injected script an attacker could change parts of the webpage or send the user to another (potentially malicious) webpage. In any way, your user will notice and be less likely to go on using your web application.
For users there are simple ways to reduce the risk of Cross-Site Scripting attacks, since there are add-ons for some browser that protect from certain malware attacks. As the application provider, you shouldn't trust that all of your users have these included, which is why you should take action yourself.
What can you do?
Cross-Site scripting vulnerabilities are hard to identify and remediate. However, there are a few measures you can take so that these vulnerabilities are less likely to show up.
Don’t trust any user input!
All user input should be considered malicious until it is properly validated. For that you can and should follow some programming guidelines, that you can find in the OWASP Cheat Sheet.
Avoid untrusted input!
Avoid displaying any user input on your web application, since this is the major reason why XSS attacks happen. If you have the necessity to display user input, do it in certain restricted places on your web application.
Filter all user input!
When input is shown as text within the HTML-Code you should filter out the possibility to insert a <script> tag into your page.
This can be done through the following function:
htmlspecialchars($input) # PHP
html.escape(input, quote=True) # Python
org.apache.commons.lang.StringEscapeUtils.escapeHtml(input) # Java
For other specific programming guides you can also check out our Knowledge Base!
Implement automated security into your development process!
Like mentioned earlier, XSS attacks are quite difficult to detect. This can be changed if you get some external help. Penetration tests can find most sorts of vulnerabilities within your application, but using manual testing is extremely time consuming and costly - and therefore not possible to be done for every iteration of your web application.
Your code shouldn’t be untested before any release!
Using automated security, you can scan your web application for Cross-Site Scripting and other critical vulnerabilities before every release you do. This way you can make sure that the Live-Version of your web application is still secured whenever you alter or add a feature.
Automated security scanners like the Crashtest Security Suite can be run weekly, monthly or after every deployment to your test system.
To start with automated security you can use our Quick Scan to get a first look of your web application security!