Mastering SQL Injection: Lessons from Solving 18 PortSwigger Web Security Academy Labs

This article is part of my Web Security Learning Series, where I document concepts and lessons learned while completing the PortSwigger Web Security Academy.

📂 Complete Technical Documentation

The complete lab-by-lab documentation, payload analysis, and walkthroughs are available on my GitHub repository.

GitHub Repository: 👉 https://github.com/22-shahidd/Web-Security-Labs/tree/main/Portswigger/SQL-Injection

Introduction

SQL Injection is one of the oldest web vulnerabilities, yet it continues to appear in modern applications because it targets a fundamental mistake: allowing untrusted user input to become part of an SQL query.

When I first started learning SQL Injection, I assumed it was simply about remembering a few payloads like ' OR 1=1--.

After completing all 18 SQL Injection labs in the PortSwigger Web Security Academy, I realized how wrong that assumption was.

SQL Injection is much more than authentication bypass.

It involves understanding:

Database engines
SQL query structure
Database enumeration
Blind inference techniques
Time-based attacks
Out-of-Band (OAST) exploitation
Defensive programming

This article summarizes the biggest lessons I learned throughout that journey.

What is SQL Injection?

SQL Injection (SQLi) occurs when an application incorporates user-controlled input directly into an SQL query without proper validation or parameterized statements.

Instead of being treated as data, the input becomes executable SQL.

Depending on the vulnerability, an attacker may be able to:

Read confidential data
Bypass authentication
Enumerate database structures
Retrieve passwords
Modify or delete records
Execute database-specific functions
Exfiltrate sensitive information

Although SQL Injection has existed for decades, it remains one of the most impactful web application vulnerabilities because insecure query construction is still common.

My Learning Journey

The PortSwigger SQL Injection learning path contains 18 progressively challenging labs.

Rather than jumping directly into advanced exploitation, the labs build a strong foundation before introducing increasingly realistic attack techniques.

The journey looked something like this:

Basic SQL Injection
Authentication Bypass
Database Fingerprinting
Database Enumeration
UNION-based SQL Injection
Blind SQL Injection
Error-based SQL Injection
Time-based SQL Injection
Out-of-Band (OAST) SQL Injection
WAF Filter Bypass

By the end of the module, I wasn't simply executing payloads — I was understanding why they worked.

1. Basic SQL Injection

The first labs introduced the core concept of manipulating SQL query logic.

Something that looked harmless, such as a product filter or login form, became vulnerable because user input was directly inserted into an SQL statement.

These beginner labs taught me an important lesson:

Every advanced SQL Injection attack begins with understanding how the original SQL query is constructed.

2. Database Fingerprinting

One of the biggest surprises was discovering how much payloads depend on the underlying database.

Oracle…

MySQL…

Microsoft SQL Server…

PostgreSQL…

Each database behaves differently.

Oracle uses objects such as:

dual
v$version

Whereas MySQL and Microsoft SQL Server expose information through:

@@version

Before attempting exploitation, identifying the database engine becomes an essential reconnaissance step.

3. Database Enumeration

Once the database type is known, the next challenge is understanding its structure.

This means identifying:

Tables
Columns
Relationships

Instead of guessing where credentials are stored, attackers systematically enumerate the database until they locate useful information.

I found this section particularly interesting because it showed that SQL Injection is a structured process rather than random experimentation.

4. UNION-Based SQL Injection

The UNION-based labs were where everything started to connect.

Before retrieving data, I first had to determine:

How many columns the query returned
Which columns accepted text values
How to combine multiple values into one output

Only after understanding the query structure could I successfully retrieve usernames and passwords.

This reinforced a valuable lesson:

Understanding the query is more important than memorizing payloads.

Blind SQL Injection completely changed how I thought about exploitation.

The application displayed:

No SQL errors
No query results

Instead, I had to communicate with the database using only TRUE/FALSE conditions.

Simple observations such as:

"Welcome back"
Slight response differences

became enough to reconstruct an administrator password one character at a time.

This was one of the most rewarding sections because it demonstrated how much information applications can unintentionally leak.

6. Time-Based SQL Injection

Some applications reveal absolutely nothing.

No output.

No errors.

No visible changes.

In these situations, response time becomes the communication channel.

By intentionally delaying database execution only when specific conditions evaluated to TRUE, I could gradually recover sensitive information.

It was fascinating to see how something as simple as a five-second delay could become a powerful data extraction technique.

7. Out-of-Band (OAST) SQL Injection

The Out-of-Band SQL Injection labs were probably my favorite.

Instead of relying on application responses, the database itself communicated with Burp Collaborator.

First, I confirmed that my payload executed.

Then, I used the same technique to exfiltrate the administrator password through a DNS request.

This demonstrated that attackers don't always need responses from the application itself.

Sometimes, the database becomes the communication channel.

8. Bypassing Security Filters

The final lab demonstrated that Web Application Firewalls (WAFs) are not a complete defense.

A normal SQL Injection payload was blocked.

However, encoding the payload as XML entities allowed it to bypass the filter before being decoded and executed by the server.

The lesson was simple:

Security products are valuable, but they cannot replace secure coding practices.

Biggest Lessons I Learned

If I had to summarize everything into a few points, it would be these:

SQL Injection is about understanding database behavior — not memorizing payloads.
Every database platform behaves differently.
Enumeration is usually more important than immediate exploitation.
Blind SQL Injection often requires patience rather than complexity.
Burp Suite becomes dramatically more powerful once you understand Repeater, Intruder, and Collaborator.
Secure coding practices eliminate entire classes of vulnerabilities.

Defensive Takeaways

The most effective defenses against SQL Injection remain straightforward:

Use parameterized queries (prepared statements)
Never concatenate user input into SQL queries
Validate input on the server side
Apply the principle of least privilege
Suppress detailed database error messages
Regularly perform penetration testing and secure code reviews

No firewall can compensate for insecure query construction.

Final Thoughts

Completing all 18 SQL Injection labs significantly improved my understanding of how modern web applications interact with databases.

More importantly, it changed my mindset.

Instead of asking:

"Which payload should I use?"

I now ask:

"How is the application constructing this SQL query?"

That single shift in thinking made every subsequent lab much easier to understand.

What's Next?

This is the second article in my Web Security Learning Series.

Upcoming topics include:

Access Control Vulnerabilities
Cross-Site Request Forgery (CSRF)
Authentication Vulnerabilities
Server-Side Request Forgery (SSRF)
XML External Entity (XXE)
Cross-Site Scripting (XSS)

I'll continue documenting each topic through hands-on labs, technical write-ups, and practical lessons learned.

Thank you for reading!

If you're learning web application security through PortSwigger, I hope this article provides a useful overview of what to expect throughout the SQL Injection module.