1

I have an Apache server which seems to be vulnerable to path traversal, because when I test this URL: http://localhost/ati/../test.txt

it will be changed to the this: http://localhost/test.txt and the server shows the contents of test.txt file.

However, when I test this URL: http://localhost/ati/../../../../../../../../../../../../../../../../../../../etc/apache2/apach2.conf it will be changed to: http://localhost/etc/apache2/apache2.conf and therefore the server gives a 404 Not found response and does not show the content of apache2.conf file.

My first question is: Does it mean that I am secure against path traversal attack regarding the fact that I have not changed any default settings of the Apache on my server?

And my second question is: why the server does not allow to traverse beyond the root of the web server folder? I.e. why can't I access outer files than localhost folder on my web server? How can I exploit path traversal if my server is vulnerable?

1
  • Default Apache config should protect against this. Scripts are generally able to access files outside of the document root, I would focus most of my energy there. Commented Jan 14, 2015 at 17:21

2 Answers 2

4

Apache itself should not serve files outside the configured DocumentRoot.

The behavior you are describing is most likely caused by the browser, which transforms the URLs before sending them to the server.

If you use an intercepting proxy, you will notice that for http://localhost/ati/../test.txt, the browser actually requests http://localhost/test.txt and for http://localhost/ati/../../../../../../../../../../../etc/apache2/apach2.conf, http://localhost/etc/apache2/apache2.conf is sent to the server.

If you want to check the path traversal vulnerability you should use a proxy.

1

Use Telnet to actually send your malicious request. As Dinu S pointed out, the browser is mangling your request, and Apache should not be serving these files AT ALL. To check:

$ telnet 127.0.0.1 <server-port>

Then manually type in the request:

 GET /../../../../../../../../../../../../../../../../../../../etc/apache2/apach2.conf HTTP/1.1

If it responds with your apache.conf file, then you are vulnerable. If you're aren't, it should respond with a 404 or 503.

2
  • I did what Ohnana said, i.e. I telnet to the server and request apache2.conf manually, it respond me with 408 Request time-out. How should I interpret this response??
    – A.B.
    Commented Jan 17, 2015 at 7:17
  • By the way, I have another question from Dinu S:If this behavior is caused by my browser, can I use some encodings of "../", for example I use "..%c0%af" instead of "../" in order to bypass my browser checks and exploit path traversal vulnerability?
    – A.B.
    Commented Jan 17, 2015 at 8:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .