Mitigating XSS Vulnerability
Mitigation recommendations for Cross-Site Scripting Vulnerability
Cross-Site Scripting(XSS) is a serious security vulnerability. In short, Attackers use this for a wide range of security attacks like stealing user session cookies, redirecting all the users to a malicious website, logging keystrokes of the victim's activity, defacing an organization's website, even can use the victim system as a bots for malicious activity, etc.
A single technique cannot mitigate XSS vulnerability completely. Using the right defenses can help in preventing XSS attacks.
One of the best practices is "Defense-In-Depth", Enabling multiple layers of defense so even if a layer fails, other layers of protection can minimize the impact of an XSS attack.
Use Frameworks
In modern development practices, developers like to code faster and avoid recreating the wheel.
Rather than building applications from scratch, using the frameworks can protect the application from lots of vulnerabilities. As security features are in-built into frameworks and just need to enable.
For example input validation checks, XSS prevention, preventing access control issues, etc. (Some PHP frameworks include laravel, CodeIgniter, etc.)
Additionally, these frameworks do address the security vulnerabilities when discovered, all you need to ensure is that you are using the latest version of the application framework.
Validate Client Data
One of the most crucial steps is to validate each and every input received from the client.
As we have demonstrated throughout our articles, any data coming from the client side can be modified with the help of intercepting proxies.
For the same reason, each and every piece of data coming from the client must be validated then must follow through next steps of verification.
Output Encoding
Output encoding is one of the techniques used to take user-controlled data and safely display it without interpreting it as code, and considering it as text.
Below is an example XSS payload.
<script>alert(document.domain);</script>HTML-encoded text of XSS payload will be displayed as shown below.
<script>alert(document.domain);</script>- "<" changed to "<"
- ">" changed to ">"
As the browser parses HTML, JavaScript, CSS, and URL differently. Each much be encoded depending on the requirements.
Another good example in PHP, the "htmlspecialchars" function will convert the "<" less than, ">" greater than symbols to HTML entities such as "<" for less than, ">" for greater than respectively. This again makes the application treat all as text without breaking the syntax.
URL, HTML, JavaScript, and CSS can be encoded.
Sanitization
In some cases, the users need to retain HTML code as it is. In this case, the output encoding will break the document structure.
To retain the data as it is, the sanitization technique is used.
As part of the sanitization, it produced a new HTML document that contains only the "safe" or allowed HTML tags. This prevents XSS, this is performed in combination with the whitelist and blacklist approach.
Example, In PHP we used a "strip_tags" function is used to filter out all the HTML tags, the "addslashes" function escapes the special chars like a quote, and a double quote with backward slashes to retain it as text without breaking code syntax.
XSS Header
The X-XSS-Protection response header is one of the features used to prevent the reflected XSS from executing.
Below is an example of enabling the XSS protection header by completely blocking script execution.
X-XSS-Protection: 1; mode=blockThe following can be ignored if the strongly protected "Content-Security-Policy" is being used.
HTTPOnly - Cookie Attribute
This is another cookie flag that helps in reducing the XSS impact. Enabling the "HTTPOnly" flag for session cookies can prevent the javascript code from accessing it.
Content-Type
Content-Type is one of the response headers which specifies the type of content delivered. It is recommended to set the script content to "application/json" than "text/html"
Content-Type: application/jsonSetting the content type to "application/json" prevents the execution of script tags.
Content Security Policy (CSP)
Content Security Policy is an added layer of security protection. This helps in detecting and mitigating the XSS and other code injection attacks.
CSP instructs the browser on how to deal with the content. On CSP-enabled websites, it becomes very hard to exploit the XSS vulnerability.
A Content-Security-Policy header is appended by the server with policy configuration.
Content-Security-Policy: default-src 'self'; img-src *; script-src userscripts.example.com
Above is an example of CSP, instructing the browser to permit only content from the same site, images from anywhere, and execute scripts only from "userscripts.example.com"
Whitelisting rather Blacklisting
Whitelisting or allowing a known good is an approach of letting only what you trust and rejecting all the rest.
Whitelist is one of the supporting steps adding to all the above defense layers. Even in the case of unknown payloads as well whitelist defends well.
Let's say allowing the trusted characters upper case, small case letters, numerics, and some special characters based on need.
Limit usage of the blacklist only for reasonable business requirements.
Use Web Application Firewalls (WAFs)
Configuring and using Web Application Firewalls, protects web applications from a wide range of attacks like XSS, Brute Force attacks, Denial of Service attacks, Malicious input filtering, etc. a lot more.
Say AWS WAF, Cloudflare WAF, etc.
More information on mitigating XSS attacks can be found on the OWASP site.
