XSS Prevention : Without Writing Single Line of Code

What is XSS?

XSS(Cross-site Scripting) is a web threat in which the attacker inserts malicious client-side code into webpages. These attacks exploit the XSS vulnerabilities, and can ultimately result in the loss of data, or loss of control of a user session and a lot more.

How XSS attacks work?

The most famous web attacks like SQL injection, Password attack etc mainly attacks the core of the application or the server, but this is not the case with the Cross-site scripting attacks as they mainly target the application users. These attacks work by injecting code, usually a client-side script such as Javascript into a web application. There are so many injecting fields that the attacker may make use of to insert these attacks like search fields, feedback forms, cookies, and forms. Cookies are one of the most targeted, as they are commonly and regularly used incorrectly to store information such as session ID’s, user preferences or login information. These attacks make use of DOM manipulation to alter form values or switch the form action to post the submitted data to the attacker’s site. Now let’s look at how you can prevent XSS without changing the whole source code.

1. Security Headers

The X-XSS-protection header is designed to prevent XSS attacks the filter is usually present in all kind of modern browser but you need to enforce it to use it. It is supported by Internet Explorer 8+, Chrome, and Firefox etc. This is how it looks :

X-XSS-Protection: 1; mode=block

This is how it looks to check it you can use

Ctrl + Shift + I --> go to network tab --> reload the page --> click on any HTML link

Now, this header comes in many variations!

X-XSS-Protection: 0 X-XSS-Protection: 1 X-XSS-Protection: 1; mode=block X-XSS-Protection: 1; report= 0: Means Disables 1: Means Enable mode = block means filtering is ON, instead of sanitizing the page, the browser will the attack. Report = URI If XSS is detected it will send the URL on which the attack was detected.

2. Content Security Policy

To enable CSP, you need to configure your web server to return the Content-Security-Policy HTTP header (sometimes you will see mentions of the X-Content-Security-Policy header, but that’s an older version and you don’t need to specify it anymore). From a high-level view what CSP essentially does is that it enables the script executing from only whitelisted domains, so if there’s a script execution from an entry that is not in the whitelisted domain it will be blocked. If you want to make the rules a little bit more strict then you can opt out to globally disallow the script execution. This is how it looks :

Content-Security-Policy: policy

Now to make this work you also need to define a policy according to which your CSP will work let’s skim through some examples.

Content-Security-Policy: default-src ‘self’

This setting would mean that you only want to allow the person to come from the original domain and not even the subdomains.

Content-Security-Policy: default-src ‘self’ *.trusted.com

This setting would mean that you want to allow each and every domain which is under the parent domain *.trusted.com.

Content-Security-Policy: default-src https://somebank.com

The server only permits access to documents being loaded specifically over HTTPS through the single origin somebank.com. Obviously, CSP isn’t foolproof and can be bypassed but it makes the exploitation significantly tough. These are some of the methods that you can answer for your next interview when you are asked how to prevent XSS other than the classic user-input validation.