I have been reading some articles on the methods used in SQL Injection to compromise the security of a database. At first I believed I was safe, since I do not allow the user to enter a paramter value (select boxes only)...Well, there is the login screen, but I am working on safeguarding the username and password fields now.

However, I realized that a hacker could just make their own .asp script with editable text fields of the same "name" attribute as my select boxes. Then call my database with their own doctored "parameters" (basically converting the parameters into SQL injection queries). Note that I am using stored, parametized procedures (queries predefined in my DB) for all my DB queries.

It occurred to me that I could try to implement some Lock() and Unlock() style functions to tie my pages together. So, in the first page call Lock() which generates a number on the server and sets an Application or Session variable. In the next page, the first thing I would do is try to Unlock() the page. So, the Unlock() function would try to validate a script as being my own by comparing it to a number or file, or successfully performing a server operation that only a native script could do.

I am new to ASP and could use some ideas on implementing such a mechanism in a *secure* manner. For example, I believe I read somewhere that Session variables are stored as hidden cookies or somesuch on the users machine, so thus could not be used to implement this idea.

Perhaps I don't need a lock variable of any kind, but just change Unlock() to be something more like ValidatePageSource() which performs a server operation that a foreign script would fail, perhaps a local disk operation? To implement this I would need to be able to force every page to verify that the calling page successfully called ValidatePageSource().

Anyone have some ideas on how to implement this? I am sorry if my idea is ridiculous or noobish :) If it is, just let me know...politely.

Select lists and text boxes are just different ways of getting values into a form, by the time it hits the server there is no difference.

This is not the issue. For them to be able to do that they need to be executing code on your server, and once they are executing code on your server they own the server, and you are in a world of pain.

A bigger issue is people writing their own HTML forms and posting them. If you do a view source of the form page, save the text, and edit it then you are set. There are tools out there to make this easy. I'll try to dig up some links on this from security focus. OK found it, check out the messages in this thread:
http://www.securityfocus.com/archive...0/2003-06-16/1

Also anyone can generate their own HTTP posts using perl. If you like I could post a script to do just that. It isn't more than 20 lines long.

This doesn't protect you any further. I have written a perl script that could still do this. Basically so long as the session is alive (and you can ensure that by making certain that the cookie is correctly set), then they can do whatever they want. You are approaching this from the wrong direction, by adding complication without adding much security.

Session variables are stored on the server. The way sessions work is that a random number is generated on the server. This random number is written as a cookie to the client computer. Each time a POST or GET is made to the server, the cookie is sent back to the server. From that the server can then say which session it is, and therefore what the session variables are. The session variables are never exposed to the client.

I suggest that you read:
http://www.nextgenss.com/papers/adva..._injection.pdf
This is the best paper I have read on the subject.

In summary, to prevent SQL injection you want to do two things:
1. Never use dynamic SQL (either in stored procedures or in ASP), use only parameterised stored procedures.
2. Use prepared statements, in other words for ASP use the ADO Command object to execute all your stores procedures.

There are other ways of avoiding trouble, but this is the safest.

You might also want to consider server side checking of values passed in. Checking normally takes place on two levels:
1. Checking that the value is a legal data type, ie you haven't got a string when you expected an integer, or the string is not longer than the datatype in the database allows.
2. Checking that the value fits your business logic, ie does this person have the rights to change/add this value.

regards
David Cameron

There is also an article that just appeared today on security focus that takes an extremely brief look at SQL injection among other things.
http://www.securityfocus.com/infocus/1709

regards
David Cameron