SQL INJECTION ATTACK

SQL Injection Attack

Structured Query Language (SQL) injection is an attack technique that attempts to subvert the relationship between a webpage and its supporting database, typically in order to trick the database into executing malicious code. SQL injection usually involves a combination of over-elevated permissions, unsanitized/untyped user input, and/or true software (database) vulnerabilities.

Causes 
Simply stated, SQL injection vulnerabilities are caused by software applications that accept data from an untrusted source (internet users), fail to properly validate and sanitize the data, and subsequently use that data to dynamically construct an SQL query to the database backing that application. For example, imagine a simple application that takes inputs of a username and password. It may ultimately process this input in an SQL statement of the form 
string query = "SELECT * FROM users WHERE username = "'" + username + "' AND password = '" + password + "'"; 

Since this query is constructed by concatenating an input string directly from the user, the query behaves correctly only if password does not contain a single-quote character. If the user enters "joe" as the username and "example' OR 'a'='a as the password, the resulting query 
becomes 

SELECT * FROM users WHERE username = 'joe' AND password = 'example' OR 
'a'='a';

The "OR 'a'='a' clause always evaluates to true and the intended authentication check is bypassed as a result.

Detection

Detection of SQL injection attacks can be attempted with web server log auditing combined with network Intrusion Detection Systems (IDS). If you run a production web server, you must enable logging and periodically review these logs. Numerous software tools exist that allow for the rapid search of web server logs for specified keywords or regular expressions. Typical searches include commands and characters that should not normally be provided by a user, such as "EXEC", "POST", "UNION", "CAST", or a single quotation mark. While there are many potential searches, each will be useful only in the proper context since valid web forms that require the use of these commands have the potential to generate false positives.

Comprehensive detection of SQL injection attacks is very difficult. Even with logging enabled on all production webservers and Intrusion Detection Systems (IDS) on network chokepoints, the number of methods that attackers can use and combine to evade detection is daunting. For instance, attackers can manipulate the whitespace between commands, encode using decimal, HEX, BASE64, etc., and even inject characters that the webserver / database will ignore in order to evade detection by IDS or log-based analysis. 

Detection Heuristics 
Automatic detection of SQL injection vulnerabilities relies on heuristics of how the target application behaves (or rather misbehaves) in response to specially crafted queries. The techniques are sometimes categorized into the following types: 
Boolean-based blind SQL injection (sometimes referred to as inferential SQL 
injection): Multiple valid statements that evaluate to true and false are supplied in the affected parameter in the HTTP request. By comparing the response page between both conditions, the tool can infer whether or not the injection was successful. 

Time-based blind SQL injection (sometimes referred to as full blind SQL injection): Valid SQL statements are supplied in the affected parameter in the HTTP request that cause the database to pause for a specific period of time. By comparing the response times between normal requests and variously timed injected requests, a tool can determine whether execution of the SQL statement was successful.

Error-based SQL injection: Invalid SQL statements are supplied to the affected parameter in the HTTP request. The tool then monitors the HTTP responses for error messages that are known to have originated at the database server. 

Most tools employ a combination of these techniques and some variations in order to achieve better detection and exploitation success.

Mitigation/Best Practices 

The following mitigation strategies and best practices can be used to minimize the risks associated with this attack vector: As with any system or architecture changes, local administrators are best positioned to know which strategies are appropriate for their specific networks and systems. 

Network Level Recommendations 

• Deny access to the internet except through proxies for Store and Enterprise servers and workstations.
• Implement firewall rules to block or restrict internet and intranet access for database systems.
• Implement firewall rules to block known malicious IP addresses.
• Harden internal systems against the potential threat posed by a compromised system on the local network. (Do not rely on firewalls to prevent access to insecure systems; secure them.)

System / Application Level Recommendations 

Secure both the operating system and the application. 

• Consider using NIST or other industry standard security checklists to harden both the operating systems and the applications 
• Run only the minimum required applications and services on servers necessary to perform their intended function. In other words, disable all unnecessary applications and services. 
• Follow application vendor security guidelines.

Update and patch production servers regularly. 

• Include both operating system patches and application patches. 

Disable potentially harmful SQL stored procedure calls. 

• ‘xp_cmdshell’ on MSSQL has been frequently used by attackers. 

Deny extended URLs. 

• Excessively long URLs can be sent to Microsoft IIS servers, causing the server to fail to log the complete request. Unless specific applications require long URLs, set a limit of 2048 characters. Microsoft IIS will process requests over 4096 bytes long, but will not place the contents of the request in the log files. This has become an effective way to evade detection while performing attacks. 

Sanitize/validate input. 

• Ensure data is properly typed. 
• Ensure data does not contain escaped code. 
• Consider using type-safe stored procedures/prepared statements. 

Ensure error messages are generic and do not expose too much information. 

• Keep error messages short and usable. 
• Do not disclose internal database structure, table names, or account names. 

Use principles of least privilege.

• Install and run authorized Microsoft SQL Server and IIS services under a non-privileged account.
• Apply the principle of 'least privilege' on all SQL machine accounts.
• Remove guest accounts unless operationally necessary.
• Use an application account for database access.

Enforce best practice password and account policies. 

• Require the use of a password on Microsoft SQL Server administrator, user, and machine accounts. 
• Change default/built-in account passwords.
• Change application account passwords regularly.
• Use strong passwords. 
• Lock out accounts after several unsuccessful logon attempts.

Document all database accounts, stored procedures, and prepared statements along with their uses.

• Delete/disable unnecessary accounts (including default accounts).
• Delete/disable unnecessary stored procedures/prepared statements.

Perform regular audits and penetration testing. 

• Audit transaction logs for suspicious activity. 
• Audit group and role memberships to ensure enforcement of least access principles. 
• Audit stored procedures on a regular basis and remove unnecessary ones. 
• If you use ASP, consider using Microsoft’s code analyzer. 
• Consider using HP’s scrawlr utility to help identify problems. 
• Conduct penetration tests against applications, servers, and perimeter security