newsessionkey.php

The newsessionkey.php script is sent an XML file containing the UserName of a person who wants a new random session key to use for authentication.

The XML document sent looks like

<root>
<username>UsersName</username>
</root>

Where the UsersName is the name the user entered in the login screen.

Cookie

The newsessionkey.php script tries to establish a cookie that contains a random SessionID for the purpose of identifying a client computer. This cookie is given a time to live of 2 months. The random SessionID in the cookie is not to be confused with the random key sent back to the client for authentication however. This cookie is used for only one purpose and that is to identify a client computer so that we can block that computer due to excessive login failures over a period of time. The compromise of this cookie would not gain an attacker anything of value. During login failures the value of this cookie is included in the entry that is inserted into the failedlogins table.

$HTTP_RAW_POST_DATA

After the cookie maintenance the script grabs the XML data that was sent and parses out the username.

Header

The script begins building the response XML by defining a few header entries for the document. header("Cache-control: private") instructs proxies in the path not to cache the page.

Response XML

The response XML looks like

<?xml version="1.0" encoding="UTF-8"?>
<root>
<sessionkey>21232f297a57a5a743894a0e4a801fc3</sessionkey>
</root>

A random session key is sent back regardless of whether the username was valid (exists in the users table) or not. Only a valid username will result in an entry in the sessions table and will result in a successful authentication if the correct password is entered.

Validation

It is important to note that validation needs to occur on the server side of every transaction despite how I may attempt to stop invalid user input in the client. There is nothing that would prevent someone from sending data to the server side scripts from a client application they have created.

mysql_real_escape_string

This is a handy function that escapes out characters that would be used to inject executable code into an SQL statement. I've seen folks say you 'must' use this for all data that you wish to include in an SQL statement. This is not entirely correct as if you have already validated the data as a number or date for example it could not contain executable code and using mysql_real_escape_string would do little more than add CPU cycles to your code. Since the only character filtering I've done on the username was done in the client I need to additionally ensure on the server side that the username is safe to use in an SQL statement.

enabled

I have included the required code to handle the case where a user has been disabled. This gives me a way to disable a user without removing them. Perhaps I want to be able to enable them again later and don't want the user to have lost any of their profile data or their password. Perhaps I want to prevent someone that I have blocked from setting up another account with their same email address. Or I could even use this to add usernames that I don't want anyone to be able to use.