PHP & Apache Server Security Questions

[justted]

Hello,

I was wondering if I could clarify some recent information I have found on the internet regarding PHP security. Im a self taught PHP/MySQL amateur and therefore have a very skethcy knowledgebase of the coding. lol

Im currently developing a website and would obviously like to ensure its as secure as possible from malicious activity and attacks....

My first quesion is regarding the PUBLIC_HTML folder and the use of PHP scripts and MySQL.

Am I correct in saying that any file within the public_html folder is basically open to attackers. For example ...say I have a registration script where members can register on my site.

The register.php file is the actual form that members fill.

The register_proceed.php file is the actual php code that checks, inserts and accesses the MYSQL database.

If I place both these files in the public HTML file then they are potentially at risk from being hacked right?

However ... Am I right in saying and is it possible to say for example set up a folder called register_inc at the public_html level of my server and then place the register_proceed.php file in this directory so that its not visible to the domain!

What exactly would this achieve in terms of security? Does this mean that no one can hack that script and that it can happily proceed to register the member?

Should this be done with all files that process my scripts and changes my mysql database?

Is this as easy as sending the form data to the register directory outside the public html folder and then it sending the confirmation back or is it much more complicated?

My second question is regarding cron jobs!

If i set up a cron job on my server it seems I have to insert the database connection details to allow it to work!

Is there any security loops that setting up cron jobs may cause?

I would really appreciate any feedback on this matter as now I am really interested in finding out all I can (in an easy to understand way) about website security! :OD

Regards
Justin

[cwarn23]

My first quesion is regarding the PUBLIC_HTML folder and the use of PHP scripts and MySQL.

Am I correct in saying that any file within the public_html folder is basically open to attackers. For example ...say I have a registration script where members can register on my site.

The register.php file is the actual form that members fill.

The register_proceed.php file is the actual php code that checks, inserts and accesses the MYSQL database.

Well to make a page viewable you will need to appear in public domain meaning if you hide the file from the users, the users will not be able to view or load those files. However there is one alternative. And that is storing all your sensitive php files inside a mysql database so the php code is actually inside a mysql database. Then to read the file, you would need to send the mysql data to the apache/php tmp folder then use the include function on the file in the tmp (not in public_html) folder or something like that. At least that is what I read a while ago.

If i set up a cron job on my server it seems I have to insert the database connection details to allow it to work!

As for the above quote/question, although I don't know much about crone jobs, I believe the same php rules apply meaning that to use mysql, you will need to establish a connection so mysql knows which user is being logged in. And so yes you probably will need to establish the php - mysql connection in crone jobs.

[digital-ether]

Hello Justin,

Security in PHP is the same as any server side programming language, they are all vulnerable to the same attacks.

PHP has a history of being vulnerable mainly because of its popularity.

1) More non-security aware developers use PHP then any other language, so there code has flaws almost 100% of the time.
2) There are more sites written in PHP then any other server side language, thus more chances to find security holes amongst so many.

PHP has had a rep of having security problems in the PHP core itself, but this has improved greatly. Much of which can be attributed to the Hardened-PHP project.
http://www.hardened-php.net/suhosin/

If you are using a shared host, ask if they have PHP4 with the suhosin patch or PHP5 or higher. I'm not sure if PHP5 still needs Suhosin but it seems many large sites aren't using the two together so I believe PHP5 has a better security then PHP4 natively.

As a developer I think there are just about 4 or so main security vulnerabilities to keep in mind when coding.

1) XSS (Cross Site Scripting)
This is the most common vulnerability in any website. It is estimated that around 70% of websites have an XSS vulenerability.
http://en.wikipedia.org/wiki/Cross-site_scripting

A simple example in PHP:

<?php

echo $_GET['username'];

?>

What happens is the PHP echo's a variable passed in from HTTP (in this case a GET parameter). If a user typed in the browser URL:

site.com/example.php?username=<script>alert('document.cookie')</script>

They would see the cookies saved for their session. An attacker can make a user click a link that will also retrieve these cookies from JavaScript, and send it to them - without the user knowing.

To prevent it:

<?php

echo htmlentities($_GET['username'], ENT_QUOTES, 'UTF-8');

?>

This will turn any HTML into HTML entities. You also have to specify the encoding you used for the page (in this case UTF-8). The reason is so PHP codes not mangle the character encoding, which can also result in XSS.

