Validate Input Thoroughly
One of the most compelling reasons for using the principle of least privilege is that your application might someday have to do things it was never designed to do. For example, consider a typical search page in which a user types a book title as a search criterion. You might be inviting trouble if your data-access code looks something like this:
<%
Set Conn =
Server.CreateObject("ADODB.Connection")
Conn.open application("connection_string")
Set RS = Conn.Execute("SELECT author, notes from titles where title like
'" & request.form("title") & "'" )
%>
This access method is weak for reasons that I cover in forthcoming sections, but for now, let's consider the danger. A malicious user visiting the site might test your input-validation code by inputting a single quote (') into an input field. If the input validation is weak (and the error handling is poor), the attacker might get an error message like the one that Figure 1 shows. The message
Unclosed quotation mark before the character string ''.
tells an attacker that it's possible to input into the SQL command data that invalidates the SQL statement and that outsiders shouldn't be able to inject. A common term for this kind of attack is SQL injection, and the effects are dire. When attackers see the screen that Figure 2 shows, they can smell blood. They know that somewhere, someone isn't validating or filtering input. Here, an attacker found the hole that lets outsiders inject code and now has enumerated the SQL Server and OS version information.
Consider the earlier search-form example, but instead of a book title, type the following:
' UNION SELECT loginame, creditcardno FROM accounts--
With this simulated attack, a malicious user can subvert your search form to gain access to your users' accounts and credit card data. When someone inputs this code in your form, the single quote closes the username string, and the new SQL code is injected into the stream. The double dashes at the end of the injection code comment out any following SQL, so the last quote in the Active Server Pages (ASP) code doesn't cause an error message. Keep in mind that an attacker could inject even more dangerous SQL commands, such as DROP TABLE or the master..xp_cmdshell extended stored procedure, which gives access to the OS if the application is running with SQL Server administrative privileges. Take SQL injection attacks seriously—they're deadly and represent a target-rich environment for intruders.
So, can you do anything to stop such attacks? Of course you can. One simple thing you can do is enforce strong data typing. For example, if the application asks the user to enter a number, you can validate that a number was entered. For alphanumeric data entry, one obvious answer is to replace any single quotes in user input by using the replace command as follows in your application code:
replace(request.form("title"),','')
By replacing one single quote with two single quotes, you can still let users query for single quotes in the data.
In addition to the replace command, you can use the regular expression (regex) object to filter out unwanted data. The following regular expression filters out any character that isn't a-z, A-Z, or 0-9:
Set myregex = new regexp
myregex.global = True
myregex.pattern = "\W+"
cleaninput=myregex.replace
(You can find more information about regular expressions and scripting engine requirements for their use at http://msdn.microsoft.com/scripting.) Rather than simply filtering out the invalid character, a more common implementation is to compare the unfiltered input with the filtered input. If they're different, you can simply short-circuit the process and alert the user that the input characters are invalid. No matter which method you choose, consider all the ways unwanted data could get into your database.
Prev. page
1
[2]
3
4
next page 
