SQL Injection. Elucidation & Negation.

Even though this vulnerability is known for over 20 years, injections still rank number 3 in the OWASP's Top 10 for web vulnerabilities. Let's just dive in!

You might not know but Target, Yahoo, Zappos, Equifax, Epic Games, TalkTalk, LinkedIn, and Sony Pictures—these companies were all hacked by cybercriminals using SQL injections. Moreover, Malwarebytes Labs ranked SQLI as number three in the The Top 5 Dumbest Cyber Threats that Work Anyway, citing the fact that SQLI is a known, predictable attack with easily implemented countermeasures.

So when was this first reported? What’s the timeline?

The SQL injection exploit was first documented in 1998 by cybersecurity researcher and hacker Jeff Forristal, also known as Rain Forrest Puppy, discovered it and wrote about it in Phrack 54. Since 1999, the Common Vulnerabilities and Exposures dictionary has existed to keep track of and alert consumers and developers alike of known software vulnerabilities. Since 2003, SQL injections have remained in the top 10 list of CVE vulnerabilities; 3,260 vulnerabilities between 2003 and 2011. In 2012, a representative of Barclaycard claimed that 97% of data breaches are a result of SQL injections. In late 2011 and through early 2012, i.e. in only one month, over one million web pages were affected by the Lilupophilupop SQL injection attack. The year of 2008 saw an incredible economic disruption as a result of SQL injections. In 2009, Heartland Payment Systems was breached using an SQL injection. Even the official United Nations website in 2010 fell victim to an SQL injection attack. Then there was Sony Pictures in 2011. There was also a major breach at Yahoo! in 2012 and it was SQL injection that caused it.

Is it still being reported? How relevant is this?

According to OWASP, In 2024, SQL injections are still a thing, as they are one of the most exploited security vulnerabilities. Despite the huge influx of commercial and open-source solutions in the market today, all claiming to alleviate SQL injections, they are still number 3 on the OWASP Top 10 ranking.

According to Edgescan’s 2024 Vulnerability Statistics Report, SQL Injection still remains the foremost critical vulnerability in web applications, accounting for 19.47% of vulnerabilities detected and requiring 15 days to remedy.

So what’s SQLI?

A SQL injection attack consists of insertion or “injection” of a SQL query via the input data from the client to the application. A successful SQL injection exploit can read sensitive data from the database, modify database data (Insert/Update/Delete), execute administration operations on the database (such as shutdown the DBMS), recover the content of a given file present on the DBMS file system and in some cases issue commands to the operating system.
-OWASP

Still not getting it? I gotcha!

When a website uses a database to store information, it often uses a language called SQL to talk to that database. SQL injection is like a hacker sneaking in their own SQL commands into places where the website expects regular data. If the website isn't careful and just blindly trusts whatever it receives, the hacker's commands can trick the database into doing things it shouldn't, like giving up secret data or even deleting stuff. It's like slipping in your own instructions to control the database behind the scenes.

Let’s just get ourselves a bit more technical. Shall we?

SQL injection attacks come in different forms depending on how the attacker manipulates the input to the website. Let’s jump into a classic case:

The website takes the username and password input from the user and checks them against a database to see if they match. Suppose the website uses the following SQL query to validate the login credentials:

SELECT * FROM users WHERE username = 'input_username' AND password = 'input_password';

If a user enters their username as ‘john’ and their password as ‘password123’, the query would look like this:

SELECT * FROM users WHERE username = 'john' AND password = 'password123';

Now, let's see how an attacker can exploit this with SQL injection. If the attacker enters the following into the username field:

' OR '1'='1

And leaves the password field blank, the resulting SQL query would be:

SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '';

In this case, the condition '1'='1' always evaluates to true, so the query effectively becomes:

SELECT * FROM users;

Tada😆! This query retrieves all the rows from the users table, effectively bypassing the login process. The attacker can now potentially access sensitive information or perform unauthorized actions on the website.

Some other types of SQL Injection are:

2. Blind SQL Injection: Here, the attacker doesn't get direct feedback from the website about the success of their attack. Instead, they have to infer the results indirectly by analyzing the behavior of the website.

3. Error-Based SQL Injection: This occurs when the attacker exploits error messages generated by the database to gather information about its structure or the data it holds.

4. Union-Based SQL Injection: The attacker uses the UNION SQL operator to combine results from different queries, enabling them to retrieve data they're not supposed to access.

5. Time-Based SQL Injection: This technique involves injecting SQL queries that cause the website to delay its response. By measuring the time it takes for the website to respond, the attacker can infer information about the database.

6. Second-Order SQL Injection: In this scenario, the initial injection doesn't directly exploit the vulnerability, but rather sets up conditions for a subsequent injection to be more effective.

So, How can we prevent this🤔?

• Use of Prepared Statements (with Parameterized Queries)

• Use of Properly Constructed Stored Procedures

• Allow-list Input Validation

• Escaping All User Supplied Input

• Least Privilege

• Allow-list Input Validation

If you want to get deep inside the rabbit hole to get into the crux of these preventive methods, feel free to go through the readily available free cheat sheet provided by OWASP.

Thanks for your time in going along this article😊! Hope that this article may come to you in handy when the time comes.

References:

• https://www.w3schools.com/sql/sql_injection.asp

• Just how bad is it if your site is vulnerable to an SQL Injection? Dr Mike Pound shows us how they work.

• https://www.invicti.com/blog/web-security/sql-injection-vulnerability-history/

• https://www.darkreading.com/cyberattacks-data-breaches

• https://www.malwarebytes.com/blog/news/2017/04/the-top-5-dumbest-cyber-threats-that-work-anyway

• https://owasp.org/