Tip 1: Login Page/Authentication

Let’s start with the basic example, which you can find in all those so similar tutorials… First of is the login form:

<form action="login.php" method="post">
    <input type="text" name="username" />
    <input type="password" name="password" />

    <input type="submit" name="Login" />
</form>

Very complex html code, I know. It took me around 10 minutes to write it. Now for the php script that does all the work. NOTE: In this example and all to follow we always assume a mysql connection has been made and that sessions are started.

$username = mysql_real_escape_string($_POST['username']);
$password = sha1('salt'.$_POST['password']);
$result = mysql_query(
    "SELECT id
     FROM users
     WHERE username='$username' AND password='$password'
     ORDER BY id"
);
if(1!=mysql_num_rows($result)) {
    echo 'Login failed, username or password was wrong!';
    exit;
}
$_SESSION['auth'] = true;
$_SESSION['username'] = $username;
$_SESSION['id'] = mysql_result($result, 0);
echo 'Logged in!';

If everything is clear till now than we can move onward… (with this first section I’ve done a summary of all the secure login scripts tutorials)

Tip 2: Bruteforce?

Such a rudimentary attack that people almost forget about it. And most of the time it can be invisible to the websites administrator because POST requests aren’t logged by default. You may remember this from my article Logging the HTTP requests! But I’m not going to use that, because I want to keep all this simple, as simple as possible. So then, we will assume we got a table which is cleared daily (cron?) and stores only the username in the table. One columned table. (I told you that I’m gonna keep it simple) Then the following lines would be also in the login script (before the login query):

$counter = mysql_result(
    mysql_query(
        "SELECT COUNT(*)
         FROM attempts
         WHERE username='$username'"
    ),
    0
);
mysql_query("INSERT INTO attempts VALUES('$username')");
if($counter>=10) {
    echo 'Bruteforce attempt detected or more than allowed logins per day exceeded!';
    exit;
}

As you can see the drawback for this is that while protecting the users from bruteforce attacks, it may also (and it’s likely) to lock them out. Luckily for us there is a solution for the problem. We add another column to our table attempts of type char(2) in which we store the current hour. Basically we limit the number of logins per hour.

$counter = mysql_result(
    mysql_query(
        "SELECT COUNT(*)
         FROM attempts
         WHERE username='$username'
         AND hour='".date('G')."'"
    ),
    0
);
mysql_query("INSERT INTO attempts VALUES('$username', '".date('G')."')");
if($counter>=3) {
    echo 'Max number of logins per hour exceeded!';
    exit;
}

Now it looks a little better, but still it misses something…

Tip 3: IP Ban List

You could use ban lists for various reasons, from allowing “known attackers” to blocking access via proxy. Generally people tend to use .htaccess files for blacklisting, but I will stick to PHP and MySQL for the example. NOTE: On medium to large websites a database (MySQL) – backend (PHP) application would stress pretty much the database. The following code should be inserted before the max number of logins per hour check.

$max_counter = mysql_result(
    mysql_query(
        "SELECT COUNT(*)
         FROM attempts
         WHERE username='$username'"
    ),
    0
);
if($max_counter>9) {
    mysql_query("INSERT INTO banlist VALUES('".$_SERVER['REMOTE_ADDR']."')");
}

And the following line on the first line of the script.

if(1==mysql_num_rows(
    mysql_query(
        "SELECT 1
         FROM banlist
         WHERE ip='".$_SERVER['REMOTE_ADDR']."'"
    )
)) {
    echo 'Your IP address is in the ban list!';
    exit;
}

Of course you could dump the IP Address list from time to time from the database, but the following solution is a better one because it does not involve high stress on database.

Tip 4: reCAPTCHA

CAPTCHA is a good way to protect a web page (login page, important forms) from bruteforce and CSRF attacks. But we are not talking about self made CAPTCHA’s, you don’t have to reinvent the wheel… in a cubic form. That’s right, most of those who write there own CAPTCHA’s tend to make them weak or impossible to use (yes, Rapidshare’s CAPTCHA is one of those). You should use a good and public CAPTCHA, like reCAPTCHA. Also don’t over use them, you have to think of CAPTCHA’s like door keys. It’s very good to have one to your entrance door, but having to unlock the door for every room can be quite annoying, if not frustrating.

