Admin Files

You’re administrative home page (if you have an administration panel) should require the user to be of a certain level (state, whatever you want to call it) or in a certain user group. This value SHOULD NOT be stored in a cookie. Cookies can be modified too easily, and a nosy hacker would be able to be in your admin panel in seconds.

If you have properly secured your admin panel so that a regular user cannot access it, the next step is to secure the files (assuming you’re using a paged interface, which I will explain here).

A paged interface is one in which there is a home page that includes files in a pages folder of some sort. There are multiple insecurities that I will cover with this:

1. Users accessing the directory of the pages
2. Users accessing other directories through this system

1. Users accessing the directory of the pages

This can happen through multiple ways. One thing you must do is make sure that the file exists using if( file_exists( $file_name ) ), otherwise a user could enter an incorrect value and PHP will try to include a page that doesn’t exist. This step covers up your tracks for hiding the directory.

Next, you want to protect the files of the directory. My favorite way to do this is through a .htaccess file (for apache users). In the pages directory, add a .htaccess file with the contents:

This protects the path and sends the user to the specified path. This could be a home page, a 404 error, page, or whatever you want. I do know that some people don’t like this method, or don’t have Apache, so the other way would be to use define( ‘SITE’, true ); in your index page and then add at the beginning of everyone of your pages, add if( !defined(‘SITE’) ) die( ‘Hey! You\’re not supposed to be here!’ );

These methods protect your pages directory from direct access but still allow use of PHP’s include(  ), include_once(  ), require(  ), and require_once(  ) functions.

2. Users accessing other directories through this system

This is a pretty simple hack that I found once while testing out the security of my files. I thought “Well, if I can access anything in the pages directory, what’s to keep me from accessing other directories?”

This hack is quite simple actually, and allows the hacker to figure out entire directories of a website and generate plenty of errors. As I said in Part 1, to be good at security you need to learn to hack first. So here’s how the hack works:

[Some Website]/index.php?page=ucp

Seems pretty simple right? That’s how links work. The PHP script then performs include( ‘pages/ucp.php’ ), but what if we change UCP?

[Some Website]/index.php?page=../index

Hmm… PHP interprets this as include( ‘pages/../index.php’ ), which includes the index page again. Now we start getting errors. Actually, now it includes the index page over and over until the page breaks. Now the user can do some snooping around, with things like:

[Some Website]/index.php?page=../admin/delete_user&id=1

Using things like this the user can access admin/delete_user.php?id=1 and wreak havoc on the website. The simplest protection ever can fix this:

$page = str_replace( ‘../’, ”, $page );

And you’re done!

Up Next: PHP Security: Part 3 – XSS Worms/Hacks

One of the best ways I find to be able to make a secure website is to try and find possible insecurities in OTHER websites (AKA, hacking). Try and go to a website and put a few hours into finding a security problem. Maybe your website isn’t secure against this?

Part 1 – SQL Injections

SQL Injections are one of a programmer’s biggest nightmares. SQL Injections can be used to steal, delete, or edit data that is supposed to be protected. Like you can use SQL for your websites, SQL might also be able to be injected into your code. Let’s take a normal login form, for instance:

<form method="post">
<label for="username">Username:</label><input type="text" name="username" id="username" />
<label for="password">Password:</label><input type="password" name="pass" id="password" />
</form>

This simple little script will give us a login form. Now the PHP side of things will do something like so:

<?php

$username = $_POST['username'];

$password = $_POST['pass'];

$user = mysql_fetch_array( mysql_query( "SELECT `id` FROM `users` WHERE `username` = '{$username}' AND `password` = '{$password}' LIMIT 1" ) );

?>

Simple enough, right? Maybe you encrypt your password (which we will talk about in another part), but that’s beside the point.

The Problem:

Now a hacker would enter something like this into the username field: ‘ OR ’1′ = ’1′# and then the query would look like so:  SELECT `id` FROM `users` WHERE `username` = ” OR ’1′ = ’1′#’ AND `password` = ‘{$password}’ LIMIT 1

This would allow the hacker to access accounts without even having a password to the account. The # escapes the rest of the query so that SQL doesn’t take it into account.

The Fix

Now to fix this problem we have to “escape” the data. In PHP, a “\” before an apostrophe. I use a global clean so I don’t forget to clean out any inputs. This cleans out ALL cookie, session, POST, GET, and REQUEST data.

The Function:

function Clean( $var )
{
if( is_array( $var ) )
{
foreach( $var as $key => $val )
{
$var[$key] = $this->Clean( $val );
}
}
elseif( is_string( $var ) )
{
$var = str_replace( '\&', '&', escapeshellcmd( htmlentities( $var ) ) );
}
else return;
return $var;
}

This function grabs $var and cleans all of its values, returning the sanitized variable. The escapeshellcmd(  ) function cleans different SQL-dangerous values,while the htmlentities(  ) function cleans things like “<” or “>” (HTML Entities). The use of the Clean(  ) function:

$check = array(
	'_ENV',
	'_GET',
	'_POST',
	'_FILES',
	'_COOKIE',
	'_REQUEST',
	'_SESSION'
);


foreach( $check as $key => $elm )
{
	${$key} = Clean( ${$key});
}


This example will clean all inputs to DB friendly values! This also cleans out things like <script> or <a> that could possibly lead to dangerous outputs.

Up Next: PHP Security: Part 2 – Protecting vulnerable files

1. Allowing a background to be set with CSS or a transparent background
2. Removing borders from around the iframe (they look like crap)

The Background

In Internet Explorer, if you try to add a background (or have a transparent background) with your page’s CSS it doesn’t work. Instead, it keeps a white, boring background from the iframe (assuming the iframe has no background set). This little code will fix this problem, allowing transparent or colored backgrounds to be set through CSS.

Inside of your <body> tag in the HTML of the iframe, set the background style to “inherit” (<body style=”background:inherit;”>) and you can have a background using CSS from your page. It’s that simple.

Note: If you are making a transparent background, you need to add allowtransparency=”true” to the <iframe> tag as one of its attributes.

Note: If you want to make this iframe of a page that you cannot edit, look into using PHP to modify the <body> tag.

The Border

This one is just as simple, and can be done straight from the HTML. Add to the <iframe>’s attributes the following: frameborder=”0″

My Jobs:

• Javascript/AJAX for an interactive front/back -end interface
• PHP/MySQL for a secure but fast server
• CSS/XHTML for a dazzling look

Expect more updates on WGCup in the future.

Zane

I hope to install (or create) some good addons for WordPress pretty soon.

Zane