Every day, we are storing credentials and personal information from every application that should be more secure. I am writing this blog to prevent any application from an attacker or hacker. I have used multiple ways to protect my web application from cross-site scripting (XSS).
XSS Vulnerability and Prevention
XSS attacks are common to web applications as popular as Facebook, Google, and PayPal, and XSS has been a mainstay on the Open Web Application Security Project (OWASP) top 10 list since inception. XSS attacks are especially dangerous because an attacker can gain access to user activity, which include passwords, payment and financial information. Worse – the victims, both the user and the vulnerable application, often are unaware that they’re being attacked.
XSS vulnerabilities are difficult to prevent simply because there are so many vectors where an XSS attack can be used in most applications. Unlike other vulnerabilities, such as SQL injection or OS command injection, XSS only affects the user of the website, making them more difficult to catch and even harder to fix. Also, unlike SQL injection, which can be eliminated with the proper use of prepared statements, there’s no single standard or strategy to prevent cross-site scripting attacks.
Types of XSS
- Stored XSS Attacks: In this case, the malicious string originates from the web application database. This occurs when an attacker submits malicious content to your Web application. This content is stored in a database and later rendered for other uses on web pages. In this scenario, the victim is most likely to be already authenticated, which could serve to make the attack more effective, because the script will execute with the same permissions as the logged-in user. Stored cross-site scripting is the perfect example of why input validation alone is not a sufficient defense.
So far, I was trying to explain what an XSS attack is and the types of attacks and finally, why we should try preventing these attacks. In the next section of the blog, let’s move to the main purpose of defending an XSS attack. I have used this prevention method in digital self-service where the customer uses payment gateways.
Defending and Preventing XSS
Building a web application that is resistant to XSS can be challenging. For example, having to remediate an old legacy web application that contains significant XSS, in a language that does not have the right security libraries, without any programmers on staff who have direct experience with the language, can be time-consuming and expensive proposition.
While developing a web application, there are two different ways of performing secure input handling. Validation, that filters the user input so that the browser interprets it as a code without malicious commands.
- Input Validation
Input validation should be the first line of defense for every web application. For example, if your application strips out all
<script>tags, an attacker can submit
<scr<script>ipt>to get around the first round of sanitization. Blacklist-based input validation never works to stop XSS. If you blacklist the string
<script>, an attacker will try to submit an image tag with the same payload:
<img alt="TEMP" src=”http://myorg.com/temp.jpg" onLoad=”alert(‘hello’)”>
- Contextual Output Encoding
<script>alert(“hi my dear”);</script>then you would see a little alert pop up every time you visited a page that listed my username, such as My Profile or a forum comment.
- Input handling contexts
There are many contexts in a web page where the user can insert values. You can understand the context easily with the experience of developing web applications. After identifying the context, the rules which are specific for each context must be followed, so that the user input cannot break out of context and get interpreted as malicious code. The following most common contexts are targeted in my sample demo application.
- HTML element content Attack.
- HTML attribute value Attack.
- URL query value Attack.
- DOM based Attack.
We will need to include different type of encoding for different types of context. But we do not need to write these encoding functions from scratch. Even if you skip most validation, good output encoding will save your website from most XSS. But if you have a good input validation, you will still have to face XSS, should you skip the output encoding. A better way is to have both.
We do not need to write the encoding function from scratch. A solution is to use a Java encoder project. I have used OWASP Java Encoder Project in my sample application.
Another way to prevent XSS vulnerability is to sanitize user input. Sanitizing data is a strong defense but should not be used alone to battle XSS attacks. It’s totally possible you’ll find the need to use all three methods of prevention in working toward a more secure application. Sanitizing user input is especially helpful on sites that allow HTML markup, to ensure data received can do no harm to users as well as your database by scrubbing the data clean of potentially harmful markup, changing unacceptable user input to an acceptable format.
Using layers of security like the ones mentioned above, is a great way to eliminate a majority of XSS attacks. It’s important to remember that while the above prevention methods will cover most XSS attack vectors, they won’t cover everything. In order to be truly vigilant against XSS and other common, debilitating vulnerabilities, like the rest of the OWASP Top 10, it’s important to use a mix of code review, automated static testing during development and dynamic testing once the application is live. In addition, it’s vital to use secure coding practices that will help prevent vulnerabilities like cross-site scripting.