Tip 5: Encrypted login information

You either should use SSL or (if not available) frontend encryption (hashing in our case). A good example of such an implementation would be userAtuh’s one. You can find available md5/sha1 hashing library’s written in javascript around the web. One such an example is Paul Johnston’s Javascript MD5 library which is stated to be used by Yahoo on several non SSL pages. Can’t tell if it’s true or not, didn’t check it out, but for those who know Trilulilu (especially Romanian comrades) I can tell you that they implemented it in their flash player, for “encrypting” the source of their media (did I say too much?=).

Tip 6: Legitimate Requests (CSRF free)

As mentioned before excessively using CAPTCHA may be annoying, except in the case that the admin panel is designated for only one person (yourself) and you can bare completing on every important request a CAPTCHA field. For the other cases you could take a similar approach. On request of a page with an important form you could generate the token in the following way.

$_SESSION['token'] = sha1(rand());

And inside the form you could place it like…

<input type="hidden" name="token" value="<?php echo $_SESSION['token']; ?>" />

While in the form processing page you should deal with it as in the following code.

if($_SESSION['token']!=$_POST['token']) {
    exit;
}
$_SESSION['token'] = sha1(rand());

Also a better way would be by using mt_rand() and seeding it with a secret method. Like for example the sum of the numbers from the session id.

Tip 7: Protect your includes/secure pages

If you develop your web application in a similar manner as myself than probably you include the admin pages, rather than use one single over bloated file. And it’s a common mistake to not protect those files from direct access. I’ve seen cases of obscure naming of the files, which are not secure if the attacker can get directory information in a way or another. Although are very interesting. Why? Because security by obscurity can be very fun an creative, even useful sometimes if build on top of a secure design. Like for example when using a MySQL database (version 4, so no information_schema database available) and obscuring the table names. Coming back to our subject, you could protect your included files by using the following line of code.

if(!defined('PROTECTED')) { exit; }

While defining the PROTECTED constant in the script which includes the files (which we assume you protect). You can secure your main files (those who include files) in a similar way.

if(!$_SESSION['auth']) { exit; }
define('PROTECTED', true);

Tip 8: Password Change

When making a password change functionality don’t forget to ask the user for their current password. Many think that if a user is logged in and no CSRF could take place they are safe and thus don’t need to ask them for their current password. It’s wrong to think like that because Session Riding attacks are more frequent than you think. And it’s not such a big deal of doing this, it only takes an extra where clause in the update syntax.

$old_password = sha1('salt'.$_POST['old_password']);
$new1 = sha1('salt'.$_POST['new1']);
$new2 = sha1('salt'.$_POST['new2']);
if($new1!=$new2) {
    echo 'Your new passwords do not match!';
    exit;
}
if(mysql_query(
    "UPDATE
     SET password='$new1'
     WHERE id='".$_SESSION['id']."'
     AND password='$old_password'"
)) {
    echo 'Password successfully changed!';
}
else {
    echo 'Password couldn\'t be changed!';
}

Tip 0

This are the most common approaches which should be taken when coding login scripts/admin panels. Also they are the most common neglected aspects. Kind of paradoxical in a way. And that;s not all, if we think of HTTP Redirects which by the way haven’t been treated because latest versions of PHP protect you against HTTP Response Splitting. Another thing I didn’t treat was XSS, which I think (and maybe you would approve) doesn’t make a part of this subject, it concerns the way you implement functionality in your pages. I often wonder why even give power to the user, like for example in a comment form. Why give him even the ability to post link (and convert them to link)?

Anyway, as you can see I didn’t post a ready to use script/class because I wanted you to understand the concept behind login/admin panel security. Not just copy-paste the code and cross your fingers that it will work.

