I am a believer in using session variables for security. The mechanism that drives the system is the log in script. The log in script requests a username and password. When submitted it posts to a validate script. The validate script checks the username and password against a list of users in the database. If it finds a match, it sets a session variable. Then, from that point on, you check for the existence of that session variable at the top of every page. If you don't find it, you don't display the page.
Security using session variables like this is fairly secure. The session variable is held within the php or asp engine itself. You cannot access it outside of php or asp respectively. Basically, outside the programming language, it doesn't exist. That is why security using session variables is a viable concept.
The problem is the log in script. If someone can breach the system then your security is no good.
Log in validate scripts typically check users against a database table. Bad guys familiar with SQL know this. They can get in by appending something as simple as OR 1=1 onto the password. On the back end, when you create your SQL statement it reads something like this:
SELECT * FROM users WHERE username = 'john' AND password = '1234' OR 1 = 1 |
And they walk right in.
Once that session variable is set, checking it on every page does no good. The bad guy is free to go anywhere in your system or worse yet, free to put anything they want into your SQL update statements. For this reason, you need to pay attention to your log in script and put in provisions to keep this from happening.
Here are some steps to make your log in script more secure:
1. Validate using Read Only database privileges
When you validate a user (against a database) you don't need WRITE access. All you are doing is READING the data. You don't need privileges to set a session variable either. You want to make sure that you connect to your database (username and password in your connection string) that only allows READ access and DENIES all other access. If you connect to your database as Administrator, it isn't going to matter what measures you take. You will be vulnerable. Connect to your database with READ ONLY access.
2. Require minimum length passwords
If you let people select their passwords you're going to have weak security. People select password based on what's good for them. Generally they could care less about your system or its security. They figure it's YOUR responsibility to keep bad guys out. They routinely use passwords like 1234, *, password, test or whatever.
Software designed to force entry obviously has to try all combinations to get it. Like picking a lock, they go through every possible combination of username and password. If your passwords are six characters they can grind through all combinations fairly quickly. As you add length, the possible number of combinations goes up exponentially. It doesn't take much length to put access out of reach simple by presenting too many combinations.
3. Provide a method to log out
Make sure you include a log out function on your database. If you don't, anyone can jump on that box (when not in use) and they are accessed in. That session stays in force until the browser is closed. Add a button to log out where you kill the session and instruct people to use it.
4. Add provisions to keep people from posting in from outside your domain
One of the big problems is people posting into your validate script from THEIR box. For example, forget your log in screen. They just make their own. They know what you've named your variables. So they create a screen with your variables and POST it across the web to your validate script. Your validate script, not knowing any better, takes it in and processes it. What makes this so bad is that they commit this to a looping program and they can hammer away at will from their house.
Set a session variable on your log in page and test for it on your validate script. Then if it doesn't match or isn't there, reject the input.
5. Scrub the input
Scrubbing input from forms prior to interacting with a database is a nightmare for programmers. It's hard enough just getting the system to work, let alone attempting to anticipate everything a bad guy might throw at it. The word update for example can be potentially dangerous yet it occurs in data all the time. Scrubbing input is not as easy as you think.
On a log in screen however, it is essential. You only have two variables and you need to scrub them thoroughly. There are characters that you CANNOT allow people to use. Here is an example of the code required to scrub the username and password to get rid of the most obvious violating characters. This assumes that you are connecting with READ ONLY privileges
<%
username = Request.form("username")
username = replace(username, "'", "")
username = replace(username, ":", "")
username = replace(username, "=", "")
username = replace(username, "(", "")
username = replace(username, "-", "")
username = replace(username, " ", "")
username = replace(username, chr(34), "")
%>
|
This gets rid of the obvious characters like single quote, colon, equal sign (a sure killer), parenthesis, dash, space, and double quote. If you'd like to take it a step further you can use code like this:
<%
Dim regEx
Set regEx = New RegExp
regEx.Global = true
regEx.Pattern = "[^0-9a-zA-Z]"
username = regEx.Replace(request.form("UserName"), "")
%> |
Rather than trapping for offending characters, this code tells you what characters it will accept. The code as written will accept only numbers 0 through 9, and letters a through z, and A through Z. All other characters are eliminated.
A login screen and validate script that doesn't employ these measures is a sham. Anyone can walk right in. Take care to put your input into a variable and then scrub that variable before using it in your select statement. In addition make certain to connect to your database using READ ONLY privileges. That will eliminate someone throwing in database commands like UPDATE or CAST. |
