How To Secure Your Web Accessable Database

When designing and programming a web accessable database application, you should keep in mind the following:

  • Always treat form input as tainted
  • Avoid reliance on JavaScript for security checking
  • Use proper authentication SQL logic
  • Storing of unhashed password data in cookies

Always Treat Form Input As Tainted

There’s one rule that you should remember when using forms for interacting with your database; Never assume that users will enter what you expect them to. Sure, most of the time, people will enter what you’d expect from them, especially if it’s labelled clearly.

For example, you’d expect a form with two fields; username and password, be used for entering the user’s username and password. In probably 99% of the time, your expectation would be realised. However, there are bound to be a few curious people who would enter specially crafted input to test your authentication mechanism. The manipulation of forms can be used to reveal or manipulate database information. This is commonly referred to as an SQL injection attack. I’ll give an example of such an attack later.

If their intentions are less than noble, you might be facing with an array of problems ranging from data vandalism to confidential information theft. Access to your web site might even be redirected to less desirable contents such as pornography or trojan applications.

Some experienced web developer might use features such as setting maximum length of data that can be entered in text input field, for example. However, this method could be easily defeated on the client side. Following up on the maximum text input field length example, this limit could painlessly be removed by tools such as the Web Developer extension on Mozilla Firefox.

Avoid Reliance on JavaScript for Security Checking

JavaScript is also commonly used for form input validation. To be honest, in many cases, it’s an excellent pre-server-side processing tool. Nevertheless, it’s not an iron-clad protection mechanism for web security purposes.

For one thing, JavaScript support can be disabled very easily in browsers that support it. If you choose to make JavaScript support compulsory, or more critically; essential, in order to access your web site, you risk alienating a significant proportion of potential users. Additionally, if it’s a public web application, it may no be properly indexed by search engines and other bots.

Therefore, even if JavaScript is used for form validation, you should program your form handlers to function properly and securely even if JavaScript is disabled.

Use Proper Authentication SQL Logic

The following programming logic is often used in web development (sample code in PHP):

$sql = "select * from usertable where username = '".$username."' AND password = '".$password."'";
$res = mysql_query($sql, $db);
if (mysql_num_rows($res) == 0) {
} else {

If you don’t see anything wrong with the sample code above, I pray that you haven’t created any publicly accessable web based application which uses similar user authentication mechanisms. Getting straight to the point, the fundamental error with the above coding logic is that it assumes if zero rows are returned it means that the authentication has failed.

That assumption on itself is not wrong per se, it’s the else handling which makes the logic flawed. It shows that the programmer assumes that the number of rows that can be returned by the code is either zero or one. Theoretically, if the database table is designed properly (ie. the username field is unique) those will be the only possibilities.

But what if the following data is entered:

Username: anything
Password: ' OR ''='

This would render the authentication SQL in the earlier example to become:

select * from usertable where username = 'anything' AND password = '' OR ''=''

When executed, it will return all records in the usertable table and thus causing the number of rows returned would be equal to the number of records in that table (obviously non-zero) because the bolded section renders the query to select all rows. Worse still, the authentication_passed() function would be executed, gaining the person entering the data access to areas which should only be accessed by authorised users.

SQL injection attacks as illustrated here can be avoided through the following measures:

  1. Proper form submitted data escaping
  2. Use a programming logic where authentication is true only when one row is returned
  3. Don’t continue processing input if quotes are used in forms that are meant to be used for user authentication purposes

Storing of Unhashed Password Data in Cookies

Although not directly used to access databases in web applications, cookies are often used as a method to store authentication-assisting data on the client side.

I’m not saying that cookies shouldn’t be used to store such information. On the contrary, I firmly believe that cookies are absolutely essential tools for modern web based systems. They’re quickly and easily accessable by the browser, relatively small in size, unobstrusive and universally adopted.

How some web sites store password data in cookies is why I feel that cookies deserve a special mention in this article. Many fail to take into consideration that cookie data are human readable. They are stored in plain text in ASCII files. Therefore, anyone who has access to cookie files can view its contents.

This makes storing unencrypted or unhashed password data in cookies to be a very bad idea. Cookies not only store what web programmers want to be stored there, it also stores the web site domain name along with it. This makes it very easy for malicious persons to steal usernames and passwords information and use them if they had access to cookie files. They can also try the username and password combinations on other web sites and multiply the damage if you happen to use the same combination on more important web sites (like your bank’s online services for example).

2 responses to “How To Secure Your Web Accessable Database”.

  1. » How To Secure Your Web Accessable Database Says:

    […] (more…)   […]

  2. Charles Says:

    That’s really wow I say because this would be a source of getting inspiration and that is all what is required to start the things, thank you.