1

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.

4
  • Always use the escape function provided by your SQL API. If you wish to disallow certain characters (for reasons other than SQL injections), do so before escaping the string.
    – markus-nm
    Nov 27, 2019 at 12:11
  • With regard to '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).
    – mti2935
    Nov 27, 2019 at 12:12
  • @mti2935 that's a good point and one of the reasons I am asking if these 6 special symbols can be abused and we should limit it even further Nov 27, 2019 at 12:49
  • Since you don't know how the data will eventually be used, I would think carefully about allowing commas. See owasp.org/index.php/CSV_Injection
    – mti2935
    Nov 27, 2019 at 12:58

1 Answer 1

3

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.

5
  • I know I cannot stop all and 3d party systems have to fix the usage of data, but we can at least try to prevent something while we try to update security in other products, thanks a lot for a very good answer. Is at least alphanumeric and space safe? :) Nov 27, 2019 at 13:59
  • 1
    @IlyaChernomordik "safe" is relative. You'll have to decide what is safe enough while still being usable for your users. Even your original list is fairly "safe", but if the data is badly misused by the destination application, anything can be dangerous. The XSS example I gave required a pretty bad blunder on the part of the "person" who made the application (no injection protection at all and data was injected in the most dangerous possible context). If you want to try to protect against that level of mistake, then yes, stick to only alphanumeric+space. Realistically, you'll probably be OK. Nov 27, 2019 at 14:20
  • If you're willing to assume a higher level of competence on the part of people using your data (aka no gigantic blunders like in my example), then you would probably be safe with your original list, and then your users can actually use parenthesis and hyphens (which can be common in writing - just look at this comment). "Safe" isn't an all or nothing proposition. It sometimes requires balancing user convenience against the risk you are willing to accept. That means that only you can decide what is "safe enough". Nov 27, 2019 at 14:22
  • Yes, thank you very much for clarification. The problem is that is very had to decide if it is "safe enough" unless you know a lot about security... Nov 27, 2019 at 15:44
  • 2
    If you're worried about bash, then alphanumeric and space is not safe. rm importantFile Dec 11, 2019 at 14:59

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .