Unit 7: Web Application Security
Lesson at a glance
| Item | Detail | | --------------------- | -------------------------------------------------------------------------------- | | Suggested length | 6 × 60 minutes | | Recommended placement | Weeks 10–11 | | Prerequisite | Units 1–6; signed advanced RoE | | Materials | Burp Suite Community, OWASP Juice Shop (lab instance), DVWA, Firefox + FoxyProxy |
Safety: All web testing targets the lab Juice Shop and DVWA instances only. Public web applications, school portals, employer apps, and "sites I found" are off-limits. Payloads in this guide are lab-only proofs of concept. Stop at documented PoC. Do not pivot, do not persist, do not reuse a payload outside this range.
Standards & credential alignment
- OWASP Top 10 (2021) - full coverage.
- OffSec PEN-100 web fundamentals.
- EHE - web application hacking domain.
Learning objectives
By the end of this unit, students can:
- Configure Burp Suite as an HTTP proxy and read intercepted traffic.
- Recognize and demonstrate the OWASP Top 10 (2021) at PoC level.
- Use Burp Repeater + Intruder for authorized testing.
- Articulate secure-coding mitigations for each Top 10 category.
- Produce a 6–10 page web application assessment report.
OWASP Top 10 (2021)
- A01 Broken Access Control
- A02 Cryptographic Failures
- A03 Injection (SQLi, command, etc.)
- A04 Insecure Design
- A05 Security Misconfiguration
- A06 Vulnerable & Outdated Components
- A07 Identification & Authentication Failures
- A08 Software & Data Integrity Failures
- A09 Security Logging & Monitoring Failures
- A10 Server-Side Request Forgery (SSRF)
Pacing
| Day | Focus | Deliverable | | --- | ------------------------------------------- | ------------------------------ | | 1 | Burp setup + HTTP fundamentals | Successful intercepted request | | 2 | A01 Broken Access Control + A07 Auth | IDOR + auth bypass demo | | 3 | A03 Injection: SQLi + command | SQLi PoC with screenshot | | 4 | XSS (under Injection) + CSRF | Reflected + stored XSS PoC | | 5 | A05/A06/A09: misconfig + outdated + logging | Three findings | | 6 | Report write-up | Web assessment report |
Day 1 - Burp setup
- Launch Burp Community.
- Set Firefox proxy to
127.0.0.1:8080(use FoxyProxy). - Install Burp's CA cert in Firefox so HTTPS works.
- Navigate Juice Shop. Watch the traffic in Proxy → HTTP history.
- Send a request to Repeater. Modify a header. Re-send. Observe.
Day 2 - Access control + auth
A01 IDOR:
- In Juice Shop, log in as user A.
- Find a request that fetches user A's data (e.g., basket).
- Change user ID to user B.
- Observe the response. Document.
A07 Authentication bypass:
- Try
' OR 1=1 --style on the admin login (legacy lab only). - Observe. Document.
Day 3 - Injection
SQL Injection (Juice Shop search):
qwert' UNION SELECT id, email, password, '4', '5', '6', '7', '8', '9' FROM Users--
Capture the response. Document. Stop at PoC.
Command Injection (DVWA low/medium):
- The classic
127.0.0.1; whoamiin the ping form. - Document.
Day 4 - XSS + CSRF
Reflected XSS (Juice Shop search):
<iframe src="javascript:alert('xss')">
Stored XSS (Juice Shop feedback or comments):
- Inject a payload that fires for any subsequent visitor (use a benign
alert). - Document scope: who would see this? What's the impact in a real app?
CSRF concept:
- Show a sample HTML form on a third-party site that submits to a vulnerable endpoint.
- Discuss SameSite cookies, CSRF tokens, double-submit cookies.
Day 5 - Misconfig / outdated / logging
- A05 Misconfiguration: directory listing, default creds, verbose errors. Find one in DVWA.
- A06 Vulnerable components: check
package.jsonof a sample app, runnpm audit. Discuss SCA (Software Composition Analysis). - A09 Logging failures: simulate. Show what you'd want logged for the SQLi from Day 3 and what most apps actually log. The gap is the finding.
Day 6 - Report
Template:
# Web Application Security Assessment - OWASP Juice Shop (lab)
## Executive Summary
## Scope + Authorization
## Methodology + Tools
## Findings (6+ findings, sorted by severity)
Each: Title / OWASP category / CVSS / Description / Evidence / PoC steps / Impact / Remediation / References
## Defensive Recommendations (executive view)
## Appendix
Secure-coding mitigations cheat sheet
| Vulnerability | Primary fix | | ------------------- | -------------------------------------------------------- | | SQLi | Parameterized queries / prepared statements | | XSS | Context-aware output encoding + CSP | | CSRF | CSRF tokens + SameSite cookies | | IDOR | Server-side authorization on every object access | | Broken auth | Password policy + MFA + session management + lockout | | Misconfig | Hardened baselines, no defaults, automated config audits | | Outdated components | SCA in CI/CD, patch policy | | Logging | Centralized logs, minimum required event set, alerting | | SSRF | Allow-list outbound, deny metadata IPs, URL validation |
Teacher background (read this before the lesson)
This is the unit a district lawyer will screenshot. Teach it that way.
The payloads in Days 2–4 are authorized demonstrations against this Juice Shop and this DVWA, on these dates, under the signed advanced RoE. They are not homework to try on anything else. If a learner asks "could I try this on our portal," the answer is the three-question test out loud, then no.
Lab-only legal framing (read aloud on Day 1 before Burp opens):
- Target list is written: Juice Shop URL and DVWA URL posted on the board.
- Technique is authorized: intercept, repeat, inject, document.
- Impact is capped: benign
alert, data shown in-lab, no persistence, no account lockouts on shared lab users if you can avoid them. - Evidence is for the report, not for social media.
- Unexpected behavior = stop, snapshot, call the instructor.
Walk the room during injection days. The student who is "just checking one more parameter" on a hostname that is not on the board is your private conversation.
Materials checklist
- [ ] Burp Suite Community installed; Firefox + FoxyProxy profile documented
- [ ] Lab Juice Shop URL and DVWA URL posted (and nowhere else)
- [ ] Burp CA install steps printed for the first 10 minutes of Day 1
- [ ] Report template from Day 6 copied into the engagement folder
- [ ] Signed advanced RoE confirmed on file for every learner in the room
Differentiation, IEP, and 504 supports
- Reading / working memory: Provide the SQLi and XSS payloads on a printed card so learners are not improvising strings from memory.
- Processing time: Days 2–4 can be "one finding done well" instead of every Top 10 item; the report still requires six findings if they use teacher-provided evidence packs for the rest.
- Motor / UI load: Pair for Burp; operator clicks, recorder writes reproduction steps as they happen.
- Anxiety / legal worry: Restate the target list at the start of every lab day. Anxiety here is appropriate; channel it into the RoE, not into skipping the lab.
Common misconceptions
- "I tested it once and it worked → vulnerable." - Re-test with fresh browser session, no cache, different account. Document reliability.
- "XSS is harmless because it's just an alert." -
alert()is the PoC. Real impact is session theft, account takeover, defacement. - "WAF makes it safe." - WAFs reduce noise; they do not replace fixing the vuln.
- "If the payload is in the curriculum, I can use it anywhere." - Curriculum authorization is for the lab instance. Same string against a real site is a different legal fact.
Assessment
Daily PoC screenshots must include URL bar (lab host visible), request/response, and a one-line impact statement.
Day 6 report rubric (1–4 each): scope/authorization stated, six findings with evidence, reproduction a junior engineer could follow, remediations specific (not "sanitize input"), executive summary in plain language.
Career connection
Application security is the work of people who can demonstrate a flaw and then explain the fix in language a developer will implement. The report is the product. The payload is only the proof.
Homework
Read OWASP ASVS Level 1 introduction (V1 and V5). Pick one verification requirement and write five test steps you would run against the lab Juice Shop — not against a live site.