Learn · Web simulator

Web attack simulator

Five classic web vulnerabilities (OWASP reference) explained in four phases — context, bug, impact, defence — with a log describing what a vulnerable server would do. Everything is a teaching simulation running in your browser: no network requests, no real database, no commands executed.

Who it is for: Web developers, and anyone starting out in offensive security with a defensive mindset.
Level: Intermediate
Duration: 25–35 minutes
Prerequisites: Basics of HTTP, HTML and SQL; an idea of what a session cookie is.

Learning objectives

Recognise where each vulnerability originates in the code and in the flow of a request.
Assess the real impact of each attack, without overstating or understating it.
Match each class of vulnerability with the correct, verifiable defence.

Techniques shown for study and defence only. Use them exclusively on your own systems or with written authorisation. For hands-on practice with guided scenarios, open the Virtual lab.

Catalogue

Choose what to study today

Console — SQL injection (simulated)

Try admin or paste admin' OR '1'='1 into the username field. The log describes what the vulnerable server would do.

Username

Password

[READY] Teaching environment — no real database involved

[INFO] Press the button: the four phases above light up one at a time

Typical impact: critical

Learning path

Phase 1 — What the application does

The login form sends the username and password to the back end. The back end builds an SQL string and sends it to the database to ask: "does this pair exist?".

Phase 2 — Where the bug comes from

The developer concatenates the form text straight into the query. The database receives a single string and can no longer tell SQL commands apart from data.

"SELECT * FROM users WHERE user='" + input + "' AND pass='" + password + "'"

Phase 3 — What the malicious input does

By closing the string with a quote and adding OR '1'='1, the condition becomes always true: the login can succeed without knowing the real password.

admin' OR '1'='1' --

Phase 4 — What the defender does

Parameterised queries (prepared statements): the database treats the input only as data, never as a command.
A database account with least privilege (no DROP, no file reads).
Length and format validation; generic error messages.
Logging of anomalous queries; a WAF only as an extra layer, never as the main defence.

Console — XSS (simulated)

Enter a normal comment or try <script>alert(1)</script>. No script is executed: the log only describes the flow.

Published comment

Nickname

[READY] XSS followed from the comment being published to it being displayed

Typical impact: high

Learning path

Phase 1 — Attack surface

Any user-controlled data that ends up in a page: comments, profile bios, URL parameters reflected in the response or read by JavaScript.

Phase 2 — Where the bug comes from

The input is not encoded on output. This can happen on the server, when the template prints the text without escaping, or in the browser, when JavaScript inserts it as HTML (for example with innerHTML) instead of as text: in both cases any tags inside it become code.

element.innerHTML = comment; // usa textContent

Phase 3 — Three variants

They differ in where the payload is stored and in who inserts it into the page:

Stored: the payload is saved on the server (a comment) and hits anyone who opens the page.
Reflected: the server echoes the payload back in the response to whoever follows a crafted link, once.
DOM-based: the payload never reaches the server; the page's own JavaScript inserts input (for example from the URL) into the DOM.

Phase 4 — Impact and defence

The code runs in the victim's browser: session cookie theft, actions on the victim's behalf, redirects, fake login forms.

Output encoding (treating < as text), textContent instead of innerHTML.
A Content-Security-Policy to restrict the execution of unauthorised scripts.
Session cookies with the HttpOnly and SameSite flags.

Console — Brute force (simulated)

The wordlist below is for teaching only. The simulation shows attempts and fictitious HTTP responses; it sends no requests to real login pages.

Target username (fictitious)

Wordlist (one password per line)

[READY] Attempt/response loop simulated locally

Typical impact: high

Learning path

Phase 1 — What the attacker tries

Automatically sends login requests using lists of common passwords: collected from past breaches (such as RockYou) and predictable variants (company name + year, season + exclamation mark).

Phase 2 — Why it sometimes works

Passwords chosen by people, and therefore predictable, and no limit on attempts: the cost to the attacker becomes low.

Phase 3 — Signs of success

A response that differs from the others (200 instead of 401), a session cookie, a redirect to the dashboard: the simulator describes them in the log.

Phase 4 — Defence

Rate limiting per IP and per account; progressive CAPTCHA.
A second factor (TOTP, WebAuthn): a guessed password alone is no longer enough.
Alerts on spikes of failed logins; rejecting passwords that appear in lists of compromised credentials (for example Have I Been Pwned).

Console — Insecure upload (simulated)

Teaching example: a file called foto.jpg that actually contains server-side code. No file is written to disk.

Declared file name

Content-Type sent by the browser

Content (demonstration text only)

[READY] File validation explained step by step

Typical impact: critical

Learning path

Phase 1 — Legitimate feature

The user uploads an image or a PDF; the server stores it and shows a public link.

Phase 2 — Insufficient checks

Only the extension or the MIME type declared by the client is checked: both can be forged.

Phase 3 — Escalation

If the /uploads folder executes PHP or scripts, opening the file's URL can run commands on the server.

Phase 4 — Defence

An allowlist of extensions and a check of the content's real magic bytes.
Storage outside the web root or in storage that does not execute code; files served with Content-Disposition: attachment.
Random file names (UUIDs), antivirus scanning, size limits.

Console — CSRF (simulated)

Fictitious domains (bank.example.com). The log shows how the browser automatically attaches the session cookie to a request you never chose to make.

Site where you have an active session (example)

Page you visit next (malicious)

Action the site would perform

[READY] No network requests to real domains

Typical impact: high

Learning path

Phase 1 — Valid session

You signed in to bank.example.com; the browser keeps a session cookie.

Phase 2 — Cross-site trap

You open another page containing a form or an image pointing at a sensitive URL of the bank.

Phase 3 — The "automatic" request

The browser attaches the cookies: to the server it looks like your action, even though you confirmed nothing.

Phase 4 — Defence

A unique CSRF token per session and per form.
SameSite=Lax or Strict cookies; checking the Origin header.
Explicit confirmation (password, 2FA) for irreversible operations.

Status: Lab active (offline) Topic: SQL injection Last simulation: —