Week: 6 Graded: Yes Time estimate: 75-90 minutes Tools: OWASP Juice Shop (Docker); browser; browser developer tools
Learning objective
Complete at least four broken-authentication challenges in OWASP Juice Shop. Document each technique and the underlying vulnerability class. (Bloom's L3: Apply -- exploit broken-auth patterns in a controlled, authorized environment; L2: Understand -- explain why each technique works and what the correct defense is.)
Setup
Install and run OWASP Juice Shop
Juice Shop requires Docker. If you completed FND-102, Docker is already installed.
docker pull bkimminich/juice-shop
docker run -p 3000:3000 bkimminich/juice-shop
Open http://localhost:3000 in your browser. You should see the Juice Shop storefront.
Note: If Docker is not available, ask your instructor for a hosted Juice Shop URL for your cohort, or install via Node.js: npm install -g juice-shop && juice-shop.
Note: Juice Shop tracks your progress automatically (using localStorage). If you restart the container, progress is reset unless you use the score board URL to see what you've already done.
Find the score board
In Juice Shop, browse to http://localhost:3000/#/score-board. This page (a hidden challenge in itself) lists all challenges by category and difficulty. Find the "Broken Authentication" category.
Step-by-step instructions
Complete at least four of the challenges in the Broken Authentication and Session Management categories. Required challenges are marked; choose your remaining challenges from the list.
Challenge 1 (Required): Login as admin (password reset / default credential bypass)
Find a way to log in as the administrator without knowing the admin's password.
Approaches to try:
- Inspect the login form in browser developer tools. Is there anything unusual in the request?
- Try common admin email addresses and passwords.
- Look at Juice Shop's error messages: do they reveal whether an email address exists in the system?
Document in your lab notebook: what technique worked? What vulnerability class does this represent? What would the developer need to change to prevent it?
Challenge 2 (Required): Reset Jim's password
Jim's email is jim@juice-sh.op. Use the password reset flow to reset his password without knowing his current password.
Look at the security question asked during the reset. Is the answer publicly discoverable? (The security question may hint at a famous fictional character's name; look for references in Juice Shop's product listings and reviews.)
Document: what information was needed? What category of authentication failure is this?
Challenge 3 (Required): Access someone else's basket
Browse your own basket (once logged in). Notice the URL or request parameters. Is there a user ID in the request? Try modifying it.
Document: which OWASP category (Broken Authentication, Broken Access Control, or both) does this represent? What is the specific failure (IDOR, missing server-side check, etc.)?
Challenge 4 (Required): Forged feedback (optional, recommended)
Find a way to post product feedback as a different user (or as an unauthenticated user in a way that bypasses the intended authentication requirement).
Hint: Look at the feedback submission request in browser developer tools. Is the user ID included in the request body, or is it set server-side from the session?
Document: is this an authentication failure or an authorization failure? What is the difference in this context?
Additional challenges (choose any two from the Broken Authentication / Session Management section of the score board)
Choose two more challenges from the Broken Authentication category in the score board. For each, document:
- Challenge name and description.
- Technique used (what you did, step by step).
- Vulnerability class (which OWASP Top 10 category and sub-type).
- The correct defense (what the developer should have done).
Deliverable
A lab report covering all four required challenges plus your two additional challenges. For each challenge:
- What you found (the vulnerability).
- What you did (the technique, step by step).
- Why it worked (the underlying vulnerability class).
- What the correct fix is.
Total length: 500-800 words plus any screenshots you include.
Grading rubric
| Criterion | Points | Notes |
|---|---|---|
| Challenge 1: technique documented with vulnerability class | 20 | "I guessed the password" without naming the vulnerability class does not score full marks |
| Challenge 2: technique documented; social engineering / predictable answer identified | 20 | Must explain why security questions are weak authentication factors |
| Challenge 3: IDOR technique documented; server-side check failure identified | 20 | Must distinguish authentication from authorization failure |
| Challenge 4: authentication vs. authorization distinction articulated | 15 | The distinction is the grading criterion |
| Additional challenges: both documented with technique + fix | 25 | 12-13 points each |
| Total | 100 |
Important note on scope
This lab is authorized against the OWASP Juice Shop instance running on your own machine (localhost:3000) or against an instructor-provided hosted URL.
Do not apply any of these techniques against real websites, other students' machines, or any system you do not own or have explicit authorization to test. The Juice Shop instance is deliberately vulnerable for educational purposes; real applications are not.
picoCTF connection
The picoCTF Web Exploitation category includes challenges involving cookies, authentication bypass, and session token manipulation. The browser developer tools skills you used in this lab (inspecting HTTP requests, modifying cookies, reading response headers) are directly applicable. If you get stuck on a picoCTF Web Exploitation challenge, open the browser developer tools, go to the Network tab, and replay the request to see what parameters are being sent. Forward pointer: Juice Shop's SQL injection challenges in Lab 7 reinforce picoCTF's injection-category challenges.
Lab 5 of 9. Next: Lab 6 (Full STRIDE threat model, Week 3 content, deliverable this week).