I was working with this web-app, when someone pen-tested it and sent me a huge report that says my app is vulnerable to a Directory traversal attack.

Here is one sample:

Testing Path: http://127.0.0.1:80/??/etc/issue <- VULNERABLE!


I put http://127.0.0.1:80/??/etc/issue in my browser, but it gave me the home page, it didn't at all return the /etc/issue file.    

Then I tried with curl and it too returned the homepage.  

Could somebody please explain me how my app is vulnerable, if the /etc/issue file is not returned. 

The app is coded in Python 2.7, with flask as the framework and Nginx as a reverse proxy.  

Two more samples from the report, along with the corresponding response :- 


Testing Path: http://127.0.0.1:80/??/etc/passwd <- VULNERABLE!    

GET Request - app: 0|req: 1587/1587] 127.0.0.1 () {34 vars in 488 bytes} [Tue Sep  6 15:47:13 2016] GET /??/etc/passwd => generated 982 bytes in 4 msecs (HTTP/1.1 200) 2 headers in 80 bytes1  
Testing Path: http://127.0.0.1:80/??/??/etc/passwd <- VULNERABLE!   

GET Request - app: 0|req: 1591/1591] 127.0.0.1 () {34 vars in 493 bytes} [Tue Sep  6 15:47:14 2016] GET /??/??/etc/passwd => generated 982 bytes in 5 msecs (HTTP/1.1 200) 2 headers in 80 bytes


I sent a report for a similar vulnerability recently and got a similar response.

Turns out most browsers and CLI http clients remove path traversal components from the URL.

For instance if on Firefox you type the URL http://example.com/../../../etc/passwd the GET request that arrives at example.com will look like this:

GET /etc/passwd HTTP/1.1
[Ommitted headers]


Same deal with wget.

You should try with a lower level tool, like telnet or netcat:

$ telnet example.com 80
GET /../../../etc/issue HTTP/1.1

HTTP/1.1 400 Bad Request
Content-Type: text/html
Content-Length: 349
Connection: close
Date: Wed, 07 Sep 2016 12:38:13 GMT
Server: ECSF (fll/078B)


Then again, it might have been a false positive, your auditor should've included the contents of /etc/issue in the report. That's kind of the point of using issue and not passwd.

You should at least follow up with your auditor to confirm whether it was a false positive. If that's not possible, arrange a new pentest or perform your own with a path traversal fuzzer like dotdotpwn

Never assume you're secure, ensure you are. Especially after a report like that.
