XSS mitigation

1. Input sanitization. Demo: text.replace("<script>","#");

But it can be bypassed using a number of other payloads like <img src=a onerror=alert("xss")>

It is a loosing strategy but can be implemented cleverly to block major malicious inputs.

1. Using HttpOnly cookie

Set-Cookie: key=value; Expires=<Date>; Secure; Httponly;

Secure in cookie means the cookie will only be sent over HTTPS. but doesn't help against XSS

HttpOnly means JS running on page doesn't have access to that particular piece of cookie data. Instead its only accessible by the server itself. So, if <script>alert(document.cookie)</script> is run by an attacker, it will omit any cookie which has HttpOnly set.

Uses: When server is trying to store something sensitive like Session ID, server admin can mark that cookie as HttpOnly and then JS won't be able to access it.

1. XSS protection Header

X-XSS-Protection: 0/1

Sort of a message from server which tells the web browser that if you have any special features ( that are designed to detect things that look like XSS, you should turn them on or not turn them on.

So, for example if a URL is example.com?name=Harshit

and X-XSS-Protection: 1, The page loads normally.

But if, URL is example.com?name=<script>alert(1)</script>

and X-XSS-Protection: 1, The browser activates its security mechanism against the attack. This security mechanism could be Content Security Policy or some other thing like XSS filter mechanism depending on browser.

Enable in Nginx

add_header X-XSS-Protection "1; mode=block" always;

Why is there a need for servers to add this header and explicitly turn them on?

-> Because sometimes there were sites that would break if these XSS scripting heuristics were turned on. This is a result of rapid development in security of web apps. We can't tamper too much with sites that are working currently so we add security mechanisms on top of them. Some legacy site could be working perfectly well initially by adding scripts in parameters and then drop them into page but then browser enabled XSS protection and they broke by browsers. We can't allow site to break due to an external tool. That's why we add such mechanisms on top of existing functionality where server controls which pages to turn XSS protection on, on.

1. HTML entities encoding

This way, HTML can parse these characters, but the server won't understand and hence XSS be mitigated. It isn't perfect though Bypass-> If <a href="[]"></a>

We can simply add our JS payload into this [] like

Which will not violate HTML entities encoding scheme since our payload isn't loaded through tags, rather is in the URL section now where HTML encoding doesn't apply.