1

I currently have the problem in one of my self-written apps that the app receives user input (JSON) from another app, but I am not able to check if this input is good or malicious. I can't check this because I do not know what is in this data, i.e. I know how the header should look like, but the data changes. But, before the remote app is able to send information it has to authenticate itself. Is this enough for providing security against malicious attacks via sending bad data, or should I improve the security? If yes, how?

arc_lupus
  • 209
  • 1
  • 10
  • 2
    Your question isn't totally clear, but if what you are asking is "should I validate data passed in to me from a system that I do not control" then I would say that this would be considered good practice. You should be very specific about the values you will accept, and the format this arrives in, and should not tolerate anything that you do not expect. Have a look at defensive programming – robert Oct 04 '14 at 10:20

1 Answers1

2

No, authentication is not a sufficient compensating control for lack of input validity checking.

You can't always usually ever trust input from users and and other systems (and I recommend not trusting input from your own system, as well). As an example, I've had roughly 5 instances in the last three months where a trusted user's system acted as an unwitting conduit for a scan or attack. In one case, their system was carefully tucking malicious input from a third party into valid (schema-appropriate) XML and forwarding it under their credentials. Oops!

You may not know what to expect for the valid content of the data but you should be able to look at both the structure of the data and invalid content of the data.

Structure - If it's a phone number, zip code, SSN, or other structured data, you can do syntax checking to make sure it fits the appropriate pattern.

Invalid Content - If it's unstructured text, you can validate size, and you can look for and quote metacharacters that are often used to abuse parsers and processors (`, ;, (), {}, &, <>, etc.). This is a difficult task to do comprehensively, which is why the Web Application Firewall market has sprung up - it offloads the scanning of content for malicious strings to a specialized tool that can focus on the task.

gowenfawr
  • 72,893
  • 17
  • 165
  • 200
  • The data is in JSON-Format, if not, it will be rejected – arc_lupus Oct 04 '14 at 15:57
  • JSON is a container, not a format. It is a method for interoperably transmitting data. You still have to worry about what's actually in the data, and you need to worry about attacks which attempt to mangle the container - JSON is actually worse than most here, because it's essentially code, a self-extracting archive of sorts. Watch what data you're executing :) – gowenfawr Oct 04 '14 at 16:45
  • Not really. JSON was designed so you can eval it in JS, and if you do that it is code and subject to attack. But there are now plenty of JSON-specific parsers that allow only data. – dave_thompson_085 Oct 05 '14 at 09:21