AspAlliance.com LogoASPAlliance: Articles, reviews, and samples for .NET Developers
URL:
http://aspalliance.com/articleViewer.aspx?aId=422&pId=-1
Applied Login Security
page
by Tim Musschoot
Feedback
Average Rating: 
Views (Total / Last 10 Days): 34404/ 71

Introduction

With the uprise of serverside scripting technogies, the technical possibilities for web based applications became almost infinite.  More and more companies offer webbased services towards their customers.  Common used tasks in the scope of e-commerce as order tracking, stock view, online sales,… are now online available to the customer.  Discarding the investment that accompanies the creation of these applications, the advantages are numerous.  The biggest advantage is beyond any doubt, the ‘available on demand’ property of these applications.  The customer is no longer bound to opening hours of a helpdesk.

 

Because most of these webbased applications access a part of the internal company’s software infrastructure, security has become a very important issue.  Most sites provide a login to prevent unauthorized access to their application.  However, most login validation systems are very amateuristic and can be bypassed very easily.  If the online access portal gives direct access to the company’s administration software, the effects of a visit by a malicious user can be devastating.

 

The purpose of this article is to point out some of the most recurring methods of hacking websites, and how you can prevent them on your website.

Security Implementations

Everybody who has some experience in the software business, knows there is no absolute security.  The most secured computer is the one that is in a bunker, about 500m below earth surface, without any connection to the outside world.   However, this is not a practical solution for a computer that needs to run a webbased application.

 

So does this mean you cannot prevent unauthorized access?  Yes and no.  You cannot prevent it 100%, but you can really decourage people from trying.

 

Basic security : Login screen

 

In order to secure you webapplication, you will need to provide a way to control who has access to the site and who has not.  Simply telling people they are not allowed to do so, does not work !  Controlling the access is done by form of identification of the user.  Once you know who the user is, you can tell him if he has access or not.  In practice, this is done through a login.  The user needs a login name, that uniquely identifies the user, and a password only he can know, to prove his is really the user he claims he is.  If you apply a login, and a mechanism that makes this login the only access point to your application, you are half way.

 

User management

 

Once you have a login screen, and an application to secure, you will need a way to tell who has access or not.  In practice, the most common technique it to tell who has access.  Everyone else does not.  Unless you want to create a list containing everybody in the world who does not have access…  But feel free to try, you would surely have a scoop with your system !

There are a lot of ways to maintain a list with authorized users.  The most common techniques are user databases and Windows based authentication (using the authorized user list of a Windows host).  Because Windows based authentication depends on the Windows user administration, this option will not be discussed in this paper.

 

In the next paragraphs, managing users through a database will be reviewed.

 

Database based login mechanisms

 

A login system based on a user database is very easy to create.  You need a database containing a list of user names and passwords, and a login screen.  When the user entered his credentials, you have to validate if the user is in the database.  If he is, he can access the system, otherwise, he cannot.  Because of it’s simplicity, it is the most common used login system.

 

When you look around on the internet, you can find a lot of sites providing a login system.  Most sites will indeed manage their users through a database.  However, a lot of (I’d say 70%-80%) sites are not created by security professionals.  The people who create the login might well know how to create it, but they are unaware of the methods used to ‘hack’ these systems.  And as always, people that want to avoid certain restrictions are always one step ahead of people installing these restrictions.

 

Security flaws

The most commonly used attack mechanism on a databases based login system is the so called “SQL insertion attack”.  Many login validation functions will validate the access through a query similar to the one below:

 


"SELECT COUNT(login)

FROM usertable

WHERE login = ‘” & login & “’ AND password = ‘” & password & “’”


Hereby, the login and password are the values as they are retrieved from the user input textboxes.  If the combination login/password is found in the database, the result will not be 0, and the user has access, otherwise, he has not.

 

I bet 70%-80% of the webdevelopers simply base there login system on a similar query.  The message to these developers is: WATCH OUT.  Your site is as secure as a safe with an open door !    Why?  As long as the user is a computer illiterate, you are safe.  However, less and less people are.  When you are dealing with a user with advanced computer knowledge, or someone with malicious intentions (both are not to be tangled up!), your login system is just a little annoyance.

 

Suppose a user trying to get in has not valid login/password, but wants access to your system.  He could use all possible combinations of usernames and passwords until he gets lucky.  This is called a “stupid hacker”.  The number of possible combinations is way to large to achieve a result in an acceptable amount of time.  This is not a very practical solution.

Suppose the user is smart.  Instead of the trial-and-error method, he has a more advanced approach.  Suppose he inserts this data in the login screen:

 

-         Login : ‘ OR 1=1 OR login=’

-         Password : ‘ OR 1=1 OR password=’

 

This would result in this query:

 


SELECT COUNT(login)

FROM usertable

