XSS Mitigation using regex

Question

I am allowing following character in regex that is dash, tilde, attherate, a-z, A-z, 0-9

[A-za-z_0-9.,\t\r()\\[\\]@ ~/[-]+$]

1. Is there any possibility to bypass these regex?

2. Actually, whenever request came to server, request hits to this page first. Is it safe?

3. actually application is huge in nature so I can't apply encoding on each and every response instance. Is there any way to mitigate commonly?

Answer 1

1. Is there any possibility to bypass these regex?

I am not very confident in the regex, because if I do a string like "abc" or "alert(1)" it says no match on both. XSS can be obfuscated as well, meaning a good regex to catch XSS is not an easy task to write, for more information have a look at https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet

3. actually application is huge in nature so I can't apply encoding on each and every response instance. Is there any way to mitigate commonly?

You should architect application with security in mind before you develop it. I would suggest re-factoring your code so that all output, no matter of location is encoded with html entities.

Example for C# https://docs.microsoft.com/en-us/dotnet/api/system.web.httputility.htmlencode?view=netframework-4.8

Answer 2

I agree with the answer from @RaimondsLiepiņš. To expand a bit more though, it's important to understand that the nature of how you prevent XSS depends on the context, which is why proper encoding of output is the most effective solution. Trying to preemptively clean all input can work, but also tends to be a clunky solution that causes other issues for users, and even still isn't always successful. Context-aware output encoding is the only sure-fire solution.

XSS

To give an example of where your current regex will fail, it will fail if user input is injected into javascript that's not enclosed in quotes. Imagine a URL like this:

https://example.org/page?id=5

The id parameter gets injected into some javascript on the page like this:

var resourceId = [ID_FROM_URL];

In this case, your regexp does nothing to stop active exploitation with a payload like:

http://example.org/page?id=alert(1)

If you don't have any cases like this, then your regexp might protect you. It's impossible to say for sure though, because with XSS it all depends on context. This is why trying to apply one rule to all input tends to leave security holes - there are too many possible issues.

Problems for users

Even if your regexp did fix all your XSS, it is still causing a lot of trouble. The issue is that you are preventing virtually all non-ascii characters from being used in user input. That will be unfortunate for anyone who uses your system and is Irish (i.e. Conor O'Brian), anyone from every continent except North America (aka my good pal Jávier), anyone who speaks 普通话/普通話, and anyone who needs to quote what "the other guy said".

Solution

The only real solution, therefore, is to just do it right. I'm going to guess that you work for a company that built a large software system and only afterward learned about basic application security. Unfortunately this happens more commonly than you would hope. In the long run you're really only going to have one option: re-do it. Trying to bolt security onto a system that wasn't built securely is a losing proposition. Eventually you'll either end up rebuilding your system with a more solid foundation, or you'll end up very, very hacked. Those are the only long-term options.

In the short term you could also try implementing a strict CSP to mitigate the potential damage from an XSS attack, although typically implementing a tough CSP is very difficult for systems that weren't built securely in the first place.