Paranoia or true security issue?

[Sleidia]

Hello,

I've just stumbled on the part of the PHP manual that talks about include(), and allthough I've used this features for a long long time I was surprised to read people who are trying to do everything possible to protect the access to their included files (eg: .ht, hidden directories, etc...).
Knowing the fact that the browser can't read what isn't echoed and knowing the fact that the user can't have any clue about the name of the included file, I'm wondering why they are trying to do that.

Did I miss something? Are they just on cafein?

One more thing. I've seen many sites that don't show the PHP filenames in the address bar by using folders instead or by configuring their httpd.conf to do so. Well, as I never took those precautions, I would like to know what the risk are to show the filenames as long as you pass variables with forms or cookies only.

Many thanks!

 

[skiflyer]

To the first part, it never hurts... but I think you're right, they're being a little paranoid.

To the second part, I think that people often do that (myself included) because I'd rather tell people to visit

http://skiflyer/

than

http://skiflyer/index.php

-Rob

 

[jimoblak]

The only reason I can think of why you may want to put includes in protected directories is if PHP and your server application go haywire (such as a bad httpd.conf file in Apache) and you start exposing PHP files as plain text. But if that happens, you've got other troubles to worry about.

 

[sleipnir214]

I can think of a practical reason to keep those files separate.

I have a client that uses a PHP website I helped create. The client wants to be able to edit some content, and upload the changes by FTP.

By my placing those included HTML files in a directory outside my web document root, I can better protect the code from any mistakes he makes deleting files. Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!

 

[DRJ478]

Hi!

You might want to have your include files outside of the web tree if they contain passwords and usernames for servers, MySQL for example.

Having them out of the web tree saves them from exposure through any web quirk. You can also allow access to just the web server.

If you have multiple people on a UNIX server there may be many ways to expose other's code. You could for example create a symlink with an .asis extension. That will just dump out the PHP code (assumung mod_asis is there and symlinks are enabled).

Again, I don't worry about my code, there's nothing to hide. The only things I place out of reach are passwords and usernames.

 

[Sleidia]

Thanks for the feedback!

I'll try to separate mysql security info in the future.

Two more things:

1) On the security side again, is it bad to use hidden form fields in order to pass variables? Is it safer to user global session variables instead?

2) Is it recommended to scramble the data before writing it in a cookie? (and then de-scramble when reading)

In case you have tips that can improve security, please let us know!

Have a nice day.

 

[sleipnir214]

If you are using session variables, there is nothing to scramble. The data itself is stored on your server -- only an index to where to find the data is stored on the client machine.

In terms of preventing knowledgeable users from abusing your site, probably the use of session variables is more secure. I can create a local HTML form which I can customize to submit input to your script to poison it's operation. It's also possible to forge a session variable cookie to get access to the information in another user's session variable, but I can't poison input directly. And with the way PHP generates its session variable indeces, guessing another user's session index is very tough.
Want the best answers? Ask the best questions:

http://www.catb.org/~esr/faqs/smart-questions.html

TANSTAAFL!

 

[danielhozac]

One reason to hide your PHP files as good as you can is if there is a bug in the webserver. IIS 4 (I think) had a vulnerability that allowed a user to add [tt]::$DATA[/tt] to the end of the filename which led IIS to believe that it wasn't ASP (or PHP), so it displayed the source of the script. //Daniel