Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Why should I prevent direct access to PHP files that do not echo anything?

Tags:

security

php

For an example if I have a mail script or a script that writes to a database - scripts that do not echo anything important (other than a thank you, or an error message), but do a lot of important back-end work.

What could the possible security concerns from accessing them directly be?

Is it worth preventing direct access to such files?

They are receiving data using $_POST/$_GET sent trough contact forms and then either mailing it or writing it to a DB (in both cases after good validation).

Still, can the data that is being worked with there be accessed somehow (other than cracking my account and downloading them :)), since obviously opening such files in browser will not give any results to the attacker?

like image 214
Maverick Avatar asked Jul 03 '11 14:07

Maverick


People also ask

How do I protect PHP files from direct access?

or if you prefer to create a way more simpler approach, you can do this: <? phpif ( $_SERVER['REQUEST_METHOD']=='GET' && realpath(__FILE__) == realpath( $_SERVER['SCRIPT_FILENAME'] ) ) {header( 'HTTP/1.0 403 Forbidden', TRUE, 403 );die ("<h2>Access Denied!

How can php files be accessed?

A PHP file is a plain text file, so you can open it in any text editor like VI, Notepad, or Sublime Text.


2 Answers

Server misconfiguration

The security risk is, in case the web server fails to execute the php file (because configuration was reset), it's source-code will be displayed inside the browser as plain text. And you probably want to prevent that.

Wrong Context

Next to that scenario, another problem is, if the file actually does something with your database data for example, calling the file even w/o any direct output will have influence of indirect output. This is normally unwanted as well.

In your case it sends an email even, so direct requests can be used to send emails. That is probably unwanted as well.

Not to mention the risks this can have in getting your stuff penetrated. Not that this would be the only place where it is possible, but you should keep the surface small.

Improved File-Handling

The best approach however is to store the applications code outside of the webroot, so that those files are never accessible by a direct HTTP request.

like image 74
hakre Avatar answered Sep 23 '22 08:09

hakre


You just don't know what the script will do when executed out of context, so first of all, it's a good thing to prevent that from happening. Preferable this is done by setting a variable (or rather a DEFINE) in you entry page and make all other files check if it is set.

Then, it's a good thing to put the other files in a separate directory, outside your document root. This will prevent the scripts from being downloaded. That should never happen, because they are usually parsed, but a single error might cause PHP to be disabled in which case, the php files are fed through Apache as if they are plain text files.

If people can view your code, they may find out about data structure, maybe passwords, and vulnerabilities in your code.

So, if possible, put your files outside your documents root. If you do that, you won't need to check for that define, but it won't hurt if you do.

like image 38
GolezTrol Avatar answered Sep 24 '22 08:09

GolezTrol