2) XSRF - Cross Site Request Forgery
This is similar to XSS and just as common or maybe even more common. It is when a website fails to protect it's users from being used by 3rd parties without their knowledge.
http://en.wikipedia.org/wiki/Cross-site_request_forgery

And example of this in PHP is a simple comment form.

<form action="submit.php">

<textarea name="comment"></textarea>
<input type="submit" value="Post Comment" />

</form>

Imagine the comment form is only available for logged in users. Now an attacker can just send an already logged in user the URL:

site.com/submit.php?comment=I hacked you&submit=Post Comment

So when the logged in user clicks on that link, they have posted the comment without knowing. This can even be done in a hidden frame, so the user never see's it.

So the attacker is using the user's already authenticated session (privileges) to do his/her bidding.

Preventing XSRF:

<form action="submit.php">

<textarea name="comment"></textarea>
<input type="submit" value="Post Comment" />
<input type="key" value="some_random_value" />

</form>

Notice the new <input> called "key". It will contain a random value remembered by PHP. This random value should be saved, and be unique for every form that is sensitive.

This way, the attacker would not be able to make the user post something on their behalf, since they don't know the value of "key".

(This only works if you don't have an XSS vulnerability of the page itself, as that can lead to the attacker knowing what the value of "key" is)

3) SQL injection

SQL injection is when an attacker manages to manipulate any SQL database queries in your website in a way you didn't intend.

Example:

<?php

$query = "SELECT * FROM users where password = '".$_GET['password']."'";
$result = mysql_query($query);

?>

Because the $_GET can be anything the attacker wishes to put in the URL, they could craft a URL like:

site.com/login.php?username=joe&password=nothing' or 1

Notice the ' in the value for the parameter "password"

This will make your sql query:

SELECT * FROM users where password = 'nothing' or 1

This would make it return the first user instead of the user with password = "nothing" since "or 1"is always true.

Preventing SQL injection:

<?php

$query = "SELECT * FROM users where password = '".mysql_real_escape_string($_GET['password'])."'";
$result = mysql_query($query);

?>

the function mysql_real_escape_string() will prevent any SQL injection by escaping any character that would otherwise terminate the string.

4) Remote File inclusion

Remote file inclusion is when an attacker can include remote file into your PHP code. This is the most dangerous attack, as it allows the attacker to execute arbitrary code on your PHP server.

eg:

<?php

include('/pages/'.$_GET['page'].'.php');

?>

With this code the developer is hoping to have a URL such as:

site.com/pages.php?page=home

And this would include the file:

/pages/home.php

However, any attacker can now place a URL such as:

site.com/pages.php?page=../../passwords.txt

And it would reveal the contents of the file passwords.txt

Or they could use it to include a remove file from their server, if the URL wrappers are enabled for file includes (which is common).

With these precautions in mind, I'll answer your questions:

My first quesion is regarding the PUBLIC_HTML folder and the use of PHP scripts and MySQL.

Am I correct in saying that any file within the public_html folder is basically open to attackers. For example ...say I have a registration script where members can register on my site.

The register.php file is the actual form that members fill.

The register_proceed.php file is the actual php code that checks, inserts and accesses the MYSQL database.

The public_html folder is the default web directory on many server setups. This has nothing to do with PHP, it is dependent on your web server and its configuration.

In order for a file on your website to be accessible, the web server must allow access to it from the public web.

Servers do this by designating a folder as the web directory or web root. In apache it is called the DOCUMENT_ROOT. So whatever is the document root, is accessible by anyone.

It can be any type of file, the webserver will try to send the file over HTTP when anyone asks for it.

If it is a PHP file, they the webserver will most likely be configured to send it to the PHP interpreter first, before receiving the output and sending it to HTTP.

Now a PHP file can include any file it has access to - even those below the web directory. If you have made sure there are no remote file inclusion vulnerabilities, then you are safe. However, many go to precautionary measures, and will keep sensitive files below the web root, so they are not publically accessible. Since a PHP file from above the web root can include it, but the server will not serve it to the public, then it is more or so protected from direct viewing.

Servers may sometime go into errors, and accidently serve a PHP file as plain text, this is way it is always safer to keep files below the web root if they contain sensitive information.

If i set up a cron job on my server it seems I have to insert the database connection details to allow it to work!

For cron jobs, it is better to have the file you're including in the cron below the web root. Then use the PHP CLI based interpreter. That is the interpreter that users the Command Line Interface.
http://www.php-cli.com/

So your cron command would looks something like:

