Which symbols can I whitelist to remain safe against SQL injection, XSS, and all other injections attacks?

Question

I have an input field in a web that is being saved. This field can be shown in other systems that I do not have control over and that's why I would like to limit what is allowed in this field, although I would like to allow some common special characters for user convenience.

This is what I came up with (I will whitelist only these characters):

• Alphanumeric
• Space
• .,()-:

I would like to check if this is "safe" enough with regards to XSS injection, SQL injection and eventually any other things I did not think about.

P.S. I do know that this is not the right way to prevent an attack but I need this because data use will be out of my control.

Answer 1

tl/dr: You simply can't protect other systems from malicious input. Protecting against injection attacks depends too strongly on the way in which the data is used. The best you can do is try to prevent obvious malicious payloads from sneaking in, but even your proposed white list can leave severe vulnerabilities if the application on the other end isn't practicing proper security.

Unfortunately what you are trying to do is nearly impossible, because ultimately securing against injection attacks depends completely on the context (aka how the application is using the data). To pick one random example, imagine someone reflects your input into an HTML page like this:

<script type="text/javascript">
var dataFromIlyaChernomordik=[DATA];
</script>

Note that the data is injected directly into javascript without any double quotes. Unfortunately, the data that went into your site is:

eval(String.fromCharCode(97,108,101,114,116,40,39,72,73,39,41))

Which translates into:

eval("alert('HI')")

I'm sure you can see where this is going. Using only A-Z0-9,.(), combined with a lack of proper input handling at destination, I can now inject arbitrary javascript. Game over.

So let's get rid of everything but: A-Z0-9-:

Yeah, but that hyphen there - it looks dangerous, and it has a variety of possible meanings in bash. Is it possible that someone might be using this input to build strings to execute in a command line? Is it possible they might forget to escape the data properly? If so, you should ditch the hyphen. Spaces and a colon also might cause trouble if someone is using your data inside an eval command in a python script.

The point is, anything can be dangerous in the wrong context. As a result the only way to properly secure a system against malicious user data is to understand the context in which the user input is being used. The only input that might be safe in an unknown context is an empty string (but man you'll be in trouble if you accidentally use a null character instead of an empty string!)

In essence, you're attempting to build a WAF, and while those can play a role in providing security to web applications (which is already a very specific context - a WAF will by no means protect against everything), anyone who has done enough penetration testing has plenty of stories about circumventing a WAF because of oversights in its rules.

Can you try to filter out the most obvious malicious payloads? Yes. Can you stop all dangerous payloads in all contexts? Definitely not.