There are three things to remeber about web programming security that you have to bear in mind when designing your applications. These are, respectively, validation, validation and validation. The first thing a cracker will do to your site is to see where it breaks.

(note: Cracker is the correct use of the term here. Hackers build things, crackers break things

Quote:

Most real hackers think that crackers are lazy, irresponsible and not very bright and object that being able to break security no more makes you a hacker that being able to hotwire cars makes you an automotive engineer Eric Raymond

)

Common exploitative techniques

First Johnny Cracker will browse your site until he finds a script that accepts GET input in the format:

Code:

scriptname.ext?parameter=value

More experienced crackers will also be able to use the same sort of explotative techniques to attack scripts that accept POSTed variables, so don't assume that POSTing form data will deter a serious cracker (but it might exclude some of the more lame kiddies). For the examples in this tutorial I'm going to stick to basic GETs however.

Next our cracker will play with the URL to see what he can get to break. For example:

Code:

scriptname.ext?parameter=

If our script does not validate that the parameter has been passed then this will likley generate an error. If our code contains an SQL statement that looks like this:

then the cracker will get an error message containing the SQL statement and probably some infomation about the physical location of the script on the server. These are not good things to be giving out to Johnny Cracker.

TIP: In IIS and Apache it is possible to stop the server sending detailed error messages to the client (in IIS this is under application/debugging). Whenever you are not actively debugging your application you should ensure that this option is checked. Otherwise every error message is a bit more information for Johnny Cracker to work with.

Let's say our cracker is malicious - They now know that we have a table called pubs in our database. They can now rework the URL to include SQL stuffing like this:

Code:

scriptname.ext?parameter=1;delete * from pubs

Bye-bye pubs table. Our code above will assume that everything after the semi-colon is another SQL query and run it with the same permissions that were set up to run the first query. If those permissions were to the master database of an MSSQL database then the cracker now has access to all the stored procedures, including xp_cmdshell to run programs from the command line, xp_sendmail to mail himself the contents of your tables etc.

TIP:Never connect a web script to the master database of a MSSQL server. Never run your web page scripts from an administrative account.

Overcoming these techniques through validation

In both of these instances we could have stopped these attempts with proper validation. For example if we had nested our SQL statement in the following clause:

Code:

IF NOT (Len(request("parameter")>0 AND INSTR(LCASE(request("parameter")),"delete") =0) THEN
...Whatever...
END IF

then our cracker would not have been able to perform either of the above 'exploits'.

Now re-writting these validation sequences for each of your scripts is a real waste of time and can really get quite tedious. Me personally I prefer to throw each of my validation sequences into a class that I can re-use time and again.

NTSA's Validation script

Don't try to copy and paste this script (not least because it's taken from one of my ActiveX controls and probably won't run as is in ASP). I am including it in this tutorial only as an example of what YOUR validation class might include - mine is tied into a number of sub classes that I'm not including here (debugging classes, INI file class,etc), but you can get the gist of what I'm doing. This class encapsulates all my validation routines and on completion allows an array of reported errors to be passed back to the calling script for display to the user.

You would call the routines in this class like this:

Code:

Dim ers As Boolean
Dim Er As Variant

ers = False

Validate.ClearErrors
If Not Validate.isvalid("number", tInteger, "1") Then ers = True
If Not Validate.isvalid("password", tPassword, "123456") Then ers = True
If Not Validate.isvalid("Date", tDate, "28/3/75") Then ers = True
If Not Validate.isvalid("Email", tEmail, "si@ntsa.org.uk") Then ers = True
If Not Validate.isvalid("Required", tRequired, "sdgv") Then ers = True
If Not Validate.isvalid("NoSpaces", tNoSpaces, "12345") Then ers = True
If Not Validate.isvalid("Message", tNotHTML, "") Then ers = True
If Not Validate.isvalid("SQL Statement", tNotSQL, "select * from sysobjects") Then ers = True
If Not Validate.isvalid("Card Number", tLUHN, "4121111111119") Then ers = True

can I just say thank-you for the belly laugh! ;) (Trial and error - validation - get it? nevermind)

March 24th, 2003, 11:07 PM

unrealrsnd

really good actually

March 25th, 2003, 03:46 AM

linuxelite

Nice one ntsa. Just wanted to add, people need to be extremely careful when implementing "get" scripts, because, another way somebody can exploit the server, is to add their own page "...?http://blah.com", and load their won page that does whatever to the server that runs it. Perhaps checks it out for vulnerabilities, or gives you a list of hard drives, physical locations, specs, there are many scripts that do that.

March 25th, 2003, 05:19 AM

daxmax

Nice leg work ntsa.
There is a easy way to secure this on dbs like MS Access, on a physical level.
When I do standard SQL Selects ( 90% of the time) I open the db in read only.
When I actually update info in someway, that is when I open it for writing, the info passing through it is heavily analyzed.