2

I used zap to scan one of my websites and found a path traversal issue.

These are the informations:

Attack: c:/

URL: www.example.com/example.php

Parameter: mail

I am now tinkering around in the browser and in CMD with curl and try to get access to the root, but nothing works. Could it be a false positive?

I have done tons of tests now, but shouldn't these give some results:

www.example.com/example.php?mail=../../
www.example.com/example.php?mail=..%u2216..%u2216
www.example.com/example.php?mail=..%c0%af..%c0%af (I tried even more encodings)
www.example.com/example.php?mail=c:/

Here is an example with cURL:

curl --path-as-is -X POST --data "mail=..%c0%af..%c0%af" https://www.example.com/example.php

I found where ZAP displays which request has been done:

mail=c%3A%2F

But the response looks correct. Its the HTML site.

EDIT:

If I execute this cURL I get an empty response, there is nothing.

curl --path-as-is -X POST --data "mail=c%3A%2F" --url
"https://www.example.com/example.php"

EDIT:

If I make the same request through the browser and look at response I see:

Failed to load response data

EDIT:

Wow... it was a false positive. So here is what happened. I had an inline html comment, which looked like that:

<!-- enemies, boulders, etc. -->

I noticed that zap has marked (grey color) the word etc. I assume because its usually part of an important file system path.

I have no clue how this could be connected to path traversal, but after removing the comment zap does not alert this issue anymore.

Roman
  • 157
  • 8
  • The **response** is just as important as the request. It's important to understand how the system is actually using the parameter in question. So, how does that parameter seem to be used? How does the response from the server change when using a "normal" payload vs using the `c:/` payload? – Conor Mancone Mar 04 '20 at 14:25
  • @ConorMancone Check my update please and thanks for replying – Roman Mar 04 '20 at 14:33
  • Is there any difference in the response between a "normal" request and the `c:/` payload? Try saving the two html files and using something like [diff](https://www.geeksforgeeks.org/diff-command-linux-examples/) to find any differences at all. Also related, what else might differ from the HTTP responses other than just the body. Response code? Response headers? Something must have changed for OWASP ZAP to think there is a vulnerability (although it definitely still could be a false positive) – Conor Mancone Mar 04 '20 at 15:38
  • @ConorMancone Check my second edit please – Roman Mar 04 '20 at 15:40
  • @ConorMancone It seems it was a false positive, super weird issue. created a new EDIT. – Roman Mar 04 '20 at 15:59
  • You should take your edits out and turn it into an answer. False positives are actually very common. You're probably exactly right: `etc` is an important part of file systems in unix-based systems, so that was triggering a false positive from zap. The only part that surprises me is that I would expect it to be more concerned about differences between good and malicious requests, so I'm surprised it was triggered by something that was in all responses. – Conor Mancone Mar 04 '20 at 16:53
  • Thank you for taking the time to look into my issue. I will answer the question now. – Roman Mar 04 '20 at 21:29

1 Answers1

2

It was a false positive. So here is what happened. I had an inline html comment, which looked like that:

<!-- enemies, boulders, etc. -->

I noticed that zap has marked (grey color) the word etc. I assume because its usually part of an important file system path in unix-based systems.

After removing the word etc there were no more path traversal issues in the report.

Roman
  • 157
  • 8