Welcome
Use the links above (or the buttons below) to open a dedicated page for each attack. Each page contains: a short description, a simple simulated example, a step-by-step guide to run the safe demo, and the demo controls. Below each demo you'll also find a plain-language example, an analogy to explain the idea to non-technical people, and a short "what to watch for" list.
Birthday (Hash Collisions)
Short demo to show how reducing hash size increases collision probability.
Open Birthday demo →Man-in-the-middle (MitM)
Simulated sender → network → receiver flow with optional interception/modification.
Open MitM demo →SQL Injection (SQLi)
Client-side simulation of vulnerable string-concatenated SQL versus parameterized queries.
Open SQLi demo →Cross-Site Scripting (XSS)
Reflected & stored XSS simulated using innerHTML vs safe text rendering.
Open XSS demo →Birthday attack (Hash collision)
Description: Exploits probability of hash collisions to substitute one file for another with the same hash.
Simple simulated example (safe)
This page uses a tiny 16-bit demo hash so collisions appear quickly and students can observe them.
—
Plain-language example
Imagine a classroom where everyone writes their name on a small slip of paper and the teacher folds them so only the first letter shows. Two people can easily share the same visible letter — that is a collision. With small hashes we only see part of the file's identity, so two different files can 'look the same' to the hash.
Key takeaways
- Hashes are fingerprints: longer hashes (more bits) make collisions exponentially harder.
- What a collision means: two different files can produce the same hash, so a matching short hash is not proof the file is safe.
- Practical rule: prefer modern hashes (SHA-256 or stronger) and avoid any system relying on tiny or shortened hashes.
- How to verify: use digital signatures or signed checksums — these bind the file to the signer, not just the hash value.
Step-by-step guide (simulation)
- Explain: This uses a toy 16-bit hash — in reality hashes are larger (SHA-256).
- Click Find collision. The demo will brute-force random strings and show a pair with the same hash.
- Discuss probability: for N-bit hash collisions expected after ~2^(N/2) items.
- Mention mitigations: use SHA-256+, include nonces/timestamps, sign properly.
Man-in-the-middle (MitM)
Description: An attacker intercepts and possibly alters messages between sender and receiver.
Simple simulated example (safe)
—
Plain-language example
Think of sending a postcard — anyone handling the postcard can read and even change the message. Without encryption (an envelope), the message is exposed. MitM is like someone opening the postcard, changing the address, and re-sending it so it looks legitimate.
Key takeaways
- Look for the padlock: if the site warns about certificates, don’t proceed without checking.
- Public Wi‑Fi is risky: avoid logging into banking or sensitive sites on open networks without a VPN.
- Question to ask: "Is the connection encrypted?" — if not, data can be read or changed by others on the network.
- Simple habit: update your browser and OS regularly — they protect you from known interception tricks.
Step-by-step guide (simulation)
- Explain common vectors: rogue Wi‑Fi, ARP spoofing, DNS hijack, proxy interception.
- Type or use default message and click Send with MITM off to show normal forwarding.
- Enable MITM, send again to show how attacker inspects and modifies the message.
- Discuss mitigations: TLS, certificate validation, HSTS, VPNs, cert pinning.
SQL Injection (SQLi)
Description: Injecting malicious SQL by concatenating untrusted input into queries.
Simple simulated example (safe)
—
Plain-language example
Imagine a receptionist who takes whatever someone says and writes it directly into a command for a locked door. If someone shouts a special phrase, the receptionist will run it as a command and open doors they shouldn't. SQLi is when untrusted text is treated as a command instead of harmless data.
Key takeaways
- Don’t trust raw input: user input should be treated as data, not as commands.
- One-line rule: prepared statements (parameterized queries) separate data from code — prefer them.
- Least privilege: web apps should use DB accounts with minimal rights — preventing full-database compromise.
Step-by-step guide (simulation)
- Explain the vulnerable pattern: building SQL by string concatenation.
- Enter a malicious username like
admin' OR '1'='1' --and click Run (vulnerable) to show the constructed query. - Click Run (parameterized) to show how placeholders separate data from code.
- Discuss mitigations: prepared statements, ORMs, input validation, least privilege DB accounts.
Cross-Site Scripting (XSS)
Description: Injection of malicious client-side scripts that execute in other users' browsers.
Simple simulated example (safe)
Plain-language example
Think of a public message board where anything you write can be interpreted as a normal message or as instructions. If you allow instructions (scripts), a malicious message can make other visitors do things they didn't intend — like leaking their username or clicking hidden links.
Key takeaways
- Scripts are active: text that looks like code (e.g.,
<script>) can run in your browser if a site is vulnerable. - Popups and redirects: unexpected alerts or redirects can indicate XSS or malicious scripts on the page.
- Safe display rule: user content should appear as plain text, not as HTML — if it appears as HTML, be careful.
Step-by-step guide (simulation)
- Explain types: Reflected, Stored, DOM-based.
- Enter a payload like
<script>alert('XSS')</script>and click Post (vulnerable) to see execution. - Then post same input using Post (safe) to show safe rendering without execution.
- Discuss mitigations: output encoding, CSP, sanitizers, and frameworks that auto-escape.