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 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 understand the risks you might be exposed to, starting with the most likely vulnerabilities. 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 altering all user actions 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 webserver, storing it in its database. This means that any new user retrieves the 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 a malicious script and spread it. Users opening the link get 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 its 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 it is quite harmless to your web application. Unfortunately, nothing could be further from the truth:
An attacker could change parts of the web page or send the user to another (potentially malicious) web page through the injected script. Your user will notice and be less likely to go on using your web application in any way.
There are simple ways to reduce the risk of Cross-Site Scripting attacks for users since add-ons for some browsers protect from certain malware attacks. However, 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, you can take a few measures 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 the 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. However, 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 ensure that your web application’s Live-Version 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.