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 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['password'] 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.
