SQL Injection Flaws

Fend off the next SQL Injection attack with a properly secured database
Version X X, 2005
By Ronald Anthony Lewis
Takeaway
As long as Web applications are used to provide access to data, SQL Injection will continue to be a threat. This threat can be greatly reduced by scrubbing the input, limiting the use of dynamic SQL, and by properly configuring permissions on database servers.
Table of Contents
SQL INJECTION .......................................................................................................................................................................2 THE ATTACK .............................................................................................................................................................................2 Figure A ..............................................................................................................................................................................3 Figure B ..............................................................................................................................................................................4 DEFENSES ...............................................................................................................................................................................4 ADDITIONAL RESOURCES ..................................................................................................................................................6 Version history ...................................................................................................................................................................6 Tell us what you think .......................................................................................................................................................6
Page 1 Copyright 2005 CNET Networks, Inc. All rights reserved. For more downloads and a free TechRepublic membership, please visit http://techrepublic.com.com/2001-6240-0.html
SQL Injection
Injection flaws continue to abound in the wild; in fact, this is listed as number six on Open Web Application Security Project's (OWASP) top ten list of exploited vulnerabilities. Although OWASP considers SQL Injection as a part of the injection flaw genus, because of the gravity of successful attacks, the probability of exposure, and the unusually high success rate for attackersSQL Injection should be addressed as a single exposure item. SQL Injection, by definition, occurs when a user crafts a SQL statement and embeds it into a responsesuch as an input field on an authentication screen. SQL Injection is typically used to accomplish one of four objectives: bypass authentication, glean information, inject new or alter existing data, perform a denial of service attack, or gain access to an operating system. Although the SQL Spida worm, which wreaked havoc on Microsoft SQL Servers worldwide in June 2003, is not a true SQL Injection attack, it's a good example of what can be accomplished with unauthorized SQL access. Spida targeted sa accounts with weak or null passwords, and used xp_cmdshell commands to shell out to the OS and execute it's payloadadding the guest user account as a domain administrator, and replicating itself. The SANS Internet Storm Center lists port 1433 as one of the most frequently scanned ports. This fact should raise Web developer's level of paranoia.
Protect your Web site from cross-site scripting attacks
How to obtain and install the WebGoat security application was described in this previously published download. Assuming that you've downloaded and installed it, start the WebGoat application using the appropriate WebGoat startup script,and pull up http://localhost/WebGoat/attack?Screen=4. Incidentally, it's a good idea to configure your firewall to only allow inbound Web requests (TCP port 80 inbound) for "27.0.0.1"or "localhost" while running WebGoat.
The attack
The first step in performing SQL Injection against any Web app is to look for a place to inject a SQL statement. In the case of WebGoat, our only option is fairly obvious. And the lesson creator gave a major hint on the page including the SQL statement below the variable. A quick look at the source for this page shows that the "account number" variable doesn't have a maximum length. Not only is the susceptible to SQL Injectionwe can most likely embed multiple statements. Perhaps we should test this page for buffer overflow susceptibilitybut that's another lesson. The second step is identifying the type of SQL syntax the application is expecting. In this case, I already know that WebGoat is using a Microsoft Access runtime included with the application because I have the source code. However, let's put in a semblance of a SQL command and see if we can generate an error. I entered the incomplete SQL statement "101 and " and the system returned an error. (See Figure A).
Figure A
The error tells me that I'm using an Access ODBC connector and I'll use this to identify the constraints (e.g., what I can do) and what SQL syntax is expected. Microsoft Access provides a rich set of VBScripting capability, and access to the windows scripting host via the DoCMD objectso the sky's pretty much the limit with this application. The third step is crafting the SQL statement based on initial intent: bypass authentication, glean information, inject new or alter existing data, perform a denial of service attack, or gain access to an operating system. The goal of this lesson is to the get application to display all user data. To do this, we can simply append an "or condition" that always evaluates to "true". This will give us an unfiltered data set. Because we're using MSAccess SQL syntax (actually ANSI SQL 92) enter "101 or 1=1" for the account number and press the "Go!". The system display all user account information stored in the user_data table. Let's take a moment to evaluate why this works. Click the "show java" button on the application and look at line 60. Notice that the developer of this lesson simply concatenated the account number to the end of the query. In line 66, the "unvalidated" query is executed. The lack of input validation and the use of dynamically built SQL leave this application susceptible to myriad injection attacks. The WebGoat student is given credit for completing this lesson if he can execute a query that returns more than one row. However, given the lack of validation on input, and how the dynamic query is being executedcould we craft a SQL statement that would update all records to assign all credit cards to one user? The answer is, "yes". We could embed a condition that upon success would respond true, for example (again, not a complete examplefor obvious reasons):
where userid=101 and 'update user_data, set first_name='joe', set last_name='snow' for all'=true. A properly constructed SQL statement would only yield a single rowthereby not setting the success flag, and yet successfully altering the integrity of the entire user_data table.
Figure B
Defenses
Methods for defending against SQL Injection: 1. Avoid the use of dynamically built and executed SQL statements. 2. Validate and Scrub Input 3. Limit the database's access to the Operating System Had this been a real application, I would have expected the developer to scrub the input and pass it into a stored procedure on the back end. There are so many interesting ways to exploit the SQL Injection lessonfor example (docmd.openfile())that could potentially give a malicious access to the hard drive, the supporting network, and access to servers with trusted relationships with this server. Also on the back end, I would have expected the developer to strip out characters with special meaningfor example, strip out single quotes and replace them with double quotesif quotes were reasonable input. Also, if the input contained embedded strings with special meaning (e.g, keywords like "and" or "or") the developer should have captured the user's IP address and written it to an audit log, as well as notifying the system administrator that an injection attack was attempted.
The last method for protecting against SQL Injection is ensuring that the database server is properly installed and configured. The Spida worm gives a good example of what can happen when a server isn't properly protected exploiting xp_cmdshell, in most cases, gave Spida either administrator or local system access to the OS. Properly configured serversones that ran with limited rights to the OSwere not as adversely impacted by Spida. The same holds true for SQL Injection attack. If a malicious user were able to successfully exploit an OS callthe database engine shouldn't have sufficient rights to execute the call. As long as Web applications are used to provide access to data, SQL Injection will continue to be a threat. This threat can be greatly reduced by scrubbing the input, limiting the use of dynamic SQL, and by properly configuring permissions on database servers.
Additional resources
Sign up for our Downloads Weekly Update, delivered on Monday afternoons. Check out all of TechRepublic's newsletter offerings. Protect your Web site from cross-site scripting attacks (Download) Secure SQL Server: Encryption and SQL injection attacks (Article) Manipulating Microsoft SQL Server Using SQL Injection (White paper)
Version history
Version: 1.0 Published: June 27, 2005
Tell us what you think

TechRepublic downloads are designed to help you get your job done as painlessly and effectively as possible. Because we're continually looking for ways to improve the usefulness of these tools, we need your feedback. Please take a minute to drop us a line and tell us how well this download worked for you and offer your suggestions for improvement. Thanks! The TechRepublic Downloads Team

SQL Injection Flaws

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

SQL Injection Flaws

Uploaded by

Copyright:

Available Formats

Fend off the next SQL Injection attack with a properly secured database

By Ronald Anthony Lewis

Tell us what you think

You might also like