Ravindra BagaleCourses & study guides

29. OWASP Top 10 Web Vulnerabilities

29.8 Red vs Blue, Project and Real Incidents

By Last updated:

Chala mitrano, SQLi, XSS, IDOR, command injection, SSRF, outdated components – aata Purple Team loop. Red OWN DVWA/Juice Shop/.50 kiwa Chapter-16 reels app madhe ek Top-10 class dakhavto; Blue prepared statements, output encoding + CSP, server-side authZ, allow-lists, logging ani dependency update ne band karto. Tumhi Raja-Rani Traders style OWN lab madhe build → hack → fix karun Purple report liha. Awareness + fix; weaponized internet PoC paste nahi. Samjla ka? Dusryacha website – kadhi nahi.

Red Team vs Blue Team – OWASP Top 10 awareness

Red team (attacker) does Blue team (defender) detects / stops
SQLi awareness on OWN DVWA (manual OR high-level sqlmap from Ch.21) Prepared statements / parameterised queries; least DB privilege; WAF as extra layer
Reflected/stored XSS demo in OWN lab Context-aware output encoding + CSP + HttpOnly cookies
IDOR: change id= to another user's record on OWN app Server-side authorisation: every request checks role and ownership
Command injection awareness (; / | in unsafe system()-style code) Allow-list arguments; escapeshellarg(); avoid shell for user input
SSRF: point server at internal/metadata URL on OWN lab design Allow-list outbound destinations; block link-local/metadata IPs; IMDSv2 on AWS
A06: hit known CVE in an outdated lab component Inventory dependencies; sudo yum update / Composer-npm updates; remove unused libs
Skip logs so nobody notices Log authZ failures and injection-looking input; alert in SOC (Ch.31)

Defender chi simple checklist: parameterise SQL → encode output + CSP → server-side authZ for every object → allow-list OS/URL targets → patch components → log + monitor → re-prove the attack path is closed. Red lab tool awareness; Blue secure coding. Interview madhe "I ran sqlmap" peksha "I demonstrated one OWASP class on my lab app, fixed it with prepared statements/authZ, and re-proved the exploit failed" jast strong.

# OWN lab only – Kali 192.168.56.10 → DVWA/Juice Shop/reels on 192.168.56.50 (or your Chapter-16 app)
mkdir -p ~/labs/raja-rani-owasp
# Pick ONE class for the Purple loop (example: SQLi on DVWA low → then fix on YOUR PHP):
#   1) Baseline: screenshot the vulnerable behaviour on OWN target only
#   2) Fix on the code YOU control (prepared statement example idea):
#        $stmt = $pdo->prepare('SELECT * FROM users WHERE name = ?');
#        $stmt->execute([$name]);
#   3) Re-test the same input – should fail safely
# Helper packages on Amazon Linux app VM you own:
#   sudo yum update
#   sudo service nginx status    # or httpd / php-fpm – confirm app still up after fix
#   sudo service mysqld status
# Record before/after in notes (no weaponized public-site payloads):
echo 'Target: OWN 192.168.56.50 – class: (SQLi|XSS|IDOR|cmd|SSRF)' \
  > ~/labs/raja-rani-owasp/scope.txt
echo 'Fix: (prepared statements | encoding+CSP | server authZ | allow-list | patch)' \
  >> ~/labs/raja-rani-owasp/scope.txt
# Optional high-level Ch.21-style check on OWN DVWA only (awareness – not a full attack cookbook):
#   nikto -h http://192.168.56.50/   # info only; then FIX findings you own

Ravindra Bagale's Tip

Students Top-10 chi list pathantar kartat pan ekhi fix code madhe nahi – interview madhe fail. Dusri chuk: sqlmap chi full attack recipe notebook madhe paste karun public site try. Rule: OWN DVWA/Juice/reels only → ONE class demo → FIX in code same day → re-prove path closed → Purple report. OWASP chapter = secure-coding chapter. Ghabru naka, practice ne yetay.

Lab

DVWA 192.168.56.50 (kiwa Juice Shop / swatahcha reels app) var ekach risk choose kara – SQLi OR XSS OR IDOR. Vulnerable behaviour notes + screenshot ~/labs/raja-rani-owasp/. Mag tyachya matching fix (prepared statement / encoding+CSP / server-side ownership check) apply karun punha try – attack fail zala pahije. sqlmap full internet cookbook naka. Public websites nahi.

Project: Build it, hack it, fix it

Build: For fictional Raja-Rani Traders (Nashik shop web order form) on host-only 192.168.56.50 (DVWA / Juice Shop / Chapter-16 reels app you own):

  1. Pick one OWASP class to own end-to-end (recommended: SQLi or IDOR – easiest to prove fix)
  2. Confirm lab scope file: host-only IPs only; written note that this is Raja-Rani's OWN practice app
  3. Ethics card: IT Act – no scanning or injecting on third-party sites; no pasting weaponized PoCs into public chats

