How a Web Application Gets… | Presentation #250

Creator prompt

The idea behind this presentation

# How a Web Application Gets Hacked — Attack to Defense **Complete Presentation Kit (10 Slides + Speaker Notes + Q&A Prep)** **Fictional target app used throughout: "ShopKart"** — a small e-commerce app (like a mini Amazon). Students relate to e-commerce instantly, and every attack maps naturally to it. --- ## SLIDE 1 — Title & The Target ### Slide Content **Title:** How a Web Application Gets Hacked — Attack to Defense **Subtitle:** A guided attack simulation on a fictional app: *ShopKart* ``` [ATTACKER] [SHOPKART ARCHITECTURE] 👁️ | ┌─────────────┐ | Internet ───► │ Web Server │ (Login, Search, | │ shopkart.com│ Cart, Orders) | └──────┬──────┘ | ▼ | ┌─────────────┐ | │ API Server │ GET /api/orders/1042 | └──────┬──────┘ | ▼ | ┌─────────────┐ └───────────────────► │ Database │ Users, Orders, │ │ Payments └─────────────┘ ``` **One line:** *We will attack this app at 3 layers — code, API, and cloud — then rebuild it securely.* ### Speaker Notes **What to say:** "Everyone here has used Flipkart or Amazon. Today we're going to hack one — well, a fictional one called ShopKart — and then fix it. Notice the architecture: it's the same three-tier architecture you've studied in web engineering — presentation, application, data layer. The only difference is it's deployed in the cloud. And that's exactly what makes it interesting: the app has THREE attack layers — the code, the APIs, and the cloud configuration. We'll attack all three." **Definitions to mention casually:** - **Three-tier architecture** — browser → app server → database. Same as what you built in your web tech lab. - **Attack simulation** — ethical, controlled testing of your own fictional system. **Likely questions:** - *Q: Is this legal?* → "Attacking systems without permission is illegal under the IT Act (Sec 43/66). Everything here is a fictional lab, same as what tools like DVWA (Damn Vulnerable Web App) let you practice on." - *Q: Why is it in the cloud?* → "Because today almost every university project deploys on AWS/Azure free tier. Cloud misconfiguration is now one of the top causes of real breaches." --- ## SLIDE 2 — What the Attacker Sees vs. What the Developer Sees ### Slide Content **Split slide:** | 👨‍💻 DEVELOPER SEES | 🎯 ATTACKER SEES | |---|---| | A login page | A place to test default/weak credentials | | A search bar | An input that might reach the database | | `GET /api/orders/1042` | "What happens with **1043**? Someone else's order?" | | A profile picture upload | A way to upload a malicious file | | A "Forgot Password" link | An email-enumeration oracle | | A cloud dashboard (green ticks ✔) | Public storage buckets, open ports, leaked keys | **Key concepts:** ``` RECONNAISSANCE → ENUMERATION → ATTACK SURFACE → TRUST BOUNDARY Recon = watching the app like a normal user Enumeration = mapping every URL, parameter, endpoint Attack surface = every point where data crosses a trust boundary ``` ``` TRUST BOUNDARY (the key idea of this slide) [ USER INPUT — UNTRUSTED ] ║▌│▌║ [ SERVER — TRUSTED ] ║▌│▌║ Every crossing of this line is a potential vulnerability ``` ### Speaker Notes **What to say:** "When a developer finishes the project at 3 AM, they see a login page. When an attacker opens the same page, they open Burp Suite and see HTTP requests. Same app, completely different view. The developer thinks in features; the attacker thinks in *inputs* — every place data crosses from the untrusted outside to the trusted inside. That line is called the trust boundary. Every single attack in this presentation happens at one of these crossings." **Real-world example to cite:** "In 2019, Facebook accidentally left 540 million user records in a publicly exposed AWS bucket. No code was hacked — the developer 'view' (it works ✔) and the attacker 'view' (anyone can open this URL) were different. We'll recreate this in Slide 6." **Definitions:** - **Reconnaissance** — gathering info about a target without touching it (viewing page source, checking `robots.txt`, noticing tech stack). - **Enumeration** — systematically listing endpoints, parameters, usernames. - **Trust boundary** — the line where data moves from untrusted to trusted territory. **Likely questions:** - *Q: How does an attacker even find these inputs?* → "Browser DevTools, tools like Burp Suite, or just the browser's 'view source'. Everything the browser sends is visible to the user anyway." - *Q: What is Burp Suite?* → "A proxy that sits between your browser and the server so you can see and modify every request. Standard tool in every security lab." --- ## SLIDE 3 — The Attack Methodology ### Slide Content ``` ┌──────────────┐ ┌──────────────┐ ┌──────────────────┐ │ 1. RECON │──►│ 2. ENUMERATE │──►│ 3. FIND VULN │ │ Goal: know │ │ Goal: map │ │ Goal: find the │ │ the target │ │ every input │ │ weak input │ │ │ │ & endpoint │ │ │ └──────────────┘ └──────────────┘ └────────┬─────────┘ ▼ ┌──────────────┐ ┌──────────────┐ ┌──────────────────┐ │ 6. IMPACT │◄──│ 5. GAIN │◄──│ 4. EXPLOIT │ │ Data breach, │ │ ACCESS │ │ Craft & send the │ │ takeover │ │ Session/role │ │ malicious input │ └──────────────┘ └──────────────┘ └──────────────────┘ DEFENDER'S PARALLEL VIEW (same pipeline, flipped): Recon → Detect recon (odd traffic patterns) Enumerate → Rate limiting, 404 monitoring Exploit → WAF rules, input validation Impact → Logs, alerts, incident response ``` **One line:** *The attacker runs a pipeline. Security = breaking any single stage of it.* ### Speaker Notes **What to say:** "Notice this is exactly like the software development life cycle — but inverted. Attackers are methodical, not magical. This matters because it means defense is also methodical: I don't need to stop the attacker, I just need to break ONE stage of their pipeline. If I detect the enumeration, the exploit never happens." **Practical point (marks magnet):** "Remember this: **an attacker needs every stage to succeed; a defender only needs one stage to fail (for the attacker).** This asymmetry is the foundation of security architecture." **Likely questions:** - *Q: How long does a real attack take?* → "Recon can take weeks (silent), exploitation seconds. That's why detection tools focus on the slow recon/enumeration phase — it's the attacker's most visible phase." - *Q: Is this the same as the Cyber Kill Chain?* → "Yes — Lockheed Martin's Kill Chain has 7 stages; this is a simplified web-app version of it." --- ## SLIDE 4 — Attack #1: SQL Injection (The Search Bar) ### Slide Content **The setup — ShopKart's product search:** ``` User types in search box: laptop │ ▼ VULNERABLE CODE (string concatenation): query = "SELECT * FROM products WHERE name = '" + input + "'" │ ▼ Attacker types: laptop'-- ◄── 🚨 THE INJECTED INPUT Final query sent to DB: SELECT * FROM products WHERE name = 'laptop'--' ◄── everything after -- is a COMMENT (rest of query is neutralized) ``` **Same attack on the LOGIN:** ``` Intended: WHERE user='xxx' AND pass='yyy' (both must match) Injected: WHERE user='admin'--' AND pass='' (password check is COMMENTED OUT) Result: ✔ Logged in as admin — password never checked ``` **THE FIX — Parameterized Query (Prepared Statement):** ``` BEFORE (vulnerable): AFTER (secure): stmt = prepare( "SELECT * FROM users "SELECT * FROM users WHERE user='"+u+"' WHERE user=? AND pass=?") AND pass='"+p+"'" stmt.bind(u); stmt.bind(p) Input becomes DATA, not CODE. ┌─────────────────────────┐ │ Input: laptop'-- │ │ Treated as: a product │ │ name that literally │ │ doesn't exist → 0 hits │ └─────────────────────────┘ ``` **Attack → Defense summary bar:** | Attack | Vulnerability | Impact | Detection | Defense | |---|---|---|---|---| | Send `--`, `'` in inputs | Input concatenated into SQL | Full DB access, auth bypass | Weird queries in DB logs, WAF flags `'--` | Prepared statements + input validation | ### Speaker Notes **What to say:** "Here's the core idea in one sentence: **SQL injection happens when user input is treated as code instead of data.** The database receives one string, and it can't tell which part the programmer wrote and which part the user typed. The `--` in SQL means 'comment' — everything after it is ignored. So the attacker's input didn't add anything malicious; it *deleted* the security check. That's why injection attacks are so elegant — they edit the query rather than break it." Walk through the before/after carefully — this is the money moment of the presentation: "With a prepared statement, the query structure is sent to the database FIRST, with empty slots — the question marks. Then the input is bound to those slots as pure data. The database has already decided the query's shape. Even if I type `DROP TABLE` — it will just search for a product literally named 'DROP TABLE' and return zero results. The input physically cannot change the query anymore." **Real-world example:** "SQLi is old (documented since 1998) but still in the OWASP Top 10 in 2021 (A03: Injection). In 2012, Yahoo was breached via SQLi that exposed 450,000 accounts. It survives because developers still concatenate strings when deadline pressure hits." **Definitions:** - **Prepared statement** — a pre-compiled SQL template where inputs are bound later as data. - **WAF (Web Application Firewall)** — a filter sitting in front of the app that blocks requests containing known attack patterns. - **Injection** — untrusted input changing the meaning of a command meant for an interpreter (SQL, OS shell, etc.). **Likely questions:** - *Q: Can't we just escape the quotes / blacklist bad characters?* → "Blacklists always miss something — encoding tricks, unusual syntax. Parameterization removes the entire class of problem because input is never parsed as code." - *Q: Does this work the same in NoSQL/MongoDB?* → "Yes, injection exists there too — instead of SQL syntax, attackers abuse query operators like `$ne`. The fix is the same concept: validate input as data." - *Q: Is ORM enough?* → "Mostly yes — ORMs parameterize by default. But raw query escape hatches in ORMs can still be vulnerable." - *Q: Where do we see the attack as defenders?* → "Database slow-query logs, weird response times, WAF signatures, and errors appearing in app logs where they never did before." --- ## SLIDE 5 — Attack #2: Broken API Authorization (IDOR) ### Slide Content **The setup — ShopKart order history:** ``` Aarav (user_id=101) is logged in. He clicks "My Orders": GET /api/orders/1042 ← HIS order ✔ 200 OK GET /api/orders/1042.json ← weird format ✔ 200 OK (info leak) Attacker's question: "What about /api/orders/1043?" ``` ``` WHAT THE CODE CHECKS vs WHAT IT SHOULD CHECK ┌─────────────────────────────────────────────┐ │ if (user.isLoggedIn()) { ← AUTHENTICATION ✔ │ return getOrder(requestedId); ← AUTHORIZATION ✘ MISSING! │ } │ │ // Never checked: does this order │ // BELONG to this user?? └─────────────────────────────────────────────┘ GET /api/orders/1043 ───► returns PRIYA's order (address, phone, total, items) — to Aarav. No alarms. ``` **THE key distinction (say this loudly):** ``` AUTHENTICATION = "Who are you?" → checked ✔ AUTHORIZATION = "Is this YOURS?" → NOT checked ✘ ``` **THE FIX — Object-Level Access Control:** ``` Secure version: if (user.isLoggedIn() AND order.userId == user.id) { return order; } else { return 403 Forbidden; // every check fails CLOSED } ``` | Attack | Vulnerability | Impact | Detection | Defense | |---|---|---|---|---| | Change ID in URL | Missing object-level authorization | Mass data leak of all users' orders | One user requesting sequential IDs; API logs show cross-user ID access | Check ownership of EVERY object; use random UUIDs (harder to guess); rate limiting | ### Speaker Notes **What to say:** "This is my favorite vulnerability to teach because it requires zero hacking skill. No payloads, no tools. Aarav just changes one number in the URL. The server happily returns someone else's order because the developer checked *authentication* — is this a logged-in user — but never *authorization* — does this specific order belong to this specific user." "This is called **IDOR — Insecure Direct Object Reference** — and it's OWASP API Security Top 10's #1 issue (BOLA — Broken Object Level Authorization). It's extremely common in student projects and startups, because developers test with their own account, it works, ship it." "Here's the scary part for detection: from the server's view, this looks like a *normal successful request*. 200 OK. No error, no alarm. That's why the detection signal is in the *pattern* — one account requesting hundreds of sequential order IDs is the giveaway." **Real-world example:** "In 2019, a security researcher found he could view **any** user's transaction history on a major payments app just by changing the user ID in an API call — millions of records, no 'hacking' involved. Also, the 2019 Experian breach exposed 24 million records through a similar endpoint flaw." **Definitions:** - **IDOR** — accessing another user's object by manipulating its reference (ID) in the request. - **403 vs 401** — 401 means "not authenticated," 403 means "authenticated but not allowed." Good APIs return these correctly. - **Fail closed** — if a check errors out, deny access by default. Never fail open. **Likely questions:** - *Q: Isn't using UUIDs instead of numeric IDs a fix?* → "It's defense-in-depth — UUIDs are unguessable. But hiding the ID is *security by obscurity*; if the ID leaks (in a link, log, or another API), you still need the server-side ownership check. The check is the real fix." - *Q: How do we test for IDOR?* → "In a lab: log in as two users, capture user A's request for an object, swap to user B's object ID, see if it returns. That's the entire test." - *Q: What about horizontal vs vertical?* → "Horizontal = accessing peer users' data (this case). Vertical = accessing admin functions as a normal user (e.g., calling `/admin/deleteUser` as a student). Both are authorization failures." --- ## SLIDE 6 — Attack #3: The Cloud Misconfiguration ### Slide Content **The twist — the CODE is now perfect. Attacks 1 & 2 are fixed. And the app still gets breached.** ``` THE SHOPKART CLOUD DEPLOYMENT Internet ──► [WAF/LB] ──► [Web App] ──► [API] ──► [Database] │ └──► [S3 Bucket: shopkart-backup-files] ▲ 🔓 SET TO "PUBLIC" 🔓 IAM role: FullS3Access (*) 🔓 Hardcoded AWS key in public GitHub repo ``` **Three realistic cloud weaknesses (choose the story):** ``` 1. PUBLIC STORAGE Backup bucket set to public "so the team could download files easily" → contains user_data.csv (10 lakh customers). Anyone with the URL has it. 2. LEAKED CREDENTIALS Developer pushed code to GitHub with: aws_access_key_id = AKIA...EXAMPLE Bots scan GitHub for these keys within MINUTES. 3. OVER-PERMISSIVE SECURITY GROUP Database port 3306 open to 0.0.0.0/0 ("public") → attacker can reach the DB directly, bypassing the entire web app. ``` **THE FIX — least privilege everywhere:** | Weakness | Defense | |---|---| | Public bucket | Private by default + presigned URLs with expiry | | Key in code | Secret manager / IAM roles — **zero keys in code** | | Open DB port | Security group allows only the app server's IP; DB in private subnet | | Nobody noticed | Cloud posture scanning (AWS Config, Security Hub) + alerts on "bucket made public" | ### Speaker Notes **What to say:** "Here's the punchline of this whole slide: **the code was perfect and the app still got hacked.** Because the application is no longer just code — it's code PLUS configuration PLUS credentials PLUS network rules. A single wrong dropdown — 'Public' instead of 'Private' on a storage bucket — does what a thousand SQL injection attempts couldn't." "My favorite statistic for this slide: Gartner estimated that through 2025, **99% of cloud security failures will be the customer's fault** — meaning misconfiguration, not the cloud provider being hacked. AWS gives you a padlock; leaving it unlocked is on you." Tell the story: "Imagine the developer at 2 AM thinking — 'the team needs these backup files, I'll just make the bucket public, we'll fix it later.' There is no 'later' — automated bots scan for public buckets and leaked AWS keys continuously. A key pushed to a public GitHub repo gets found in minutes." **Definitions:** - **S3 bucket** — AWS cloud file storage; each has an access policy (public/private). - **IAM (Identity and Access Management)** — cloud permission system; roles define who can do what. - **Least privilege** — every identity gets ONLY the permissions it needs. Not `S3FullAccess` — only read/write to one specific bucket. - **Security group** — cloud firewall rules controlling which IPs/ports can reach a server. - **Presigned URL** — temporary, expiring link to a private file. **Likely questions:** - *Q: Why not just keep secrets in a config file?* → "Config files end up in repos, backups, and logs. Secret managers (AWS Secrets Manager, Vault) encrypt, audit access, and rotate keys automatically." - *Q: What's a private subnet?* → "A network segment with no internet route. The database can talk to the app server but is unreachable from the internet. Even if the DB has a weak password, attackers can't even connect." - *Q: How does the attacker FIND these?* → "Public buckets via URL guessing and scanners; leaked keys via bots monitoring GitHub pushes; open ports via internet-wide scans (tools like Shodan map every open port on the internet)." - *Q: Is this the responsibility of AWS?* → "No — the Shared Responsibility Model: AWS secures the infrastructure; YOU secure what you put in it and how you configure it." --- ## SLIDE 7 — Detection & Incident Response (The Fightback Begins) ### Slide Content **Our app has been under attack all along. Here's what the SOC (Security Operations Center) saw:** ``` THE ATTACK vs THE ALERTS — SAME TIMELINE, TWO COLUMNS ATTACKER SIDE │ DEFENDER SIDE (SIEM console) ──────────────────────────────┼────────────────────────────────── 10:02 Credential stuffing │ ⚠ 400 failed logins from 1 IP (10k leaked passwords) │ → Rate-limit alert fires 10:03 Login succeeds (weak │ ⚠ Login from new country password: Aarav123) │ → Impossible-travel anomaly 10:03 IDOR: requests orders │ ⚠ Sequential API calls: 1042, 1043, 1044... │ 1 user → 800 orders in 60s 10:04 SQLi probe: ' -- │ 🔴 WAF BLOCKS request sent to /search │ → SQLi signature detected 10:05 │ ✅ Account auto-locked. │ API token revoked 10:10 │ 👤 On-call engineer paged; │ investigation begins 10:40 │ ✅ Breach contained: 3 orders │ exposed. Root cause: IDOR 11:00 │ 🔧 Hotfix deployed; user │ notified; post-mortem ``` **The IR lifecycle (say it like a fire drill):** ``` PREVENT ─► DETECT ─► RESPOND ─► RECOVER ─► (LEARN ─► loop back) (MFA, WAF, (logs, SIEM, (block, revoke, (patch, restore, param'd alerts, isolate) notify users) queries) anomalies) ``` **One line:** *The attacker needs minutes. Our detection pipeline gave us minutes too — and that decided the outcome.* ### Speaker Notes **What to say:** "Read the left column and you'll notice the attack was noisy. Four hundred failed logins. Eight hundred API calls in a minute. This is the secret defenders rely on: **attacks leave fingerprints.** The question is never 'did we log it?' — it's 'does anyone look at the logs before it's too late?' That's what a SIEM does." "What's a SIEM? It's the security control room — it collects logs from every system (login logs, API logs, WAF, cloud audit logs) and correlates them. One failed login is noise. Failed logins + new country login + sequential ID access within 3 minutes = one incident, with one alert to one engineer. Correlation is the magic." Point at the timeline: "Notice the response was largely **automated** — rate limiting kicked in at 10:02, the WAF blocked SQLi at 10:04. Humans only got involved at 10:10. In modern security, automation contains the attack; humans investigate it." **Real-world example:** "The famous 2013 Target breach — the alerting system DID detect the malware and fired warnings. But the alerts were ignored in the holiday rush. 40 million card numbers stolen. Detection without response is decoration." **Definitions:** - **SIEM** (Security Info & Event Management) — aggregates and correlates security logs across systems. - **Credential stuffing** — replaying leaked username/password pairs from other breaches against your login. - **Anomaly detection** — alerting on deviations from a baseline (normal users don't request 800 order IDs). - **Post-mortem / root-cause analysis** — the blameless write-up after an incident: what happened, why, what changes. **Likely questions:** - *Q: What's MTTR / why do you keep emphasizing time?* → "Mean Time to Detect and Mean Time to Respond are the two KPIs of security ops. Attackers need an average of minutes to hours; companies historically took ~200+ days to even detect a breach. Every day undetected = more data lost." - *Q: What logs should an app actually keep?* → "Authentication events (success AND failure), all authorization denials (403s), input validation failures, admin actions, and cloud config changes. And protect the logs themselves — attackers delete logs first." - *Q: What if the attacker is quiet — no brute force?* → "Then behavioral anomalies carry the load — a dormant account waking up, data downloaded at odd hours, access from a new device. Defense in depth exists precisely because no single signal is reliable." --- ## SLIDE 8 — Before vs After: Same App, Hardened ### Slide Content ``` BEFORE (how we got hacked) AFTER (hardened ShopKart) Internet Internet │ │ ▼ ▼ ┌──────────┐ ┌─────────────────────────┐ │ Web App │ │ WAF + DDoS Protection │◄── blocks SQLi │ • concat │ └───────────┬─────────────┘ patterns │ SQL ✘ │ ▼ │ • no │ ┌─────────────────────────┐ │ authz ✘│ │ Load Balancer + HTTPS/ │◄── encryption, └────┬─────┘ │ rate limiting │ traffic shaping ▼ └───────────┬─────────────┘ ┌──────────┐ ▼ │ Database │ ┌─────────────────────────┐ │ • public │ │ Web App │◄── prepared │ port ✘ │ │ • MFA login │ statements ✔ └──────────┘ │ • prepared statements ✔ │ (fixes Attack 1) │ • input validation │ └───────────┬─────────────┘ ▼ ┌─────────────────────────┐ │ API layer │◄── object-level │ • authorization check ✔ │ authorization │ on EVERY object │ (fixes Attack 2) └───────────┬─────────────┘ ▼ ┌─────────────────────────┐ │ PRIVATE subnet database │◄── no public port, │ • IAM least privilege │ secret manager, │ • encryption at rest │ private storage │ • no keys in code │ (fixes Attack 3) └───────────┬─────────────┘ ▼ ┌─────────────────────────┐ │ Logging + Monitoring │◄── full audit trail, │ • SIEM + alerts │ cloud posture │ • posture scanning │ scanning └─────────────────────────┘ ``` **Map each control to the attack it kills:** | Control | Kills which attack | |---|---| | Prepared statements | SQL Injection (Attack 1) | | Object-level authorization | IDOR (Attack 2) | | Private subnet + IAM least privilege + secret manager | Cloud misconfig (Attack 3) | | MFA | Credential stuffing | | WAF + rate limiting | Automated probing & floods | | Logging + SIEM | The "silent" attack (detection layer) | ### Speaker Notes **What to say:** "Same app. Same three tiers. Completely different security posture. And here's the key insight I want you to take away: **look where the fixes live.** One fix is in the code (prepared statements). One is in the API logic (authorization). One is in the network and IAM (private subnet). One isn't a fix at all — it's the ability to *notice* (monitoring). Security is not a feature you add; it's a property you distribute across every layer." Walk the audience down the AFTER stack: "Follow one request: it arrives over HTTPS, passes the WAF, gets rate-limited, hits the app where the input is parameterized, passes the API where ownership is verified, reaches a database that the internet can't even see, and every step leaves a log line in the SIEM. To breach this, the attacker must defeat ALL of it. To defend, we only had to defeat ONE of their steps. Same asymmetry from Slide 3 — now you can see it as architecture." **Definitions:** - **MFA** — Multi-Factor Authentication: password + OTP/biometric. Kills credential stuffing because a leaked password alone isn't enough. - **Encryption at rest vs in transit** — data encrypted on disk (DB breach yields ciphertext) vs on the wire (HTTPS stops eavesdropping). - **Defense in depth** — multiple independent layers, so one failure isn't fatal. **Likely questions:** - *Q: Doesn't all this slow down the app / cost money?* → "Some overhead, yes — but WAF and rate limiting are managed services, and the cost of one breach (fines under DPDP Act/GDPR, reputation) dwarfs the subscription. Security is insurance you pay for before the fire." - *Q: Is WAF enough instead of fixing code?* → "No — WAFs are bypassable with encoding tricks and novel payloads. They're a shield, not a cure. Fix the code AND keep the shield." - *Q: What is OWASP?* → "Open Web Application Security Project — publishes the OWASP Top 10, the industry-standard list of most critical web vulnerabilities. Everything we covered maps directly to it: Injection (A03), Broken Access Control (A01 — the #1 in 2021), Security Misconfiguration (A05), plus the API Top 10." --- ## SLIDE 9 — The Big Picture: End-to-End Attack-to-Defense Pipeline ### Slide Content ``` ╔══════════════════════════════════════════════════════════════════╗ ║ THE COMPLETE ATTACK → DEFENSE LIFECYCLE ║ ║ ║ ║ ATTACKER'S PATH (top) DEFENDER'S COUNTER (bottom) ║ ╠══════════════════════════════════════════════════════════════════╣ ║ ║ ║ 1. RECON ← Minimize public info, ║ ║ ex: view source, robots.txt monitoring odd traffic ║ ║ ↓ ║ ║ 2. ATTACK SURFACE ← Reduce & harden every ║ ║ ex: search box, /api/orders input & endpoint ║ ║ ↓ ║ ║ 3. VULNERABILITY ← Secure code review, ║ ║ ex: SQL string concat SAST/DAST scanning ║ ║ ↓ ║ ║ 4. EXPLOITATION ← WAF, input validation, ║ ║ ex: laptop'-- sent rate limiting ║ ║ ↓ ║ ║ 5. IMPACT ← Least privilege limits ║ ║ ex: auth bypass, IDOR leak the blast radius ║ ║ ↓ ║ ║ 6. DETECTION ← Logs, SIEM correlation, ║ ║ ex: 400 failed logins/min anomaly alerts ║ ║ ↓ ║ ║ 7. RESPONSE ← Block, revoke, isolate, ║ ║ ex: account auto-locked automated playbooks ║ ║ ↓ ║ ║ 8. REMEDIATION ← Patch root cause, ║ ║ ex: parameterized queries verify the fix ║ ║ ↓ ║ ║ 9. SECURE DEVELOPMENT ← Repeat forever. ║ ║ ex: threat modeling in every Security is a loop, ║ ║ sprint, not a phase not a checklist. ║ ╚══════════════════════════════════════════════════════════════════╝ ``` ### Speaker Notes **What to say:** "This single diagram is the entire presentation compressed. Trace the top row: that's the attacker's journey — the exact path we walked through ShopKart. Now look below each stage: every attacker step has a defender counter-step. This pairing is the whole discipline of security in one picture." Close with the loop: "See stage 9 pointing back to the start? That's deliberate. There is no 'finished securing the app.' New features, new developers, new dependencies — the attack surface regenerates. The organizations that survive aren't the ones that were never attacked; they're the ones that detect faster, respond faster, and learn faster." **Likely questions:** - *Q: What are SAST and DAST?* → "SAST = Static Application Security Testing — scans source code for dangerous patterns (like string-concatenated SQL) before deployment. DAST = Dynamic — attacks the running app from outside like a black box. Use both: SAST catches it early, DAST catches what SAST misses." - *Q: What is threat modeling?* → "Before writing code, you ask: what can go wrong here? Four questions — what are we building, what can go wrong, what will we do about it, did we do a good job? STRIDE is a common framework. Five minutes of threat modeling prevents Slide 4 from ever existing." - *Q: Which stage do companies most often skip?* → "Detection and learning. Most teams are decent at prevention (SSL, passwords) but have no monitoring and no post-mortems. That's why breaches run undetected for months." --- ## SLIDE 10 — Key Takeaways ### Slide Content **Six lessons from hacking ShopKart:** 1. **Secure by design, not by patch** — the SQLi existed because of one concatenated string; the IDOR because of one missing check. Both were cheap to prevent, expensive to fix. 2. **Authentication ≠ Authorization** — "Who are you?" is not "Is this yours?" The most damaging modern API flaws live in that gap. 3. **Every input is a boundary** — search boxes, URL IDs, uploaded files, config dropdowns. Trust boundaries are where attacks live. 4. **Perfect code can still be breached** — one public bucket, one leaked key, one open port. Cloud configuration IS the attack surface. 5. **Prevention + Detection + Response** — you need all three. Prevention fails; detection is your safety net; response decides the damage. 6. **Security is a loop, not a phase** — recon → attack → detect → fix → recon again, forever. ``` ┌─────────────────────────────────────────────────────┐ │ │ │ "Understanding how attackers think is one of │ │ the best ways to design systems that │ │ resist attacks." │ │ │ │ — Today, you didn't memorize vulnerabilities. │ │ You walked in an attacker's shoes. │ │ That perspective is your defense. │ │ │ └─────────────────────────────────────────────────────┘ ``` *(Optional footer: Tools to try safely in a lab: OWASP Juice Shop, DVWA, PortSwigger Web Security Academy — free, legal, browser-based.)* ### Speaker Notes **What to say:** "Let's close the story. We never used a single advanced tool. We looked at a search box, changed a number in a URL, and noticed a dropdown said 'Public.' Three tiny, mundane mistakes — and each one alone could have ended ShopKart. That's the real lesson: breaches are almost never cinematic. They're small doors left open by ordinary decisions under deadline pressure." "Six takeaways — if you remember only two, make them these: **authentication is not authorization**, and **cloud configuration is part of your code**. Those two ideas cover most real-world breaches of the last five years." Finish strong: "I want to leave you with this: the best defenders I know of were students who learned to attack first — in legal labs like OWASP Juice Shop or PortSwigger Academy, both free and browser-based. You don't have to take my word for it — spend one evening on the Web Security Academy and you'll have run every attack from today, legally, against apps designed to be hacked. Understanding how attackers think is one of the best ways to design systems that resist attacks. Thank you." **Likely questions:** - *Q: What's the single most important defense?* → "For web apps specifically: input handling + authorization checks, enforced with prepared statements and object-level access control. Statistically, OWASP's #1 category in 2021 was Broken Access Control — our Slide 5." - *Q: Where do we legally practice this?* → "OWASP Juice Shop, DVWA, PortSwigger Web Security Academy, TryHackMe, HackTheBox (with permission-based labs). All designed to be attacked. Never practice on live systems you don't own." - *Q: How does this connect to what companies actually do?* → "Everything here maps to real job roles: penetration testers run Slides 2–6, SOC analysts live in Slide 7, DevSecOps engineers build Slide 8, and AppSec owns Slide 9." --- # 📋 PRESENTING GUIDE (Not a slide — for you) ### How to deliver this for maximum marks 1. **Open with the story, not the definition** (30 sec): *"Let me tell you how a company gets hacked. Not in a movie — in real life, on a Tuesday afternoon, because of a search box."* 2. **Use the recurring villain-hero framing**: Attacker actions in red tones, defender actions in green/blue tones — on every slide. Professors consistently reward clear attacker/defender separation. 3. **The three money moments** (practice these three explanations until smooth): - Slide 4: the `--` comment walkthrough + "input becomes data, not code" - Slide 5: "Authentication = who are you, Authorization = is this yours" (say it twice, slowly) - Slide 6: "The code was perfect. The app still got hacked." (pause after this line) 4. **The asymmetry line** (use it in Slide 3 AND Slide 8 — it's your thesis): *"The attacker needs every stage to succeed; the defender needs only one to fail. Security architecture is the engineering of that asymmetry."* 5. **Timing for a 10-min slot**: ~50 sec/slide. Skip nothing, but if running long, compress Slide 2 (60%) and Slide 3 (50%) — the attack scenarios and the before/after are where the marks are. 6. **If asked anything you don't know**: tie it back to a slide. E.g., "That's essentially a deeper case of the trust-boundary issue from Slide 2..." — professors reward conceptual anchoring over memorized trivia. ### Quick technical-accuracy self-check (already verified in content above) - ✔ Every attack has all five: Attack → Vulnerability → Impact → Detection → Defense - ✔ SQLi example uses the universally taught `--` comment technique (safe, conceptual, no weaponized payload) - ✔ IDOR = OWASP API Top 10 #1 (BOLA) — correctly framed - ✔ Cloud section reflects the Shared Responsibility Model correctly - ✔ OWASP Top 10 2021 references are accurate (A01 Broken Access Control, A03 Injection, A05 Misconfiguration) - ✔ No content enables attacking real systems — all examples are fictional or lab-oriented Good luck — walk in like someone who's already hacked ShopKart once and fixed it twice. 🛡️ Follow Design: {"palette":["Canvas porcelain #F8FAFC — crisp light background","Blueprint navy #0F2744 — authoritative headers and structural text","Exploit coral #E11D48 — vulnerability callouts and untrusted boundaries","Hardened teal #0D9488 — secure implementations and trust boundaries","Steel neutral #64748B — secondary annotations and technical notes","Surface white #FFFFFF — elevated content cards and code panes"],"fonts":{"Plus Jakarta Sans":"https://fonts.googleapis.com/css2?family=Plus+Jakarta+Sans:ital,wght@0,200..800;1,200..800&display=swap","IBM Plex Sans":"https://fonts.googleapis.com/css2?family=IBM+Plex+Sans:ital,wght@0,100..700;1,100..700&display=swap","IBM Plex Mono":"https://fonts.googleapis.com/css2?family=IBM+Plex+Mono:ital,wght@0,100;0,200;0,300;0,400;0,500;0,600;0,700;1,100;1,200;1,300;1,400;1,500;1,600;1,700&display=swap"},"type":"Plus Jakarta Sans for clean geometric titles and section anchors; IBM Plex Sans with high line-height for instructional clarity; IBM Plex Mono for database queries, endpoints, and protocol tags.","layout":"Precision 12-column architectural grid with generous margins; modular 2x2 and 3x2 card arrays for vulnerabilities and controls; side-by-side comparison panels with distinct before and after headers.","framework_treatment":"Crisp hairline borders, subtle dot-matrix background accents, structured threat-modelling comparison cards, pill-shaped category badges, and minimal wireframe architectural diagrams.","feels_like":"A Stripe-grade engineering security whitepaper and interactive university computer science masterclass deck"}

How a Web Application Gets… | Presentation #250 | Presenton

How a Web Application Gets Hacked — Attack to Defense

The idea behind this presentation

About this How a Web Application Gets Hacked — Attack to Defense presentation example

Three things to review before creating your version

Story structure

Visual hierarchy

Design consistency

Turn inspiration into an original presentation