Because this query is partially commented out, the application ignores the password. The code will falsely identify the user as whatever user is returned at the top of the list of all users. Thus, as Figure 1 shows, the application considers this attacker authenticated, even though the username and password are invalid. Of course, this type of attack can be more complex and cause more damage than the previous simple example string does. For example, you could enter the following statement:
sadf ' OR 1 = 1 ; DROP TABLE USERINJ —
which does a better job of demonstrating the potentially destructive power of the SQL injection attack. This code not only bypasses the logon statement but also drops a table—in this case, the user table. Other actions an intruder might take include creating a new user in the logon table, querying against other known tables, or using SQL management queries to locate and define other tables. With the right user permissions, an attacker could use SQL injection to access your entire system.
As a DBA, you have only limited power to defend against this kind of attack. SQL injection takes advantage of two vulnerable areas: the data-entry field where the attacker enters and executes the injection command and the database permissions that you set. By securing both of these areas, you can limit the attack's success. Secure only one of these areas, and you run the risk of an intruder accessing, misusing, or destroying your organization's private data. To ensure full protection, you need to add layers of defense that limit the input your application accepts and use proper database permissions. That way, even if one part of your defense fails, another layer will continue to protect your data.
Screening User Input
Let's begin by adding a security layer that prevents an unwanted user from using applications connected to your database to insert manipulative SQL commands. In the example SQL injection attack I created, the intruder's input included more characters (some of them special characters) than a typical username or password would have. Screening this kind of input at the source is probably the easiest way to defend against SQL injection attacks.
In Visual Studio .NET, every text field lets you specify a maximum length. To set a field's length, simply select one of the text boxes in the form and find the Properties window, which is typically in the lower right side of the screen. In the list of properties, find maxlength, and enter a value greater than 0 to limit the number of characters a user can input. Limiting the number of input characters is a simple but important step in screening user input.
Not every form contains values that you can limit to a specific length, but you can also control input by forbidding or limiting special characters. ASP.NET provides a control that lets you screen user input. From Visual Studio's toolbox, you can add a validation control for each of your input fields. .NET provides several different validation controls in the Visual Studio .NET toolbox. When you use a validation control, you can specify that a given field should be numeric, for example. Validation controls are available for identifying required fields, comparing fields, and setting numeric ranges. You can even create custom validation controls. Additionally, Visual Studio .NET provides a control called ValidationSummary that you can use as the error display across several validation controls. Validation controls are great because although they're available for execution on the client, the final screening of user input occurs on the server. Having the server run or rerun every validation control ensures that a savvy user can't bypass the screening by manipulating the data and injecting code in a string after it leaves the browser.
The RegularExpression validation control is a control that lets you specify that an input string's characters fit within the definition of a regular expression. The following is an example of a regular expression:
^[0-9a-zA-Z_]$
This expression specifies that an input string can contain only alphanumeric characters and the underscore character. In this article's examples, these limitations would screen out the special characters in the SQL injection string I used. With this definition, the application server would reject the attack string. You can create similar regular expressions by using the information about regular expression language elements that Microsoft provides at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpgenref/html/cpconcharacterclasses.asp or the syntax reference information on Jan Goyvaerts' site, Regular-Expressions.info, at http://www.regular-expressions.info/reference.html.
You don't have to limit your screening to the application's user interface. You can also include regular expressions in code. For example, the following Visual Basic .NET code creates a regular expression that checks for valid characters and for a maximum length of 10 characters:
Dim reg As Regex = New
Regex("^[A-Za-z0-9_]{10}$")
reg.IsMatch(TextBox1.Text)
The expression this code creates is one that you might use to validate usernames. Keep in mind that to add this code to this article's example, you need to include the full reference of System.Text.RegularExpressions unless you add the statement Imports System.Text.RegularExpressions to the top of the source file. .NET provides built-in support for regular expressions both at the control level and, more importantly, within your code. Even though you might not be able to eliminate special characters from every field, you can screen out especially suspicious characters—such as a double dash.
Prev. page
1
[2]
3
4
next page 
