Tip

Defense tactics for SQL injection attacks

This tip reprinted courtesy of SearchSecurity.com.

The rate of application intrusions continues to rise, and many result from SQL injection attacks. These attacks are extremely dangerous in comparison to other types of Web-based attacks, because

    Requires Free Membership to View

the end result is data manipulation. However, while SQL injection holes can be easy to exploit, they can also be simple to defend against.

SQL injection attacks are a small subset of the overarching user-input validation attack class, which ranges from buffer overflows to character encoding to script insertion. SQL injection attacks are nothing more than maliciously crafted, valid SQL statements. One example of this is an authentication attack, which aims to bypass username and password logon:

SELECT Username FROM Users WHERE Username = '' OR ''='' AND Password = '' OR ''=''

The authentication attack allows an attacker to poke through a site with strong authentication but weak input validation and database column controls. Enterprises that lack these types of protections are common victims of SQL injection attacks, among myriad other Web-based threats that spawn from poor development practices.

A more efficient attack that produces a similar end result and lists objects within a protected sysobjects table resembles the following:

SELECT name FROM sysobjects WHERE xtype = 'U'

Organizations can defend against SQL injection attacks with vendor products and secure development. Host-based solutions, such as SANA Security's Primary Response or McAfee Entercept can monitor and block SQL injection attacks. These types of prevention systems have the ability to parse inbound kernel and application requests to verify that the requests are valid and not malicious. However, host-based prevention systems provide little value considering the amount of configuration that is required to protect against each server and application. The price tag is about $1,000 per server, and one server may take as much as three days to configure and appropriately test.

Another approach for remedying SQL-based vulnerabilities is to deploy a perimeter or proxy-based security product. This is a more effective approach because it can prevent all inbound attack patterns at the perimeter, versus waiting until the attack reaches the host system. Check Point's Software Technologies Application Intelligence, NFR's Security Sentivist and McAfee's IntruShield are three of the industry's leading perimeter security products that can be implemented to protect against SQL attacks. These solutions typically employ deep packet analysis with signature matching to determine if an inbound TCP/IP packet is an attack (think traditional Snort signatures for attack identification utilized in conjunction with proprietary blocking technology).

While perimeter-based solutions can provide fast relief, they can be costly and don't fix the underlying problem. A more efficient and effective solution is to eliminate SQL injection holes in-house. Your developers and administrators can fix the front-end Web code and appropriately configure the backend database for connected applications.

On the backend, Oracle tables in the default SYS database such as these should top the list for hardening: ALL_TABLES, TAB, USER_OBJECTS, USER_TABLES, USER_VIEWS, USER_TAB_COLUMNS, USER_CONSTRAINTS, USER_TRIGGERS, and USER_CATALOG.

In theory, however, the front-end Web code could be insecure even if the backend database is hardened.

The best practice is to strip special characters in front-end Web code or in custom rules within the database column- and row-level security controls. The parsing of characters from user input fields removes the required characters to successfully exploit a SQL injection hole. The usual suspects for potentially dangerous SQL injection characters include:

("*^';&><</) One of the easiest mechanisms for removing these characters from user-supplied strings is to create a removal or substitution regular expression, which will search, find and remove the desired dangerous characters. For instance, this Perl-compatible regular expression can remove the previously stated characters:

next if (/^"*^';&<>()/);

Another option to eliminate SQL injection attack strings is to remove the commonly exploited SQL commands from inputted strings to include "INSERT, DELETE, SELECT, UNION, WHERE, FROM, LIKE." The risk of doing this is disallowing a harmless string that has an embedded SQL command. For instance a username "LIKEMIKE" would not be permitted if you were stripping strings with the word LIKE embedded in them. This simple regular expression could identify a potentially dangerous string:

if (m//sFROM/s/USER_INPUT_STRING/g)

The easiest method for ensuring that malicious characters are removed from strings is to conduct a global search and replace via a regular expression to disallow all non-alphanumeric characters, as displayed in this expression:

s/&#91;^0-9a-zA-Z//g

Niche database security products can add additional security layers to Web infrastructure, and consulting firms can also assist organizations with the ongoing application security war. But the highest return on investment comes from Web developer and database administrator training, which can help eliminate SQL injection vulnerabilities.

About the author

James C. Foster is the Deputy Director for Global Security Solution Development for Computer Sciences Corporation, and a contributing editor for Information Security magazine.

This was first published in March 2005

There are Comments. Add yours.

 
TIP: Want to include a code block in your comment? Use <pre> or <code> tags around the desired text. Ex: <code>insert code</code>

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
Sort by: OldestNewest

Forgot Password?

No problem! Submit your e-mail address below. We'll send you an email containing your password.

Your password has been sent to:

Disclaimer: Our Tips Exchange is a forum for you to share technical advice and expertise with your peers and to learn from other enterprise IT professionals. TechTarget provides the infrastructure to facilitate this sharing of information. However, we cannot guarantee the accuracy or validity of the material submitted. You agree that your use of the Ask The Expert services and your reliance on any questions, answers, information or other materials received through this Web site is at your own risk.