DEV Community

Cover image for The Attacker's Mindset (Part 2/3): Finding XSS and SQL Injection by Hand
Mohamed
Mohamed

Posted on

The Attacker's Mindset (Part 2/3): Finding XSS and SQL Injection by Hand

#webdev #security #tutorial #docker

Part 2 of a 3-part series about the offensive security training I gave at the Algérie Télécom Skills Center in Saïda (7-77 Digital Skills Programme). Part 1 covered the attacker's mindset. This one is the hands-on day.

Sitting through security theory is easy. Opening a terminal, intercepting live HTTP traffic and rewriting a database query by hand is where it starts to click.

The theme of session 2: "Today, we hack. Together." Laptops out, no automated scanners, and a 100% legal target running on every machine. No laptop? You paired up.

Step 1: a sealed lab in one command (Docker + OWASP Juice Shop)

Instead of fighting Windows/Linux setups and dependency hell, everyone ran the same deliberately vulnerable app locally:

docker run --rm -p 3000:3000 bkimminich/juice-shop
Enter fullscreen mode Exit fullscreen mode

OWASP Juice Shop is a modern web shop full of intentional vulnerabilities. It runs in a container on your own machine, so you can attack it as much as you like without touching anyone else's system. --rm throws the container away when you stop it, so every restart is a clean slate.

Step 2: see the hidden conversation (Burp Suite)

The browser only shows you what the page wants you to see. With Burp Suite Community as a proxy, you see every request in transit, change parameters, replay requests, and watch how the server really responds.

Tip: open http://localtest.me:3000 instead of http://localhost:3000. localtest.me points to 127.0.0.1, but browsers don't skip the proxy for it the way they do for localhost, so the traffic actually shows up in Burp.

Step 3: two vulnerabilities, by hand, down to the line of code

Cross-site scripting (XSS). The search box puts what you type back into the page without escaping it. If the browser treats your input as markup instead of text, it will run your JavaScript in the page, and anyone who opens a link you crafted runs it too. We started with a harmless popup, then traced the exact code path that made it possible.

SQL injection. The login form builds its query by gluing strings together. Simplified, the server does this:

SELECT * FROM Users WHERE email = '${email}' AND password = '${passwordHash}'
Enter fullscreen mode Exit fullscreen mode

Type ' OR 1=1-- as the email, any password, and the query becomes:

SELECT * FROM Users WHERE email = '' OR 1=1--' AND password = '...'
Enter fullscreen mode Exit fullscreen mode

OR 1=1 is always true and -- comments out the password check. The database returns the first user, which in Juice Shop is the admin, and you're logged in without knowing the password.

The fix is just as concrete: parameterized queries, so user input can never change the structure of the SQL.

Step 4: AI as a teammate, not an oracle

AI won't "hack" for you. Where it helps is the careful, boring part: drafting reproduction steps and reports, explaining an unfamiliar error, double-checking a regex. Draft with it, then verify every line yourself.

The goal of the day

Leave having found real bugs by hand, understood the line of code behind each one, and written them up properly. The practice pack has the setup guide, payload references and a report template:

Next, in part 3 (Thursday): the Cyber Attack Challenge. Teams, real vulnerabilities, one clock.

Top comments (0)