0

A penetration test using OWASP Zap is finding a number of Path Traversal 'vulnerabilities' but either the report isn't telling me the whole story, or they seem perfectly safe to me. Eg:

URL: http://[xxxx]/News/GetContactsList/2

Parameter: Id

Attack: 2

"2" is the id of the calling entity, so required by our system. The same kind of thing is obviously used in lots of places, but this is the only time Zap complains. It finds a few examples, generally by replacing the 2 with another integer, or passing a perfectly valid string in another parameter "PressContacts".

In MVC, these are bound to ints and a list of ints, so sanitised as far as I can tell.

How can I either find out exactly what the issue is, or tell Zap it's barking up the wrong tree? We have different MVC actions that respond to GET and POST, and the report isn't clear which one it's hitting.

Apologies in advance if I'm missing something really obvious. This is my first time using Zap so maybe I've just completely misunderstood something.

Steve Owen
  • 2,022
  • 1
  • 20
  • 30

1 Answers1

0

This is actually a very common form of attack and the ZAP is right. The integer ID in the URL is easy to change and easy to guess because it is most likely a sequential auto generated number.

Let's say user A has permission to access the id range of 1 to 100 and user B has access to the id range of 1 to 500. User A can login and simply change the id from 100 to 300 and gain access to a record that he/she was not supposed see.

The solution is to use a unique identifier that is NOT sequential and is NOT easy to guess. The most common approach is using a GUID instead of the id in the URL.

Sparrow
  • 2,548
  • 1
  • 24
  • 28
  • That's a fair comment, but we do all that checking server side anyway, so it's not an issue for us, and doesn't seem to reflect the message Zap is saying. It's not a "path traversal" vulnerability. – Steve Owen Nov 30 '16 at 16:30
  • 2
    Normally a security expert uses the report generated by tools (such as ZAP) and tries to define the security risks and attack surface. The risk and attack surface depends on the business and the software, so it has to be done by a human. If you are confident that in your application this attack is not a concern, then you can mitigate and mark it as a low risk or no risk in your report. What's important is that you are aware and have reviewed and considered the risk. – Sparrow Nov 30 '16 at 16:38