If you’re an online merchant, your server needs to be PCI compliant. Otherwise, you not only run the risk of being hacked and losing customer data, but you also run the risk of facing major fines. One fine would be enough to wipe just about any small business out.

New security challenges arise every day. In fact, they arise every hour, it seems. Will your site stand up to the challenge? Will it meet that challenge? Only by regular security scans will you know. Even if you’re not a merchant, you need scans, because I am willing to bet that you don’t want to be hacked. All sorts of unsavory things can occur if that happens.

You could lose your databases. You could lose all data on your server. Your users’ information could be compromised. There are many things that could happen, and none of them are pleasant.

So, contact me for your free security scan today. As I wrote earlier, all I ask in return is that you have a sincere intent of using my services.

There are certainly no security concerns involved here, but you probably don’t want to lose your visitors who may bookmark certain pages, nor do you want to lose search engine traffic, because the HTML links will still show up in those engines until they crawl your changes.

That’s where the 301 redirect comes in. This is the best sort of redirect to use, because it is search engine friendly. What it tells search engines is that the page has moved permanently to the forwarding location you provide, which in this case is a PHP file. Essentially, if you do it this way, the search engines won’t skip a beat, and you’ll keep your traffic. The last thing you want to do is let search engines crawl 404 errors.

If you need help with these sorts of things, or if you need a skilled PHP programmer to help you sort out your conversion, I would be more than happy to take a look at your specific needs, and devise a plan for you. This includes making sure that your PHP code and your setup is secure, as PHP is a valuable tool, but a potential security risk if not handled correctly.

My rates are reasonable, and I offer a wealth of experience that can benefit you. Simply get in touch with me for a custom quote!

If you have something along those lines that needs to be done, simply contact me, and we can discuss your needs in greater detail.

In addition to doing this sort of work, I run APNIC Solutions, Ltd., which is a leader in network and business integration. You can be confident that when you hire me for your PHP, web, or other needs, you are getting a competent, skilled industry leader who will do a smashing job for a reasonable fee.

Feel free to browse through my blog and read my articles on a variety of PHP and security topics. Then, get in touch with me to see what I can do for you! If all you need is a consultant to point you in the right direction and help you get to to the finish line, I would be more than happy and honoured to be that person.

While there are a lot of honourable programmers who offer their scripts for free, there are plenty of hackers who enjoy deploying applications that cause harm to others. I discussed this earlier, but it bears repeating: trust your source. Know your source.

This includes scripts that people offer for download on forums you may visit. There are plenty of good people out there who merely want to share their scripts and help, but your server’s security is very important.

A hacker doesn’t even need to gain access to your server. He or she can write a script and gain satisfaction from knowing their work is causing damage around the world.

Just be careful. Download from known and trusted sources, or if you have a script you’re unsure of, run it by someone you trust. You can even contact me, and I’d be more than happy to share my resume, and show you what I can do to help you secure your scripts and keep your server safe.

One simple way to secure your installation is to slightly modify your config.inc.php file:

Look for this line:

$cfg['Servers'][$i]['auth_type'] = ‘config’;

Change “config” to “http”. By doing this, you will require that the database information (username and password) be entered prior to accessing PHPMyAdmin. Of course, this only addresses attacks over the web. If someone tries to remotely connect to your database and knows the root password, or the credentials for any of your database, then you’re still vulnerable.

One way to address the security of your config.inc.php file is to secure the directory that it’s stored in. This is especially important if you should be on a shared server.

Of course, there is still the matter of your SQL port, 3306, being open to remote attacks. The solution to this problem can be found in the /etc/my.cnf file.

You need to add this line to make it so that only your server can connect to the SQL server.

Ensure that it’s under the “[mysqld]” section:

bind-address = 127.0.0.1

This sets it so that the SQL daemon only listens for connections locally, i.e. on your server. Anyone who tries to connect remotely will be denied. Now, the argument could be made that you could also try to add “skip-networking” to your my.cnf file, and then specify the path to your socket file, but you still need a way to administer your SQL, preferably via SSH. By adding the “bind-address” command, you can do just that.

The name of the game is security, and assumption. You have to assume that everyone’s out to attack you. If you think like that, you’ll narrow down all the ports that are exposed, and secure your server. Your SQL server is, like your DNS server, vital. It most likely powers your site. If the database is attacked, the damage can be considerable. Do understand that if a hacker is intent enough, they will find a way in, but by making it as difficult as possible, you reduce the chances of that happening.