WHERE login = ‘’ OR 1=1 OR login = ‘’ AND

password = ‘’ OR 1=1 OR password = ‘’

 

 

The result of this query is… the number of users in the database.  If the check only refuses access if the result is 0 (is no user is found), the user has access to the system.

 

This is an example of an “SQL Injection attack”.  The number of websites vulnerable to this type of attack is innumerable.  In this example, I used a query that provides access to the website.  However, the malicious user might as well delete information from the database, stop your database server, retrieve information from the database (login names, passwords, credit card details, …), create a new account without knowledge of the administrator, …  Not scared yet?  If the online system accesses your business software/database directly, he can mess up every data in your database.  For small companies without a very decent backup and recovery system, this can cause bankruptcy.  For better equipped companies, it can also harm there business (data between the last backup and the current moment can be lost).  This is under the assumption the problem is discovered immediately.  If the damage is not too visible to the company, it might well take weeks or months before it is discovered.  Think about these consequences for your company in case this happens.

Protection

First Step

 

You can easily prevent this from happening.  The first guideline is: NEVER use user input directly in your database queries.  You can either use a wrapper function that will filter all harmful items from the user input, or you can use the features provided by the development platform (ex: the SqlParameter object as provided by the .NET framework).

How can you secure the user input?  As you can see from the example, I used the single quotes to insert additional SQL code in the query.  If you want to use a single quote in an SQL text value, you need to double the single quote.
Example:

 

 

O’Maley will be O’’Maley

INSERT INTO users (login, password) VALUES (‘O’’Maley’, ‘pass’)

 

So, first thing you need to do is replace all single quotes in the user input to 2x the single quote (do not confuse with the double quotes on your keyboard !).  When applied to the query above, the result will be:

 

 

SELECT COUNT(login) FROM usertable WHERE login = ‘’’ OR 1=1 OR login = ‘’’ AND password = ‘’’ OR 1=1 OR password = ‘‘

 

 

To enhance visibility, I marked the values as entered by the user, but where the single quotes are doubled, in red.  The user input will be considered as text, and will not influence the normal execution of the query.  You now enhanced the security of your website by around 95%.

 

Additional Enhancements

 

Besides the solution as mentioned in the previous paragraph, there are some additional steps that should be taken to further enhance the security of your website.

 

-         Limit the size of the user input.  There is no reason the user should be able to insert a 10 digit value in a database field of length 8.  Considering the large amount of buffer overflow based security risks in Windows based software, you can prevent this from happening at this point.

 

-         Newer trust clientside scripting.  You may validate user input by using clientside scripting, but you always have to implement a double check in the serverside script.  Nothing can prevent a user from saving a webpage, removing the clientside checks, and opening it again

 

-         Always run the SQL code in a database account with the least privileges.  There is no need for the account that is used to validate the login, to have write access to the database structure.  This prevents a malicious user from executing DROP TABLE… instructions.

 

-         Never expose a database error message to the user.  The message contains in many cases security sensitive information about the database structure, and may give the malicious user some extra ideas.  Encapsulate database error messages and prevent them by being displayed directly

 

-         Protect pattern matching statements.  If you need to use input with the LIKE clause, some characters take on a special meaning for pattern matching.  In order to prevent misuse, you need to escape these characters.  These are substitutions you’ll have to make on SQL Server:


- Replace a single quote by 2x single quote (‘ by ‘’)
- Replace [ by [[]
- Replace % by [%]
- Replace _ by [_]

Conclusion

Many people often blame so called hackers for intruding there systems.  However, in many cases (not to say most), they can only blame theirself for installing and implementing ‘immature’ security systems.  Most of the so blamed ‘hackers’ are curious kids that read some information about security (as it is widely available on the internet) and are messing around a little.  They rarely have malicious intentions.  If they get in, start by improving your security system instead of blaming them.  I’ve seen solutions provided by ‘professionals’ working for famous consultancy companies, that provide security systems even a 6 year old can bypass.  If you see the fees charged for these applications, you’d rather consider sueing the consultancy company then the intruder.  Maybe something to think about: if a real hacker would want to harm you, you’d never know it before the damage is irreversible !

Sources

[1]       Building Secure ASP.NET Applications, Microsoft Corporation, Patterns and Practices

[2]       Advanced SQL Injection In SQL Server Applications, Chris Anley

 

Copyright Ó 2004, Tim Musschoot, All Rights Reserved

Disclaimer: the author of this publication denies any responsibility for the behavior of the individuals who misuse the information provided by this article for illegal purposes.



©Copyright 1998-2024 ASPAlliance.com  |  Page Processed at 2024-03-29 6:05:23 AM  AspAlliance Recent Articles RSS Feed
About ASPAlliance | Newsgroups | Advertise | Authors | Email Lists | Feedback | Link To Us | Privacy | Search