Hack (lab awareness – OWN systems only): From Kali 192.168.56.10:

  • Reproduce the chosen class with the minimum input needed (manual SQLi/XSS/IDOR steps already taught in this chapter / Ch.21 style)
  • Capture request/response or screenshot proving impact (e.g. extra DB rows, script alert, other user's order id)
  • Name tools (Burp, browser, optional sqlmap awareness) in the report; do not paste a full weaponized exploit kit

Do not attack production shops, do not use customer databases, do not publish live exploit strings for unpatched internet targets.

Fix:

  • SQLi → parameterised queries / prepared statements; least-privilege DB user
  • XSS → output encoding + CSP + HttpOnly; validate input length/type
  • IDOR → server-side check that Raja/Rani session owns the object id
  • Command injection → allow-list; no raw shell with user strings
  • SSRF → allow-list URLs; block 169.254.169.254 style metadata
  • A06 → update libraries (sudo yum update on Amazon Linux helpers; Composer/npm for app libs)
  • Turn on basic security logging for failed authZ and suspicious input

Re-verify: Same payload/path fails after the fix; regression test one happy-path feature (login/order still works). 1-page Purple report for owners Raja and Rani: finding → OWASP category → code fix → evidence. Peer-review with Zoya / Salman. IT Act: only systems you own or are authorised to test.

Real incident: TalkTalk – SQL injection (2015)

In October 2015, UK provider TalkTalk suffered a breach that the ICO later described as exploiting SQL injection on legacy web pages (reported as inherited from a prior acquisition), with outdated database software and weak monitoring. TalkTalk reported that personal data for on the order of 156,959 customers was accessed, including thousands of sets of bank details and partial card data (treat published figures as reported). The ICO issued a then-record fine (reported £400,000) and stressed that SQLi was a well-understood risk with known defences. Weakness: injectable legacy pages + unpatched DB stack + failure to act on earlier similar probes. What would have stopped it: parameterised queries, removing or hardening legacy pages, timely DB patching, and vulnerability monitoring that turns findings into fixes. Lab lesson: your Raja-Rani SQLi fix is the same Blue answer the ICO expected – not a new invention. Source: ICO investigation materials and major UK reporting on the 2015 TalkTalk breach (2015–2016 enforcement); verify current summaries.

Real incident: Log4Shell – Apache Log4j CVE-2021-44228 (2021)

In December 2021, Log4Shell (CVE-2021-44228) in Apache Log4j 2 was publicly disclosed as a critical remote code execution issue: attacker-controlled text that got logged could trigger JNDI lookups and, on vulnerable versions, code execution. CISA and partners issued urgent guidance; NVD scored the issue at the maximum CVSS of 10.0. Weakness: a ubiquitous logging component (A06 – vulnerable and outdated components) trusted inside many Java apps, so patching "our business code" was not enough until Log4j itself was upgraded (and follow-up CVEs required further versions). What would have reduced it: software bill of materials (know what you ship), rapid dependency upgrades, WAF/virtual-patch rules while patching, and outbound controls that limit weird JNDI/LDAP callbacks. Lab lesson: OWASP A06 is not theory – inventory and update libraries the same week you learn them. Source: CVE-2021-44228 / NVD, Apache Log4j security notices, and CISA advisories (2021–2022); verify current summaries.

Interview model (clean English): "I pick one OWASP Top 10 class on my own DVWA or reels lab app, demonstrate the issue with minimal proof, fix it with prepared statements or server-side checks, update components, and re-prove the path is closed."

Thodkyaat: Top-10 olakha, pan fix + re-prove shika. Aata pudhe cloud ani AWS security – EC2, S3, IAM. Chala pudhe, mitrano!

Thodkyaat sangaycha tar

  • OWASP publishes the Top 10 web risks; understand and fix them, do not just memorise names.
  • Injection (A03): SQLi to prepared statements; XSS to output encoding + CSP + HttpOnly; command injection to allow-lists + escapeshellarg().
  • Broken access control (A01)/IDOR: check role and ownership on the server for every request.
  • Authentication (A07): strong passphrases, MFA, lockout, session_regenerate_id; Cryptographic failures (A02): HTTPS, bcrypt, no secrets in code.
  • Also harden design, components, integrity, logging and SSRF – each attack has a concrete defence.
  • Every fix here maps directly to the app you built in Chapters 9–16.

Samjla ka? Web app suraksha cha paya pakka zala. Pudhchya chapter madhe cloud ani AWS security – tumchya EC2, S3, RDS la kase surakshit thevaycha. Chala pudhe, mitrano!