XSS Vulnerability and prevention

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 attacks trick an application into sending malicious script through the browser, which believes the script is coming from a trusted website. Each time an end user accesses the affected page, his/her browser will download and run the malicious script as if it was a part of the page. In majority of XSS attacks, the attacker will try to hijack the user’s session by stealing his cookies and session tokens, or use the opportunity to spread malware and malicious JavaScript.

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

1. Reflected XSS Attacks: In this case the malicious string originates from the victim’s request. This occurs when a hacker tampers with HTTP requests to submit malicious JavaScript or jQuery code. Upon receipt of the request, the website immediately renders the modified content, including the malware script without encryption, back to the victim’s web browser.
2. 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.
3. DOM-based XSS Attacks: In this case, the vulnerability is in the client-side code rather than the server-side code. DOM-based XSS is best understood by how it must be treated from a defense point of view. While reflective and stored XSS must be defended via encoding while building UI code server-side, DOM XSS is almost exclusively managed by adding defenses into custom JavaScript code, or by simply using safe JavaScript APIs in custom JavaScript code.

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.

Building a web application that is resistant to cross-site scripting can be challenging

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.

• Encode data on output at the point where user-controllable data is output in HTTP responses, encode the output to prevent it from being interpreted as active content. Depending on the output context, this might require applying combinations of HTML, URL, JavaScript, and CSS encoding.
• Use appropriate response header to prevent XSS in HTTP responses that are not intended to contain any HTML or JavaScript. You can use the Content-Type and X-Content-Type-Options headers to ensure that browsers interpret the responses in the way you intend.

1. Input Validation

   Input validation should be the first line of defense for every web application. For example, if your application strips out all

   tags, an attacker can submit

    ipt> 

   to get around the first round of sanitization. Blacklist-based input validation never works to stop XSS. If you blacklist the string
   , an attacker will try to submit an image tag with the same payload:

    

    

2. Contextual Output Encoding

   Output encoding, or output escaping, is a technique that converts data to a form that is display-only and will not execute JavaScript or even render HTML tags. For example, if we set a username to august

   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.

    

   However, when HTML entity encoding is applied to that username, the code will be visible on the page, but not executable. JavaScript XSS tests being rendered safely because they are output encoded with HTML entity encoding.

3. 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.

   1. HTML element content Attack.
   2. HTML attribute value Attack.
   3. JavaScript value Attack.
   4. URL query value Attack.
   5. 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.

Conclusion

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.

References :

https://www.owasp.org/index.php/OWASP_Java_Encoder_Project

https://docs.oracle.com/middleware/1212/owsm/OWSMC/owsm-policy-framework.htm

https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)