/usr/bin/php -q /path/to/php/file.php

Sorry for the length of the post.

[justted]

Hello,

Thank you both kindly for the replies. Ether ... thank you for those points that you made. Im just about to go and see if I can check my code and ensure those are implemented. I may even have to consider re-coding the entire website as its based on a script I bought that was badly coded.

This way if I re-code it completly then at least id have full control and knowledge of every little thing. Its all very well buying these ready made scripts but you never know how security concious the developer was when making it. lol

Im just looking at getting my own dedicated server for the peace of mind and also improved security/performance etc. Im currently on a reseller and just hate the thought of sharing the server with other unknown websites. LOL

Anyway ... once again thanks to you both for the help. Will see what I come up with :p
Regards
Justin

[justted]

Hello again,

As it stands im having a few problems with my includes and my lack of knowledge again. lol

I wanted to clarify if im thinking along the right line here ....

Say I have a basic HTML form that a visitor can fill in called form.php

When the visitor sends this form it sends it to form.pro.php

In the form.pro.php I have my code which calls for the global settings page, the config and various other pages which as located in my hidden directories.

However ... if my code in form.pro.php first of all checks the user input and then if checks are TRUE ... I would enter the include: which would replace my current INSERT INTO table_name etc ...

I would then move this INSERT INTO table_name piece of code to the include file ... does that make sense and if so is that correct?

For some reason I had it in my mind to put the form.pro.php file for example in the hidden directories which obviously isnt correct.

Many Thanks and would apreciate any feedback or info

[justted]

sorry just to add something to that .... this include file that is located in a hidden directory would basically be the place where I store all my variables and database INSERTS,DELETE,UPDATE commands ?

Then I add the includes to the relevant pages that require the info and therefore would be protecting the certain variables and database details within the hidden files....

Would this be a correct statement??????

[nikesh.yadav]

thanks digital-ether,

for nice post

[justted]

Hello again ... Im having a nightmare trying to get my hidden directory to work! lol

I managed to find the PHP.ini file which is located on my server files in the Public Html folder.

I changed the include_path to the name of a folder called includes as below and then created a folder on the same level as my public html folder. I inserted a file include that connects to my database and then tested this out on my website.

However ...it couldnt connect and didnt work at all.

Is there something im missing in the actual include file or the one calling it? I thought you could type in the include "/filename"; as normal as the checks are meant to be made with the .: ?

Im totally confused now and no where near getting an understanding of these hidden files and directories. lol

Please help someone explain it?

Here is the code

;;;;;;;;;;;;;;;;;;;;;
; Paths and Directories ;
;;;;;;;;;;;;;;;;;;;;;;;;;

; UNIX: "/path1:/path2"  
include_path = ".:/usr/includes:/usr/local/includes"
;

[digital-ether]

Hi justted,

could you post some of your code, and directory structure if possible.

To include a file, it is good to use the full path.

eg:

/home/user/site.com/path/to/file.php

instead of:

file.php

Relative paths can be confusing. When you include a relative path, PHP will first look in the current working directory, then look in the includes_path you specify in php.ini, then try the current executing script.

The current working directory is the directory of the first script executed by the PHP interpreter. eg: if the URL was: site.com/index.php then the first script executed is index.php and the current working directory looks something like:
/home/usr/site.com/public_html/

If if you had included a file includes/db.php and that file included another file, db.config.php, then php will look for that file in /home/usr/site.com/public_html/ and not in /home/usr/site.com/public_html/includes/ which is a bit counter intuitive.

You can however change the current working directory using chdir():
http://www.php.net/manual/en/function.chdir.php

If you want absolute paths, it is good to work from your web directory. You don't want to use literal absolute paths as this binds you to the server you write your code in.

The web directory is available in PHP as:

$_SERVER['DOCUMENT_ROOT'];

So if you have a file under the document root, trackback from there using the ../ notation.

eg:

if you have your DOCUMENT_ROOT as:

/home/usr/site.com/public_html/

And have your includes in:

/homr/usr/site.com/includes/

Then use:

i

nclude($_SERVER['DOCUMENT_ROOT'].'../includes/';

This gives:

/home/usr/site.com/public_html/../includes/

Most PHP applications actually do the following. They will first find the web root using:

$document_root = dirname(__FILE__);

This has to be in a file in the web root however. Then calculate paths from there.

[jackiboa]

I may even have to consider re-coding the entire website as its based on a script I bought that was badly coded.