Consider this: you accept input asking for a month or year. The problem is that a user decides to enter “”;rm -rf *” after the year, and in so doing could cause the deletion of your whole website. Obviously, this is not a good thing, so what to do? Data validation is the answer. As the name suggests, it validates or verifies data, ensuring that it complies to form.

In other words, when you validate data, you ensure that a user entered numbers for a year, and not a malicious command as shown above. Unfortunately, many webmasters have fallen victim to this, all because they didn’t tighten security on their server.

One solution would be to enter data in this manner:

$month = $_GET['month'];
$year = $_GET['year'];

if (!preg_match(”/^[0-9]{1,2}$/”, $month)) die(”Invalid entry. Please try again.”);
if (!preg_match(”/^[0-9]{4}$/”, $year)) die(”Invalid entry. Please try again.”);

exec(”cal $month $year”, $result);
print “

";
foreach ($result as $r) { print "$r
"; }
print "

“;

What this code does is this: it allows your user to enter a month and a year, say for a credit card or date of birth, but it also double checks the data, ensuring that it is in fact numeric data that a user entered, and not code that could cause you hours of grief.

Of course, there is more extensive code you can write which will validate further, but this data pertains strictly to the security of your server. You can, of course, add code that will ensure that a year is between, say 1900 and 2020, and that a month is between 1 and 12.

As an administrator or webmaster, you need to consider all data that a user enters questionable. By using this mindset, you’ll be in a position to prevent yourself from being vulnerable to malicious injection attacks. Too often, a webmaster has chosen not to take security measures because he or she assumed that no one would try something so awful as to delete someone’s data. As we see every day, however, there are people who think nothing of ruining peoples’ hard work, data, and electronic property.

If you don’t have secure PHP code, you may find yourself the victim of numerous type of attacks, including SQL injection attacks, which as the name suggest, goes directly after your database, which in most cases is the very heart of your website or application.

Sometimes, the most basic adjustments will go along way. One example is this variable:

register_globals

If you look in your php.ini file, and find that this variable is enabled, you may be putting yourself at risk, for all anyone has to do is add “?authorized=1″ to a URL on your site, and they will then gain access to sensitive information that you likely don’t want the average user to see.

The best solution here is to simply set register_globals to “off”.

Another mistake that many people make is that they fail to suppress PHP errors. When a PHP error occurs, and error reporting is fully enabled, a user can see a lot of information about your site, including exact paths. Of course, you don’t want this information to be readily available, so it would be a wise decision to suppress the errors so that they do not display in the web browser.

You actually need not change the error_reporting variable itself, because you still want to be able to see errors as the administrator. You just don’t the whole world to see them, too. To accomplish this goal, simply look for the “display_errors” variable, and set it to “Off”.

You will also want to set the “log_errors” variable to “ON”, so that the errors show up in your error log. If you turn both logging and display off, the potential exists for errors to still display, because the errors do need to be reported somewhere. But by confining it to the error_log, you and anyone else you grant administrative powers to will be the only ones who see them.

By doing this, you will prevent error messages from showing up on a user’s web browser, potentially giving them a detailed road map to the compromising of your server.

Also, make sure that there are no settings for error reporting in your .htaccess file, because these settings could override your default php.ini settings for that particular website.

These are just two examples of easy ways that you can secure PHP. There are, of course, many others. Though these solutions are simple, they go a long way, and the time invested in making these adjustments will pay dividends in the form of a secure server.

It is useful for a variety of things, specifically encoding non standard characters that may not be safe to pass around such as in a browser address bar or in a plaintext email..

Here’s one example..

<?php
$obj = new stdClass();
$obj->a = “test”;
$obj->b = “string”;
$obj->c = 12345;
$output = base64_encode(serialize($obj));
echo $output;

?>

This returns ‘Tzo4OiJzdGRDbGFzcyI6Mzp7czoxOiJhIjtzOjQ6InRlc3QiO3M6MToiYiI7
czo2OiJzdHJpbmciO3M6MToiYyI7aToxMjM0NTt9′

We could now pass this as an HTTP safe string between pages; decoding using $v = unserialize(base64_decode());

This is obviously not an optimal way of storing or passing this example data between various pages however is one example of how base64 encoding can be used.

As a website security consultant I advise you to ensure that your memcache server runs on 127.0.0.1 only and that you secure your server. Anyone with access to the server can telnet to the server’s local interface and get/set your memcache data.

I’ve used memcached for a number of PHP/MySQL projects, where I want greater cache control on database queries, than just relying on MySQL’s inbuilt caching abilities.

Now, whilst memcached should not be used to mask bad database design and optimization, or badly written SQL queries, it can help dramatically with queries that simply take a long time and have already been optimized as far as possible.

Assume that you had a simple database query wrapper:

function db_getrows($query)
{

$rows = Array();
$resource = mysql_query($query);
while ($rows[] = mysql_fetch_object($resource))
{

//do nothing

}
return $rows;

}

If you have no idea what queries are going to get passed to this, but simply want to cache all SELECT output, then modify as follows:

function db_getrows($query)
{

$rows = Array();
//Get the MD5 hash of the query, which we can use to identify it:
$hash = md5($query);
$memcache_obj = memcache_connect(”localhost”, 11211); //connect to memcached
$mem_get = memcache_get($memcache_obj, $hash); //If we had this query key stored in memcache, $mem_get will now contain the data, otherwise, it will be empty.

if (empty($mem_get))
{

$resource = mysql_query($query);
while ($rows[] = mysql_fetch_object($resource))
{

//do nothing

}
memcache_add($memcache_obj, $hash, serialize($rows), false, (60*60)); //add it to memcache for next time, have it expire in 1 hour (60*60 seconds)

} else {

$rows = unserialize($mem_get);

}
return $rows;

}

What will happen now, is that when a query is provided, we take the MD5 sum of that query. We then check to see if we have that query response in memcache already. If so, great, unserialize it and return it. If not, run the query, get the data, and add it to memcache with an expiry time of 1 hour.

Any queries to memcache will of course bypass the database alltogether therefore alleviating the load. Your only consideration is what to cache and the expiry time. If you cache the output of a SELECT query on say, the number of posts on your forum, it may not just keep that out of date for an hour, but could infact cause erroneous data to be inserted by your forum into your database. In that case, you can take a look through the code and find any instances where your forum post count may be updated, and add memcache_delete($memcache_obj, ‘key_to_delete’, 10); which will automatically delete ‘key_to_delete’ after 10 seconds.

You can also use 'SHOW' to display a wide range of information: http://dev.mysql.com/doc/refman/5.0/en/show.html

Now you can try the following:

<?php
$handle = curl_init();
curl_setopt($handle, CURLOPT_URL, “http://www.google.com/”);
curl_setopt($handle, CURLOPT_HEADER, 0);
curl_setopt($handle, CURLOPT_RETURNTRANSFER, 1);
$output = curl_exec($handle);
curl_close($handle);

print_r($output);
?>

You can also check http://uk.php.net/manual/en/function.curl-setopt.php to take a look at the other options that curl_setopt can take.

curl can also post data to the remote server via POST or GET and also has the ability to save and retransmit cookies.

curl -u username:password http://api.twitter.com/1/statuses/friends_timeline.xml

Which will get the statuses of all your friends. You can of course use PHP’s curl library just as easily as the command line, and my next post will focus on using php5-curl

Shameless plug: Why not contact me BEFORE this happens for a FREE basic web scan.

Shameless plug over, why not consider some of the things that can be done to help prevent a website breach..

First, concentrate on the box and LAMP environment as a whole. Here’s a top 10:

• Restrict or disable .htaccess type files. A lot of sites these days allow uploading of files, in whatever form that may come. Often, the code can be tricked into allowing an attacker to upload htaccess files to certain directories which could allow for scripts to be executed, or visitors to be redirected.

• Check your apache config, after tightening up/disabling htaccess, disabling cgi directories you might not need, and modifying limits.

• Consider mod_security

• Check your apache, php, mysql and related modules are up to date

• Firewall mysql externally and any other services that should not be accessed directly from the outside or are not necessary.

• Check your list of mysql users and make sure you only have the necessary privileges assigned to the various users.

• It’s common to find users on their own webservers connecting to mysql from their web code as the root user. Don’t do it. Create a user account for that particular site/database and assign it the tightest privileges. Do not connect to mysql as root unless necessary.

• Take multi day backups of database, code AND logs.

• Check the machine for word readable/writable directories.

• Restrict limits on hits/sec from IPs

Next, look to your web code, here’s a top 5:

• Look for SQL Injection opportunities. SQL Injection is NOT just prevented with escaping incoming strings..

• Check all input areas for XSS (Cross Site Scripting)

• See my PHP Security post

• Session ID Protection – can users overwrite cookie/session variables that you have set and taken for granted the fact that they shouldn’t be changed by the user? This is easy to do overwrite/exploit with ‘curl’ or ‘wget’

• How are you handling user data input? Sniffing plaintext HTTP or plaintext anything for that matter is very simple. All sensitive data should be sent over HTTPS. On that matter, are you storing the data safely afterwards?

Anything to add to this list? Please let me know!

There are a few general limitations that you’ll find. You have limited CPU power available, you have very little RAM available, and for more advanced operations and optimizations, your CPU will generally have a limited function set.

The usual good programming practices apply, but are of much greater importance. Specifically, don’t allocate memory that you don’t need, and dont put the CPU under undue stress with unnecessary or badly optimized loops. Taking C syntax and some pseudo code;

char *myvar = malloc(10240);
strcpy(myvar, somevar);
…

Where somevar has previously been limited to say 16 bytes of data, why just allocate an arbitrary large number (10KB) to myval?

Here’s another:

int ctr = 0;
int maxlen = 0;
for (ctr = 0; ctr < get_count(data); ctr++) { … }

Although this looks nice and tidy, why are we calling get_count to get the number of records each time the loop runs when it will never change?

int data_count = get_count(data);
for (ctr = 0; ctr < data_count; ctr++) { … }

makes much more sense.

Years ago, there was also a lot of manual assembler optimization that you could do before compiling. A popular one was replacing “movl %eaX, 0″ with “xorl %eax %eax” as the exclusive or result of two of the same value will be 0 and requires less processor time than the movl operation. Now, not only can most of this be done for you by passing the -OX flag to gcc, but a loop of 1 million movl’s took no more time than 1 million xorl’s on my processor, and I’m guessing the processor deals with this for you now anyway. Today, if you’re on a nonstandard platform and you’ve got the information that certain instructions are favored over others on your target, you’d be able to better optimize the assembler code before compile time.

The main thing to remember, is that sloppy programming that would have gone unnoticed on your super powerful CPU will bring your embedded application to a halt.

Look into PHP’s “safe mode” feature, ESPECIALLY if you’re running a webserver that takes the general public can upload scripts to. Here you’ll find a list of the functions disabled or restricted by safe mode. It is not strictly PHP’s job to restrict these types of functions, however unless you really know what you’re doing, the list of functions restricted by safemode is a good starting point for building secure applications. These are generally functions that allow file and directory manipulation, and socket manipulation. If it’s not possible within your environment to disable them all, disable as many of these functions as possible.

Although not that common, if I’m writing an application that heavily relies on functions that manipulate directories or sockets, I’ll prefer to create a C daemon or similar to handle this side of things and simply use PHP to communicate with it.
Within your code, do not ever assume any type of input given by a user or with the possibility of being manipulated by a user is safe. Take the following example:

readfile.php?file=…
<?php
$fh = fopen($_GET['file'], “r”);
…
?>

The attacker can specify ?file=/etc/passwd or anything else for that matter readable by the web user. Instead:

readfile.php?file_id=1
<?php
switch($_GET['file_id'])
{
case “1″:
$filename=”/tmp/myfile”;
…
}

Next, make sure register_globals is turned OFF in PHP’s config file. In all newer versions of PHP this is already done. register_globals automatically creates a variable called $username from a page called with page.php?username=adam. With register_globals off, this is only accessible via $_GET['username'] or $_REQUEST['username'].

This means that I could call page.php?user_id=1&username=admin. Your code should accomodate register_globals being turned on, and automatically check for this kind of variable poisoning however this is often overlooked.

Magic Quotes is a depreciated feature of PHP helping beginners write more secure code. All incoming input would automatically have the quotes escaped thus preventing SQL Injection. More advanced users that know what they’re doing can find this annoying, as it is not strictly PHP’s job to interfere with the input variables like this. Instead you should escape all input yourself with addslashes() or mysql_real_escape_string()

PHP error reporting is another important issue to consider. By default, any warnings and errors are printed out to the user. This often gives away directory paths, filenames, variables and all sorts of other information about the server and the script that should not be printed out to an anonymous user. Turn off error reporting to the screen and instead dump any errors to a log file an perhaps trigger an email to an admin.

These are just a few basic things to keep in mind to get started. User input can come in a variety of formats, and not just via the variables $_GET, $_SESSION, etc, etc. XSS (Cross Site Scripting) is another common attack method and something that will be covered in future articles.