Article Preview
TopIntroduction
SQL injection has been a long-standing challenge in database security. As of this past year, injection attacks are still the number one web application security risk (OWASP, 2017). The community backing the OWASP Top 10 Most Critical Web Application Security Risks gather data from over 100,000 real-world applications and APIs. These applications stem from over 40 organizations that specialize in web application security. This is just a small percentage of the web applications that exist in the cyber realm currently, but at least this will provide a solid statistical foundation as to why injection attacks are still rated number one.
An injection attack can allow an attacker to gain complete access to a database which oftentimes contains sensitive information, such as social security numbers and bank credentials. This results in a loss of confidential information which places consumers at a huge risk. There are many kinds of injection attacks (Halfond, Viegas, & Orso, 2006), but the attacks are split into three general categories: first order attacks, second order attacks, and lateral injection.
First Order Attacks
Taken directly from Oracle’s website, the description of a first order attack is where “the attacker can simply enter a malicious string and cause the modified code to be executed immediately (Oracle, 2018).” This vulnerability occurs due to a multitude of reasons such as incorrectly filtered escape characters or incorrect type handling. The most common example of this is appending the string ‘OR ‘1’ = ‘1’ to a query. This alters the logic of the query and will result in the query always returning as true due to the fact that 1 will always equal to 1 (Clarke-Salt, 2009). The ability to enter in a string like the one above is a threat because it gives the attacker the ability to get information from queries they would otherwise not have access to, due to the database not preventing the user from entering any incorrect input.
Second Order Attacks
A second order attack is where an attacker will seed a malicious input into a system or database to indirectly trigger a SQL injection attack (Halfond, Viegas, & Orso, 2006). The attack is delayed until a secondary query is executed, which differentiates it from the way a first order attack is executed.
Following Anley’s (2002) example, a potential attack scenario for second order SQL injection would begin with an existing query, such as one that allows a user to update their password:
UPDATE user SET password = ‘new_password’ WHERE username = ‘username’ AND password = ‘old_password’;
The attacker would first create a dummy user called “admin’-” and then try to update the password of the newly created user. When they do so, the query ran is as follows:
UPDATE user SET password = ‘new_password’ WHERE username = ‘admin’--’ AND password = ‘old_password’;
As a result, everything after the -- in the query is ignored and the attacker can update the admin password without even knowing what the previous one was.
These attacks are dangerous because they are harder to detect due to the attack vector being an existing query such as resetting a users’ password, as seen in the example above. These are also more persistent than first order attacks because they are not executed immediately. Moreover, they are more difficult to detect since the malicious code can be appended into a non-malicious statement, therefore masking the attack.
Lateral Injection
Lateral injection focuses on PL/SQL, which is Oracle’s procedural language extension to SQL. A lateral injection attack works on PL/SQL procedures that do not take user input. These procedures take no parameters and are not audited. However, there are variables in these procedures that can be taken advantage of. For instance, there is a built in function called SYSDATE() that has a variable V_DATE which typically takes a numerical input. Nonetheless, an attacker can trick the PL/SQL compiler to accept an arbitrary SQL command as a numerical input even though it is not. This can be achieved by using the ALTER SESSION privilege to laterally influence the SYSDATE function and exploit the procedure that does not take direct user input (Litchfield, 2008). The major concerns with this form of an attack is the fact that these procedures are not audited or monitored in any way, so an attacker can perform this type of injection unnoticed.