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.

  • 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 4 at 14:25
  • @ConorMancone Check my update please and thanks for replying – Roman Mar 4 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 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 4 at 15:38
  • @ConorMancone Check my second edit please – Roman Mar 4 at 15:40
  • @ConorMancone It seems it was a false positive, super weird issue. created a new EDIT. – Roman Mar 4 at 15:59
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.

| improve this answer | |

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.