Jump to content

directory traversal attacks


ala888

Recommended Posts

Hello, Ive been looking up info on this type of attack, but sadly have not found extensive documentation on it.Aside from using $_REQUEST superglobals in include files, are my php files vulnerable to being downloaded before being parsed by php-fpm alongside nginx? And how must I safeguard against such attacks.

tldr: how do I safeguard my php source code from being directly downloaded ?

>using nginx on VPS

  • Like 1
Link to comment
Share on other sites

It looks like it's been at least 3 years since the last php-fpm update. That's forever in code years.

Link to comment
Share on other sites

You safeguard against a directory traversal attack by validating any user-supplied data that goes into a filename for something like an include statement or file download. It doesn't matter what the technologies on the server are.My application, for example, sends ajax requests to a common PHP file. This PHP file includes everything the application needs in general, does some basic authentication used for any ajax request, and then includes another PHP file based on what the ajax request was for. The ajax request includes a partial filename (without the ".php") and some other data about the request. To validate this, I build a path to the directory where the PHP files are that are allowed to get included with ajax requests, and use the submitted value as part of the filename. Then I use the PHP function realpath to resolve anything like directory traversal or virtual directories in order to get the actual canonical path to the file that I'm about to include. Finally, I make sure that path is inside or under the directory that files are allowed to be included from. If it is outside of that path then it is a directory traversal attack and it gets ignored, otherwise the requested file gets included.In your case, it sounds like you are asking about something like a file download script, where you send it the filename to download. If you don't validate that filename then you could send it the path to a PHP file and it will send the code. Including a PHP file like I described earlier does not output the code, it executes it. It would output a non-PHP file, though.

Link to comment
Share on other sites

I realize that there is some ambiguity to my original question, so let me rephrase it for clarity.

I know that it is possible to become a victim of directory transversal attacks if you are using user input to comb through your server files in PHP via the include function; but what I am interested in is, whether or not it is possible to do so otherwise (e.x. there is no include function to exploit).

 

ex.

nginx

root is /var/www

 

all my files are in www/...

while some sensitive data is in /var/[config files]...

 

Im curious of whether or not it is possible to access the var directory from the outside world? And if there is some specific nginx directive that will prevent this - something along the lines of default_type (if .php) do not send and return 403 error instead - thus forcing the code to be first interpreted or else become completely inaccessible. so like in theory preventing anyone from ever having access to the source except for the php interpreter itself

Edited by ala888
Link to comment
Share on other sites

Im curious of whether or not it is possible to access the var directory from the outside world?

If the www directory is the server root, then it shouldn't be possible to directly access /var as long as the server is configured and functioning correctly. You can still write insecure PHP code that will end up opening any file that PHP has access to open, though.
Link to comment
Share on other sites

configured and functioning correctly

Im highly paranoid. Is there a citation you can provide for a comprehensive checklist or something to the like?Im confident that my php code itself is secure - just not about the server configuration

 

and also like niche mentioned

It looks like it's been at least 3 years since the last php-fpm update.  That's forever in code years.

should this concern me? Like I know its just a cgi proccess manager - which theoretically shouldn't be that big of a deal, as long as the php/perl/python that it actually serves is up to date. But Just wanted to confirm its not a problem

Edited by ala888
Link to comment
Share on other sites

Im highly paranoid. Is there a citation you can provide for a comprehensive checklist or something to the like?

No, I'm not familiar with nginx.

should this concern me? Like I know its just a cgi proccess manager - which theoretically shouldn't be that big of a deal, as long as the php/perl/python that it actually serves is up to date. But Just wanted to confirm its not a problem

I can't really comment on that. It's not a problem if a lot of people use it and no one is finding any bugs. It's a problem if people aren't reporting bugs or if reported bugs aren't being fixed.
  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...