UPDATE: On Ronald’s suggestion I replaced the md5 hashes with sha1 hashes, even salted them. Also modified the MySQL code to order the result by id, just in case there where two accounts with the same login information (which shouldn’t, if you properly did the checks in the registration page, if uses any).

Logs, and I’m speaking about logging the HTTP requests, can help you very much. With the use of logs you can predict defacements: someone constantly trying to inject sql commands, who knows, maybe he’s on to something. Also these logs could help you prevent bruteforce attacks (if such protections weren’t implemented in the original login scripts). Needless to say that it will help you (probably) trace back a dumb attacker.

A rudimentary logging system would look something like this (assuming that a mysql connection has been made before):

function sqle($in) { return mysql_real_escape_string($in); }
function start_log() {
    $referer = sqle($_SERVER['HTTP_REFERER']);
    $uagent  = sqle($_SERVER['HTTP_USER_AGENT']);
    $iproxy  = sqle($_SERVER['REMOTE_ADDR']);
    $exactly = date('r');
    $model   = "INSERT INTO <TABLE> (iproxy, referer,
        uagent, exactly, data) VALUES ('$iproxy',
        '$referer', '$uagent', '$exactly', '<DATA>')";

    if(isset($_POST)) {
        $data  = sqle(serialize($_POST));
        $query = str_replace('<DATA>',$data,$model);
        mysql_query(str_replace('<TABLE>','postlog',$query));
    }

    if(isset($_GET)) {
        $data  = sql(serialize($_GET));
        $query = str_replace('<DATA>',$data,$model);
        mysql_query(str_replace('<TABLE>','getlog', $query));
    }
}

As you can see we have two tables declared in the same way, one named ‘postlog’, while the other ‘getlog’. From this point on you can make scripts that will check for xss, sql injection, lfi/rfi attempts.

I, for example, use it to track those trying to bruteforce my login credentials. And for monitoring wrong entered passwords, if any.

Another thing to note is that the script logs everything passed via a request, so it’s not recommended to add on login pages without setting an exception for the password field.

Another security enchantment would be to have the tables inside another database than the one you’re using for the website, so in case of an SQL injection no sensitive log data would be revealed (sensitive if you wouldn’t add exceptions as mentioned above). And how it would be this the best way to achieve? By adding a mysql connection to the example above. Upon inclusion the code executed would be the following

//some general inclusion you make
//include logger.php (this is our script expanded)
function sqle($in) { ... }
function start_log() {
    $handle = mysql_connect('host','user','pass');
    mysql_select_db('logDB', $handle);
    ...
    if(isset($_POST)) {
        ...
        mysql_query(
            str_replace('<TABLE>','postlog',$query),
            $handle
        );
    }
    if(isset($_GET)) {
        ...
        mysql_query(
            str_replace('<TABLE>','getlog',$query),
            $handle
        );
    }
    mysql_close($handle);
}

Another thing to note, is that the user of the website database shouldn’t have rights upon the log database. You should create a special user just for the logging part.

Also if you like automated stuff, as I do, you would love a logrotate-like implementation which you could cron:

mysql_connect('host','user','pass');
mysql_select_db('logDB');

$date = date('Y-m-d');
$path = '/home/logs/';
$file  = $path.'default.txt';
$query = "SELECT * FROM <TABLE> INTO OUTFILE '$file'
         FIELDS TERMINATED BY ' ' LINES TERMINATED BY 'n'";

