SQL Injection: Beginner’s guide

I’ve been digging into SQL injection. It’s like finding out you can talk directly to a database with just a few tweaks to a URL or form input. Here are a few takeaways from what I’ve learned.

What’s SQL Injection?

SQL injection (SQLi) is when someone sneaks some malicious SQL code into an application’s input fields (like a login form) to mess with the database. If the application isn’t properly secured, the database just eats up that malicious code and does what it’s told, which can lead to all sorts of trouble like data theft, bypassing logins, or even deleting the whole database.

Use cases to understand SQLi better

Use-case 1: Bypassing a Login

Consider a situation where we got a simple login form that checks the username and password against a database. For that validation, the SQL query might look something like this:

SELECT * FROM users WHERE username = 'JB Singh' AND 
password = 'PassTheHash';

But if the application is not secured to SQL injection attacks, a threat actor could input the following to the username field:

' OR 1=1 --

And leave the password field blank:

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

where:

• The ‘OR 1=1’ part is always true.
• The ‘--‘ turns the rest of the SQL query into a comment, so it’s ignored.

Result:

The database thinks the condition is true for every row, and the attacker could be logged in as the first user in the database, which is often an admin.

Use-case 2: Dumping a Whole Database

Now consiser a situation where we have got a search box on a website that lets you search for products:

SELECT * FROM products WHERE name LIKE '%inputSearch%';

Now, if an attacker enters the following statement into the search box:

%' OR '1'='1

This will change the query to:

SELECT * FROM products WHERE name LIKE '%' OR '1'='1';

If this works, it reveals a serious problem. Knowing that it works with this app, the threat actor can see all the usernames and passwords inserting this:

'; SELECT * FROM users; --

Which would trick the app into running:

SELECT * FROM products WHERE name LIKE '';
SELECT * FROM users;
--';

Use-case 3: Deleting Data

If an admin panel, where you can delete users by their ID, is not immune to SQLi attacks, it can end disastrously. For this purpose, the SQL query might look like:

DELETE FROM users WHERE id = inputId;

An attacker can input:

1; DROP TABLE users; --

To change the query to:

DELETE FROM users WHERE id = 1;
DROP TABLE users; --;

This is catastrophic because the entire ‘users’ table would be deleted.

Basic techniques to discover SQLi vulnerabilities

1. Finding Vulnerable Entry Points

• Forms and Input Fields: Places where we can input data, like login forms, search boxes, or even URL parameters, can be vulnerabl to SQLi. We can test these fields by entering special characters (like single quotes ‘ or double dashes --) to see if they can break or manipulate the SQL query.
• Error Messages: We can craft an input in a specific way, the application might return a database error, revealing the underlying SQL query structure. This can give clues on how to exploit the system further.

2. Blind SQL Injection

Even if an application doesn’t display error messages, we can use blind SQL injection techniques to test the app. We can send crafted inputs and observe the application’s behavior (like different page content, or timing differences) to deduce whether the input affected the SQL query.

3. Pentesting and Code Review

If we are on a pentesting team, we might have direct access to the source code. In that case we can review the code for vulnerabilities, run penetration tests, and use automated tools to detect insecure queries.

Protect against SQLi

1. Use Prepared Statements

Using prepared statements will make sure the input is treated as data, not code.

2. Sanitize Input

Make sure to clean up user input, eg: removing or escaping special characters, that could mess with your SQL queries.

3. Limit Database Permissions

Don’t let your app’s database user have more permissions than necessary. Eg: if the app only needs to read data, it shouldn’t be allowed to delete tables or run ‘delete’ queries.

4. Error Handling

Don’t show detailed database errors to users. This info can help attackers craft their injections.

Conclusion

SQL injection is like tricking a website into running bad commands on its database. To keep things safe, always make sure to follow the measures listed above to not let anyone mess with you app database. Think of it like locking that door so nobody can sneak in and cause chaos.

If there’s a particular cybersecurity concept you’d like me to elaborate on, I’m ready to research and craft a detailed article to provide content tailored to your expectations. Please specify any specific areas of interest or topics you’d like me to explore further. Thank you for your collaboration and ongoing support.