How to handle Non Persistent XSS injection

How to handle Non Persistent XSS injection

Cross-site scripting (XSS) attacks are a type of injection, in which malicious scripts are injected in the client side of the web application to exploit confidential data stored in the browser like cookies, session tokens and other sensitive information. The attackers target the modification of the content of the web page, display of invalidated output from any user input and URL parameter injection.

There are three types of XSS attacks:

Here, our focus is on second type of XSS, which is Non-Persistent XSS injection, also known as Reflected XSS. This kind of attack is possible in a web application when a user input is immediately returned by the application in an error message, search result or any other form of response without that data being made safe to render in the browser. The attacker constructs a link with a malicious script attached to it and distributes this link via email, social media or forum sites. As soon as any user clicks on the link, the browser loads the vulnerable webpage and executes the embedded script to initiate XSS attack. If the attack is successful, the attacker can receive the extracted data, for example, session cookies. This type of attack can also be done to compromise integrity by modifying confidential data or actions.

Prevention and Mitigation Techniques

Following are the ways by which a website can be made secure against Non Persistent XSS attacks:

Input Validation

Validating input is one of the most important steps to prevent XSS attacks. There are two types of input validation – Syntactical and Semantic. Syntactical validation checks the format of input, for example: date, currency, pin code, mobile number, etc. While Semantic validation checks the correctness of the values in the business context, for example: start date should be earlier than the end date, discount must not be more than the cost price, etc.

Validation by Whitelisting

Validation by whitelisting involves defining what format of input is valid for submission. The free text entries might be to get date, email addresses, pin codes, phone numbers and requirement might be more specific, suppose if phone numbers of only one country are valid. Such validation needs regular expression based whitelisting, which can check the entered string and allows it only if the input matches with the defined pattern. If an input has fixed responses, using radio buttons, checkboxes or dropdown are preferred. File uploads need to be checked for their name, extension, size and content at the client side as well as at the server side.

Whitelisting is better than Blacklisting for input validation, reason being that in blacklisting limited restrictions are imposed on the input, so the attackers can either execute brute force attack or reverse engineer validation logic to find a vulnerable input field. Blacklisting could also block valid inputs, for example, O’Neill is a valid company name but if the apostrophe character is blacklisted, this input would not be allowed.

Ensure that all the validations done on client-side are done on server-side too, so that Persistent XSS attacks can be prevented.

Output Validation

A web page is termed vulnerable to Non Persistent XSS attacks when it displays output without validating it first. Hence, encoding (or escaping) the output is the most vital defence mechanism to prevent XSS attacks. HTML encoding is the process where the characters that do not come in the safe charset [a-z, A-Z, 0-9 and few symbols] are converted to their HTML entities. This will prevent malicious code from executing in the browser; instead, it will render the data in plain text, where it supposed to be rendered.
For example,

If input validation is not in place and following input is submitted

< script>alert(document.cookie);< /script>

Now if output encoding is implemented, then it’ll attach the following code to the HTML
< script>alert(document.cookie);< /script>

If this is rendered, it’ll display the original input in text, but without executing the payload:

URL Encoding

It is not recommended to pass on data via GET parameters, however if it’s essential to do so, then implement encoding and decoding techniques for the data in the URL. This is also known as Percent-Encoding [https://en.wikipedia.org/wiki/Percent-encoding]. By using this method, malicious content can be filtered out before it affects the application.

For example,

will be encoded to
%3Cscript%3Ealert%28document.cookie%29%3B%3C%2Fscript%3E

Before decoding this data, it’s necessary to filter out the malicious content and validate it according to the required content type.

Web Application Firewalls

Web Application Firewalls can prevent Non Persistent XSS attacks by recognising the requests using signature based filtering. They also crowdsource data related to the attacks, so that all the websites using that particular WAF can be protected against the attacks.

Web Vulnerability Scanners
There are many tools available to test a website for vulnerabilities. These tools can detect the presence of a Non Persistent XSS vulnerability in a website or web application. Some of them are listed below.

Tools

Following tools can be used to detect presence of Non-persistent XSS vulnerabilities:
OWASP Xenotix XSS Exploit Framework
https://xenotix.in

OWASP Zed Attack Proxy (ZAP)
https://github.com/zaproxy/zaproxy

Burp Proxy
https://portswigger.net/burp

XSSer
https://xsser.03c8.net

Xss-scanner
http://xss-scanner.com

XSSploit
https://www.scrt.ch/en/attack/downloads/xssploit

Arachni frameworks
www.arachni-scanner.com

Subgraph Vega
https://subgraph.com/vega

Proudly powered by WordPress | Theme: Looks Blog by Crimson Themes.