mysql_query(str_replace('<TABLE>', 'getlog', $query);
rename($file, $path.$date.'(GET).txt');

mysql_query(str_replace('<TABLE>', 'postlog', $query);
rename($file, $path.$date.'(POST).txt');

About logs (and logging) that’s it for the moment. Maybe I’ll do another time an article about analyzing HTTP logs.

Another thing I wanted to mention, is that there is a similar approach found on the web via a wordpress plugin. Wanted to share it but unfortunately didn’t find it while writing the article.

P.S. Didn’t write the table creating syntax, but you can do it yourself. Not much into it, a bunch of varchar fields…

UPDATE: did some minor editing, upon renaming the files they would have been put in the scripts executing directory.

The next section of the guide is about crawling code, what to look for in JAVA/ASP/JavaSript.

I’ll skip the rest (I’ll let you discover it) and only mention the “example by technical control”, section which I would recommend to any web developer (regardless of language) because It points out every aspect for the following technical controls: authentication, authorization, session management, input/data validation, error handling, secure deployment, cryptographic controls.

That being said, you can read the guide on-line at owasp.org, or download the pdf version from lulu.com.

Filters

In the filters extensions we have 3 types of filters: validate, sanitize and other filters. Let’s take em each separately and see what the extension has to offer us.

Validate Filters
• Data Type Validation
  • FILTER_VALIDATE_BOOLEAN

    Validates if the specified variable/value is a boolean value.

  • FILTER_VALIDATE_FLOAT

    Validate if the specified variable/value is of type float.

  • FILTER_VALIDATE_INT

    Besides the fact that it validates integers it allows you to specify a range in which the specified variable or value should be. It also allows you to validate octal and hexadecimal numbers.

• String Validation
  • FILTER_VALIDATE_EMAIL

    Validates if the variable/value is a well formed email address.

  • FILTER_VALIDATE_IP

    Can be used for validating IPv4/IPv6 addresses, having flags to disallow reserved/private IP ranges.

  • FILTER_VALIDATE_REGEXP

    Validates variable/value with regular expressions.

  • FILTER_VALIDATE_URL

    Validate URL’s. I wouldn’t recommend it though, since it validates 'http://...'. Better of with regular expressions here.

Sanitize Filters
• FILTER_SANITIZE_EMAIL

  I highly recommend to not use this filter, because it won’t sanitize the email address. The characters !#$%&'*+-/=?^_`{|}~@.[] will remain intact.

• FILTER_SANITIZE_ENCODED

  URL-encode string, optionally strip or encode special characters.

• FILTER_SANITIZE_MAGIC_QUOTES

  Applies addshashes() to the specified variable/value. Seriously, shouldn’t this be extinct already. I though we should have left them behind once we moved away from PHP 4.x. Try to not use this one, because in some SQL systems backslashes are not escape characters.

• FILTER_SANITIZE_NUMBER_FLOAT

  Remove all characters except digits, +- and optionally .,eE.

• FILTER_SANITIZE_NUMBER_INT

  Remove all characters except digits, plus and minus sign.

• FILTER_SANITIZE_SPECIAL_CHARS

  HTML-escape '"<>& and characters with ASCII value less than 32, optionally strip or encode other special characters.

• FILTER_SANITIZE_STRING

  Strip tags, optionally strip or encode special characters.

• FILTER_SANITIZE_STRIPPED

  Alias for the above filter.

• FILTER_SANITIZE_URL

  Remove all characters except letters, digits and $-_.+!*'(),{}|^~[]`<>#%";/?:@&=.

• FILTER_UNSAFE_RAW

  Do nothing, optionally strip or encode special characters.

Other Filters
• FILTER_CALLBACK

  Call user-defined function to filter data.

As you must have noticed the sanitizing filters are pretty bad, some even repetitive. Although haven’t marked red all of them, I surely won’t use them. For sanitizing (against XSS) I’ll use good old strip_tags() combined with htmlspecialchars() because this way I can define quote style encoding, and charset in which to encode. As for safe SQL queries, I use db specific functions.

Functions

Ok, so we had some complains about the filters. But let’s look beyond that for a moment and see what the filtering functions have to offer us.

• filter_has_var

Through this function we can check if a POST, GET, ENV, SERVER, COOKIE value has been set.

if(filter_has_var(INPUT_POST, 'submit')) {
  echo 'yes the submit value has been set';
}

Although this might seem similar to a isset() usage, be not fooled by it. It (probably) takes a snapshot of all the superglobals (POST, GET, ENV, SERVER, COOKIE) so…

/*
 submit isn't set
*/
$_POST['submit']=1;
if(filter_has_var(INPUT_POST, 'submit')) {
  echo 'this will not be echoed';
}

Is this a good thing? Well, it depends. Haven’t seen till now somebody who controlled the flow of the application (in a script) through setting/unsetting a value in the superglobals, but I have seen hand coded register_globals implementation (for backwards compatibility) in PHPList which permitted that the SERVER['file'] (named something like that) to be overwritten and making it vulnerable to remote file inclusion. So in that particular scenario it would have helped.

• filter_id and filter_list

One returns the numeric value of a filter, while the other returns a list of filters… moving on.

• filter_input and filter_input_array

The (ONE) function for the “Data Filtering Extension”. I’ll post an example from the documentation.

$search_html = filter_input(
    INPUT_GET,
    'search',
    FILTER_SANITIZE_SPECIAL_CHARS
);
$search_url = filter_input(
    INPUT_GET,
    'search',
    FILTER_SANITIZE_ENCODED
);

echo "You have searched for $search_html.\n";
echo "<a href='?search=$search_url'>Search again.</a>";

• filter_var and filter_var_array

It works in the same way as filter_input, just that now you can use the filters on variables/string… these examples are also from the documentation.

// will validate
var_dump(filter_var(
    'bob@example.com',
    FILTER_VALIDATE_EMAIL
));

// will fail (return false), because it
// misses the scheme (http://)
var_dump(filter_var(
    'example.com',
    FILTER_VALIDATE_URL,
    FILTER_FLAG_SCHEME_REQUIRED
));

Should I use it?

Well, can’t say for sure. The validation filters seem pretty good unless you count the URL one… actually that could be a good filter also if you shouldn’t add 3 flags to behave like you normally would expect…

The other reason why I can’t pronounce a final answer (maybe someone who reads this will) because I haven’t checked the source code of the extension…

You have more information about it (not quite that big of a difference) from the online documentation page found here. Waiting your opinion on this one…

Update: Chuck Norrises was here and updated the text, removing my opinion of vulnerable code. eof!

And ignoring this warning is half as bad as having a sql injection vulnerability. Even if home users no longer are a part in a shared network thus sniffing is highly improbable, companies have LAN’s which would make a sniffing attack possible (if the sysadmin didn’t do his job). Throwing away all your security implementations, password enforcements…

SSL is the solution for this case but isn’t necesarily needed. Here comes in userAtuh. Yes it’s a typo, but who cares how it’s called as long as it does a great job?

UserAtuh is a php/js library used for serverside/client side password encryption, ment to mask the password sent by login forms. You can download it from it’s project page on SourceForge.

How does it work? Actually it’s quite straight forward, but I could better show it’s working by pointing out the key portions of code.

It all starts with the login form with has defined to the on submit event assigned to the setEncryption() function, which: hashes the password, joins it with the username and key and double hashes the result storing it in a hidden input field.

Upon form submision the only two values that are requested are the username and the result of the setEncryption() function. The rest is ignored. Forgot to mention that the setEncryption() function also changes the password from the input field with a substring of its result.

The authentification is done by the function with the same name from the KeyHandler object:

public function authenticate($name,$encodedPass,$sha1=true){
    //get the last key that was generated for this
    //session
    $ip = getenv('REMOTE_ADDR');
    $key  = $this->_dba->getKeyFromDB($ip);

    //check if a user exists with this name
    if ($this->_dba->userExists($name)==false) return false;    	

    //retrive the password for the user
    $pass = $this->_dba->getPass($name);

    //make sure password is hashed
    if (!$sha1) $pass = sha1($pass);

    //create a hashed string from the date collected
    $encoded = sha1(sha1($pass.$name.$key));

    //generate a new key, so the last key won't be usable
    $this->generateKey();

    //check the hashed string with the key sent by the
    //client side
    return ($encodedPass==$encoded);
}

Simple, easy, useful. It’s implementation can take at maximum a couple of minutes. Quick and painless, just as I like ‘em.