The SQL injection (SQLi) is one of the most common threats to contemporary computer security. It is also one of the most successful threats because it is easy to execute and moderately hard to detect and prevent, so the success rates are high and the damaged caused by the attack is severe. Furthermore, there are no tools that can accurately detect and stop specific SQLi attacks, so developers are required to analyze the source code and resort to code-based defense strategies if they want to prevent unauthorized access to data. In the worst case scenario, an attacker can take complete control over a database with poor security, leak out sensitive information, and sometimes take over the entire server hosting the database. Although the awareness about the SQLi threats is currently high, it is evident from the amount of research and case studies that the SQLi methods impose a high risk for web applications and beforehand preparations are the only reliable methods to prevent potential threats.
Several research papers are dedicated to analyzing methods to detect and prevent potential security threats in the SQL code. However, it is possible to notice that intrusion detection software (IDS) is aware of only existing security threats while neglecting potential and unknown weaknesses in the code. Furthermore, most IDS software is not capable of recognizing and stopping certain types of security threats caused by the SQLi methods. While traditional code assessment and protection methods offer some protection, it is the administrators’ responsibility to combine several approaches in restricting access to the database and controlling input validation. Relying on one approach leaves out too many options for the attackers to submit queries successfully and gain unauthorized access to information that eventually allows them to take complete control over the database if the attack is not stopped in time.
Background
According to the Imperva’s Hacker Intelligence Initiative report, SQLi has been responsible for 83 percent of the successful data breaches (Rachwald, 2011). TJMax, RockYou, and Heartland are examples of various breaches that have lost around 262 million data records. The most well-known contemporary example where SQLi damaged a large corporation and millions of users is the breach caused by the hacker group LulzSes. After hacking Sony with a simple SQLi vulnerability, LulzSec obtained access to more than 4.5 million customer records and leaked Sony’s source code that allowed them to reverse-engineer the network (Shan, 2011).
The SQLi is the fastest and most effective contemporary method for security breaching; observations conclude that it is possible to carry out an average of 71 SQLi attacks within one hour (Rachwald, 2011). According to the Open Web Application Security Project ([OWASP], 2010), the injection flaws, including SQL, OS, and LDAP injections, and cross site scripting (XSS) have been the most common security threats since 2007. SQLi and XSS attacks are similar because they exploit the regular input vectors, so they can often be used together, but the SQLi attacks are harder to detect than XSS attacks, so they are more prevalent and potentially cause more damage to hosts than XSS attacks.
Technical Aspects
Databases were designed to organize data in a structured manner because it allows easy information retrieval and cross-referencing, and that type of database is referred to as a relational database. The structured query language (SQL) is the most common method of managing those types of databases, and its major components include the data definition language (DDL), data manipulation language (DML), and the data control language (DCL). The DML commands are the most common targets of successful SQLi attacks, and the key vulnerability exploitation statements include the SELECT, UNION, AS, WHERE, LIKE, UPDATE, INSERT, DELETE, and the EXEC statements (Harper et al., 2011). Other characters used in SQLi attacks include the ‘, “, +, ||, *, %, ;, (), --, and # symbols (Harper et al., 2011).
The SQLi is a method that allows attackers to insert custom strings using the most vulnerable DML statements in the uniform resource locator (URL) that browsers usually use to access servers. The vulnerabilities of those strings allow the attackers to access and manipulate databases stored on the targeted server. While all attacks will rely on different syntaxes to achieve the same result, they all work on the principle of exploiting the SQL statements that were implemented in the database development, but the web application was not designed to perform requests that the attacker can manipulate through modifying the SQL statements.
However, because the attacker uses only standard queries listed in the trusted API to execute the attack, it is possible that the system administrator will completely overlook the attack. While the examples of SQLi attacks show that an attacker could gain remote control over a database to change or obtain sensitive data, it is possible that the SQLi attack goes completely undetected because there is no evidence of an attack when data is displayed without changes (Rao, Kumar, Reddy, and Sharma, 2012). Even the log file when data is retrieved without modification will probably remain unsuspicious because the executed query is unfiltered, so the administrators will not see a reason for concern.
Example Attack Scenarios and Outcome
A basic example of an attack that targets s and passwords would start by testing the responsiveness of the database located on the hosting server. In that example, the attacker would send two single quotes. If query is successful, but does not return data, it is possible to notice that the manipulation of the database can be achieved. For example, adding OR 1=1 between the quotes could obtain the information on all users. Whenever the database returns an error message to the attacker, it gives the attacker more details about the database structure and pointers for following string exploitations (Boyd and Keromytis, 2004). Further SQLi attacks could reveal the location of password strings within the database and allow the attacker to utilize the UNION command to select and obtain the passwords from all users in the database.
A general example of a string an attacker can use to obtain unauthorized access to data stored in the database is:
String query = "SELECT * FROM accounts WHEREcustID='" + request.getParameter("id") +"'";
If the attacker modifies the ‘id’ parameter to send ‘ or ‘1’=’1, the modified query will return all records from the database rather than focusing only on one record (OWASP, 2010). In the worst-case scenario, the attacker will obtain complete control over the database. Sometimes, the entire server hosting the database is at risk.
There is a wide variety of ways an attacker can choose from when performing SQLi attacks. The choice of the method will depend on the attacker’s aims, and they can be performed independently, together, or sequentially. For example, using an incorrect query intentionally could be the first step to obtain information about the name of the input fields through an error message (Tajpour, Masrom, Heydari, and Ibrahim, 2010). With that information, the attacker can develop a structured plan to carry out attacks, such as the union query or the piggy-backed query, and obtain the desired results.
Even when developers hide error messages to hinder the attackers’ reconnaissance, the attackers have the option to use the blind injection. Blind injections exploit the vulnerability by inputting a series of true or false questions. Even if the error messages are disabled, the attacker will gain the required information. However, it is possible to prevent blind injections by setting up input validation (Tajpour, Masrom, Heydari, and Ibrahim, 2010). Furthermore, in combination with limiting the allowed user input, input validation restricts the attacker’s options in harassing the information stored in the database (Rao, Kumar, Reddy, and Sharma, 2012). That example proves that it is not possible to limit the database defense to only a few methods, and the developers should combine various policies to restrict the access to the database.
Prevention
The four main types of SQLi attacks are SQL manipulation, code injection, function call injection, and buffer overflow attacks, but the SQL manipulation is the most common and severe type of attacks, so the contemporary research emphasizes the developers’ responsibility to sanitize every dynamic SQL statement that is potentially harmful. Patel, Mohammed, and Soni, (2011) reviewed the predefined choice input, bind variables mechanism, input validation, and parameterized statements and identified them as the most common and successful SQLi prevention methods. However, because the SQLi popularity is high, developers are advised not to restrict themselves to single solutions in preventing SQLi attacks, so different protection methods should be implemented simultaneously to prevent adverse outcomes.
Boyd and Keromytis (2004) argued that the SQLrand system was a reliable security measure because it randomized instances of the SQL statements and a de-randomizing proxy because, so it decreased the database vulnerability while adding minimal response time (6.5 ms) for query processing. From the security viewpoint, the standard keywords used in SQLi attacks used significance, and the attackers would be unable to access the database because the randomization of the query language would allow the detection and abortion of queries with injected code (Boyd and Keromytis, 2004).
Keizun, Guo, Jayaraman, and Ernst (2009) presented an automated tool that allowed developers to find security vulnerabilities in web-based applications by identifying both SQLi and XSS vulnerabilities in databases. According to Keizun, Guo, Jayaraman, and Ernst (2009), their technique is superior to defensive coding, static analysis, test generation, and dynamic monitoring because it works on unmodified codes, creates inputs that exposed unknown vulnerabilities, operates before the software is deployed, and focuses on internal analysis to identify vulnerable aspects of the code.
In contrast to standard black-box and white-box techniques that failed to identify unknown vulnerabilities, the analysis tool ARDILLA, tested by Keizun, Guo, Jayaraman, and Ernst (2009), discovered 68 vulnerabilites in five applications, and no false positives were reported in the further examination. Any failure to detect vulnerabilities was examined manually, and the researchers concluded that the ability of their software to find unknown vulnerabilities is admirable. However, the line coverage of their automated software in web-based applications is lower than 50 percent because it cannot work with more than two PHP codes simultaneously.
Research by Tajpour, Masrom, Heydari, and Ibrahim (2010) analyzed various tools, including SQLPrevent, WAVES, JDBC-Checker, CANDID, SQLGuard, AMNESIA, WebSSARI, SecuriFly, and SQL-IDS, that detect and prevent SQLi attacks. The comparison of those tools found that only 54 percent of them are capable of stopping some of the more common SQLi techniques, namely Tautologies, Illegal/Incorrect, Union, Alter Encoding, Piggy back, and Inference, while 46 percent of them can stop the attacks partially. The Stored Procedure attack was considered the most harmful because only 31 percent of the available tools could stop it completely while 23 percent of the available tools cannot stop it at all.
Rao, Kumar, Reddy, and Sharma (2012) analyzed six common security threats related to unauthorized data access, and the SQLi was considered the most common threat because a weak protection, such as using an unconstrained account, allows the attacker to take over the database with a greater range of queries and commands. Weak input validation, dynamic construction of statements without type-safe parameters, and over-privileged database logins were identified as the major vulnerabilities to SQLi attacks. Furthermore, it is not possible to protect the database effectively with existing products, so a code-based defense is suggested to developers to prevent SQLi attacks. Using double quotes instead of single quotes, avoiding dynamic SQL, validating all input, and using the principle of the least privilege were considered the basic countermeasures to contemporary SQLi threats (Rao, Kumar, Reddy, and Sharma, 2012).
Conclusion
Because injection attacks have been the leading threats for data security since 2007, it is evident that SQLi deserves more research and suggestions for counter-measures. While the literature review indicates that there are diverse options to protect the database from unauthorized access, it is evident that effective countermeasures are useful only before the attack takes place because it is difficult to detect an attack once it is initiated. Although security experts and researchers have identified the most common vulnerable statements used in SQLi attacks, the implication of security measures is never complete. It is evident that every method and vulnerability detection tool has both its merits and demerits, so the developers’ skills and experience in determining and implementing the defensive measures used to protect the data from SQLi attacks is the main determinant for a successful defense. Overall, combining input restriction policies, input validation, randomizing SQL statements, and scanning the source code frequently were identified as the most successful countermeasures to SQLi attacks.
References
Boyd, S. W., and Keromytis, A. D., 2004. SQLrand: preventing SQL injection attacks. Applied Cryptography and Network Security, 2089, pp. 292-302.
Harper et al., 2011. Gray hat hacking: the ethical hacker’s handbook. 3rd ed. New York, NY: McGraw-Hill.
Keizun, A., Guo, P. J., Jayaraman, K., and Ernst, M. D., 2009. Automatic creation of SQL injection and cross-site scripting attacks. In: IEEE (Institute of Electrical and Electronics
Engineers), IEEE 31st International Conference on Software Engineering. Vancouver, BC, Canada 16-24 May 2009. Los Alamitos, CA: IEEE Computer Society.
Patel, N., Mohammed, F., and Soni, S., 2011. SQL injection attacks: techniques and protection mechanisms. International Journal on Computer Science and Engineering, 3(1), pp. 199-203.
Rachwald, R., 2011. SQL injection: by the numbers. Imperva Data Security Blog, [online] 20 September. Available at: < http://blog.imperva.com/2011/09/sql-injection-by-the- numbers.html> [Accessed 23 April 2012].
Rao, T. K., Kumar, G. Y., Reddy, E. K., and Sharma, M., 2012. Major issues of web applications: a case study of SQL injections. Journal of Current Computer Science and
Technology, 2(1), pp. 16-20.
Shan, R., 2011. LulzSec hacker arrested, group leaks Sony database. The Epoch Times, [online]
2 July. Available at: < http://www.theepochtimes.com/n2/technology/lulzsec-member- arrested-group-leaks-sony-database-57296.html> [Accessed 23 April 2012].
Tajpour, A., Masrom, M., Heydari, M. Z., and Ibrahim, S., 2010. SQL injection detection and prevention tools assessment. In: IEEE (Institute of Electrical and Electronics Engineers),
3rd IEEE International Conference on Computer Science and Information Technology.
Chengdu, People’s Republic of China 9-11 July 2010. Los Alamitos, CA: IEEE Computer Society.
The Open Web Application Security Project, 2010. OWASP top 10 – 2010: the ten most critical web application security risks. [online] Available at:
