In partnership with

🎯 Week 4: Injection (SQL & Command)

Break the Web: Part 4 of 8

Welcome back to Offensive Tuesday.

Hey 👋

Last week you broke access control. You changed IDs in URLs, accessed other users' data, and escalated to admin. If you missed it, catch up here 👉 week 1, week 2, week 3

This week? We're injecting malicious code into applications.

Here's the brutal truth — your input is code. Every form field, every URL parameter, every search box is a potential command line.

If the app doesn't validate what you type? You're not just a user anymore. You're executing commands on their server.

You type '; DROP TABLE users;-- into a login form. Their database gets wiped.

You enter ; ls -la into a search box. You're browsing their server files.

This is SQL Injection and Command Injection — the attacks that have compromised millions of systems and leaked billions of records.

Today you're learning how to weaponize input fields.

Let's inject some chaos. 💉

🪧Want your brand on a billboard? This is how to do it in less than 48 hours . . .

Run ads IRL with AdQuick

With AdQuick, you can now easily plan, deploy and measure campaigns just as easily as digital ads, making them a no-brainer to add to your team’s toolbox.

You can learn more at www.AdQuick.com

🧠 What is Injection?

Injection happens when untrusted data gets interpreted as code.

Think about it:

• You fill out a form

• The app takes your input

• Puts it directly into a database query or system command

• Executes it without checking

You just hijacked their execution flow.

Two main types we're covering today:

SQL Injection — Injecting database commands
Command Injection — Injecting operating system commands

Both follow the same principle: break out of the data context and execute code.

💉 SQL Injection Explained

SQL Injection lets you talk directly to the database by manipulating queries.

Normal query behind a login form:

SELECT * FROM users WHERE username='john' AND password='pass123'

The app expects you to type a username and password. But what if you type something the developer didn't expect?

What you enter:

admin' OR '1'='1

What the query becomes:

SELECT * FROM users WHERE username='admin' OR '1'='1' AND password='...'

Result: '1'='1' is always true. You just bypassed authentication.

That's SQL injection in 30 seconds.

🔧 The SQL Injection Attack Process

Step 1: Find Injectable Parameters

Look for anywhere the app accepts input:

• Login forms (username, password)

• Search boxes

• Contact forms

• URL parameters (?id=5, ?search=laptop)

• Cookies

• HTTP headers

Your job: Find where user input touches a database.

Step 2: Test for Vulnerabilities

Drop these payloads into input fields:

Single quote test:

'

If you see a database error (like "SQL syntax error"), it's vulnerable.

OR-based test:

' OR '1'='1

Time-based test (if errors are hidden):

' OR SLEEP(5)--

If the page takes 5 seconds to load, the database executed your command.

Pro tip: Start simple. One character at a time. If ' breaks the page, you're in business.

Step 3: Understand the Injection Types

Error-Based SQLi — Database errors leak information
Union-Based SQLi — Combine your query with the original using UNION
Blind SQLi — No errors shown, but you can still extract data using true/false questions
Time-Based Blind SQLi — Use delays to confirm queries worked

You don't need to memorize these. Tools will handle it. But understanding helps you recognize what's happening.

Step 4: Extract Data

Once you confirm injection works, you can:

Find database names:

' UNION SELECT schema_name FROM information_schema.schemata--

Find table names:

' UNION SELECT table_name FROM information_schema.tables--

Find column names:

' UNION SELECT column_name FROM information_schema.columns WHERE table_name='users'--

Dump data:

' UNION SELECT username, password FROM users--

But honestly? You'll use tools for this. Manual extraction takes forever.

Step 5: Automate with SQLmap

SQLmap is the industry standard. It automates everything.

Basic test:

sqlmap -u "http://target.com/page?id=1"

Dump entire database:

sqlmap -u "http://target.com/page?id=1" --dump

That's it. SQLmap handles detection, exploitation, and data extraction automatically.

⚡ Command Injection Explained

Command injection lets you execute operating system commands on the server.

Normal behavior:
App takes your input (like an IP address) and runs:

ping 192.168.1.1

What you enter:

192.168.1.1; ls -la

What gets executed:

ping 192.168.1.1; ls -la

The semicolon ends the first command. Your command runs next.

Result: You just listed their server files.

🔧 The Command Injection Attack Process

Step 1: Find Command Execution Points

Look for features that might execute system commands:

• Ping tools

• DNS lookup tools

• File converters

• Image processors

• System diagnostics

• Anything that interacts with the OS

Step 2: Test for Command Injection

Use command separators to chain commands:

Linux/Unix:

• ; — Execute next command

• && — Execute if first succeeds

• || — Execute if first fails

• | — Pipe output

• command — Command substitution

• $(command) — Command substitution

Windows:

• & — Chain commands

• && — Execute if first succeeds

• | — Pipe output

• || — Execute if first fails

Test payload:

127.0.0.1; whoami

If you see a username in the response, you're executing commands.

Step 3: Common Injection Patterns

Basic chaining:

; ls
; cat /etc/passwd
; whoami

Time-based confirmation:

; sleep 10
; ping -c 10 127.0.0.1

If the page delays, injection works even if you don't see output.

Output redirection:

; ls > /var/www/html/output.txt

Then visit http://target.com/output.txt to see results.

Step 4: Escalate Access

Once you confirm command injection:

Reverse shell — Get interactive access to their server
Download tools — Pull exploitation frameworks
Establish persistence — Create backdoors
Pivot internally — Attack other systems on their network

But we're not covering that depth here. This is about finding the vulnerability, not post-exploitation (that's a whole other series).

🛡️ Why These Work

Both attacks exploit the same flaw: mixing data with code.

The app treats your input as trusted data, but you're writing code. No separation = game over.

Developers forget:

• Input can contain special characters

• Strings can break out of quotes

• Users are adversaries, not friends

Your advantage: apps that trust user input are everywhere.

🛠️ Tool List

SQL Injection:

• SQLmap — The king of automated SQLi — Download here

• Burp Suite — Manual testing with Repeater — Download here

• NoSQLMap — For NoSQL injection — Download here

Command Injection:

• Commix — Automated command injection tool — Download here

• Burp Suite — Manual testing

• OWASP ZAP — Free alternative to Burp — Download here

Wordlists & Payloads:

• PayloadsAllTheThings — Massive injection cheat sheet — Get it here

• SecLists — Fuzzing wordlists — Download here

Learning Labs:

• PortSwigger SQL Injection Labs — Free hands-on practice — Start here

• HackTheBox — Real vulnerable machines — Join here

• TryHackMe SQL Injection Room — Guided learning — Try it

📚 Learning Resources

Deep Dives:

• OWASP Injection Guide — Complete reference — Read here

• PortSwigger SQL Injection Cheat Sheet — All payloads in one place — Get it

• PentesterLab SQL Injection Exercises — Hands-on training — Start here

Bug Bounty Reports:

• HackerOne SQL Injection Reports — Real-world examples — Browse reports

• Bugcrowd Command Injection Write-ups — Learn from hunters — Read write-ups

Books:

• The Web Application Hacker's Handbook — Chapter 9 covers injection in depth

• SQL Injection Attacks and Defense by Justin Clarke — The bible

🎯 What to Practice This Week

1. Set up a lab environment — Use DVWA (Damn Vulnerable Web App) or PortSwigger's free labs

2. Test SQL injection manually — Try bypassing a login with ' OR '1'='1

3. Run SQLmap — Automate an attack on a practice target

4. Find command injection — Test a ping tool with ; whoami

5. Read real bug bounty reports — See how pros find and exploit injection

Don't attack real systems without permission. That's illegal. Use practice labs.

That's Week 4. 💉

Tomorrow (Wednesday): How to defend against injection attacks and write secure code.

Next Tuesday: Cross-Site Scripting (XSS) — we're injecting JavaScript into browsers and hijacking sessions.

See you then.

— Zwire ✌️

P.S. Got questions? Reply to this email. I read everything.