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.
'and eventually any other things I did not think about'
, you might want to also consider the possibility of command line injection attacks (owasp.org/index.php/Command_Injection).