Understanding SQL Injection

CosmicByte

3 min read

·

23 hours ago

--

Listen

Share

SQL injection (SQLi) is one of the oldest vulnerabilities, yet it still shows up in real world apps. After working through a hands-on SQLi tryhackme room, this is what stood out for me.

What SQL Injection actually is?

It happens when an application takes user input (like from a login form, search bar, or URL) and tacks it directly into a database command without proper validation or sanitization. Instead of treating the input as plain text, the database parses it as executable code.

How to detect?

Before exploiting anything, you confirm the vulnerability exists. The classic first move is injecting a single quote (') into any input field or URL parameter. If the input is unsanitized, the extra quote breaks the query syntax and the database throws an error, which the app often leaks back to you.

No error doesn’t mean “not vulnerable”, it might just mean errors are suppressed, which pushes you toward blind SQLi.

Authentication bypass:

Authentication bypass via SQL injection occurs when an attacker manipulates a login query to grant them access to an application without providing a valid username or password.

Payloads like:

' OR 1=1-- 
' OR '1'='1
admin'--

work because they turn the WHERE clause into something always true, or comment out the password check entirely.

Extracting data:

Once you’ve confirmed injection, the next skill is pulling data out of the database using UNION SELECT. This requires:

1. Finding the number of columns — usually with ORDER BY 1, ORDER BY 2, etc., until it errors out.
2. Matching column types — UNION requires the same number and compatible types of columns as the original query.
3. Replacing columns with useful data — once you know which column reflects on the page, you swap it for things like database(), table_name, column_name, or actual credentials.

A typical flow looks like:

' UNION SELECT null, table_name, null FROM information_schema.tables--

This is where information_schema becomes your best friend, it's the metadata database that lets you enumerate table and column names without any prior knowledge of the schema.

Blind SQLi:

Not every app shows you query results or errors. Blind SQLi relies on indirect signals:

• Boolean-based: You ask true/false questions (' AND 1=1-- vs ' AND 1=2-- ) and observe differences in the page response.
• Time-based: You inject something like ' OR SLEEP(5)-- and measure response delays to confirm execution, since there's no visible difference otherwise.

This is slower and more tedious but critical to understand, since real-world apps almost never show raw DB errors to users.

Takeway: why this still works?

The vulnerability exists anytime user input is trusted as code instead of being treated as data. Thats why it stills exists and dangerous too.

Impact of SQLi:

• Data Exposure: Stealing sensitive information like passwords, personal user data, or financial records.
• Data Tampering or Loss: Modifying database contents or dropping/deleting entire tables.
• Authentication Bypass: Logging into administrative accounts without valid credentials.
• Complete System Takeover: In severe cases, gaining administrative access to the underlying database server.

How to prevent it?

• Parameterized queries/prepared statements — the real fix, since input is never concatenated into the query string.
• ORMs (Object Relational Mapping)— most modern ORMs parameterize by default, but raw query methods inside them can still be vulnerable.
• Least privilege DB accounts — even if injection occurs, a restricted DB user limits the blast radius.
• Input validation — a secondary layer, not a replacement for parameterization.

Final thoughts:

Doing a basic SQLi room is a good reminder that this vulnerability class rewards understanding why a query breaks, not just knowing payloads. Once you understand how the underlying query is structured, you can adapt payloads to pretty much any context, like login forms, search bars, URL parameters, even HTTP headers in some cases.