Add Cache Poisoning Vulnerability

[luks-santos]

Summary

Closes #516.
This PR delivers the full level progression for the Cache Poisoning vulnerability, from the basic route-only cache key issue to the secure implementation, and adds the supporting frontend, hints, i18n, and automated tests
needed for the lab experience.

Implemented levels

• LEVEL_1: reflected banner query parameter is rendered unescaped (also exploitable as stored XSS via the shared cache) while the cache key uses only the route.
• LEVEL_2: naive filtering of the banner parameter does not fix the underlying issue because the cache key is still route-only — alternative unkeyed inputs keep the poisoning viable.
• LEVEL_3: the query parameter is now part of the cache key, but the page remains vulnerable through an unkeyed X-Forwarded-Host header used to build absolute asset URLs.
• LEVEL_4: forwarded host headers are ignored, but personalized cookie-driven content (including derived email and tracked IP) is still cached publicly, demonstrating cross-user PII leakage from a shared cache.
• LEVEL_5: secure variant — ignores untrusted forwarding headers, escapes reflected content, uses a trusted asset host, and returns personalized responses with Cache-Control: private, no-store.

[codecov-commenter]

Codecov Report

❌ Patch coverage is 92.48120% with 10 lines in your changes missing coverage. Please review.
✅ Project coverage is 53.12%. Comparing base (45d14fc) to head (4178173).
⚠️ Report is 17 commits behind head on master.

Files with missing lines	Patch %	Lines
...ty/cachePoisoning/CachePoisoningVulnerability.java	95.00%	3 Missing and 3 partials ⚠️
...e/vulnerability/cachePoisoning/CachedResponse.java	63.63%	3 Missing and 1 partial ⚠️

Additional details and impacted files

@@             Coverage Diff              @@
##             master     #534      +/-   ##
============================================
+ Coverage     52.01%   53.12%   +1.10%     
- Complexity      465      510      +45     
============================================
  Files            69       72       +3     
  Lines          2676     2850     +174     
  Branches        285      296      +11     
============================================
+ Hits           1392     1514     +122     
- Misses         1153     1201      +48     
- Partials        131      135       +4     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[preetkaran20]

@luks-santos I must say this is amazing code change. Very thorough PR. I really liked the PR completeness. I have added small comments, can you please address?

[luks-santos]

@preetkaran20 Thanks a lot for the feedback!
I’ll review your comments and make the updates

[luks-santos]

Hi @preetkaran20

I've pushed the changes addressing the feedback. Summary of what was implemented:

Frontend / UX

• Moved level-specific templates into a common directory to reduce duplication (230afec).
• Refactored levels 1–5 to reuse doGetAjaxCall and pass xhr to callbacks (6049137).
• Added a "reset cache" button on every level so the lab is reproducible without restarting (3bae76d).

Vulnerability depth

• Made Level 1 exploitable as XSS through the poisoned cached response (179777a).
• Exposed multiple attack vectors per level with matching hints/payloads (5afcb79, f0f30a9).
• Enriched Level 4 PII leak (derived email + tracked IP) and tightened the overall lab (447b47c).
• Improved Level 3 visualization and fixed the simulation (ba62756, 2673d64).

The PR description has been updated to reflect the final scope. Let me know if there's anything else you'd like me to adjust!

[preetkaran20]

Overall, @luks-santos this is really a great PR. I have added a few comments, I think once they are resolved, i think we can merge it quickly. Just a few thoughts on browser side caching issues which we need to work on.

[luks-santos]

Hi @preetkaran20,

I've pushed the changes addressing the feedback. Here's a principal summary of what was implemented:

Cache reset reliability

• Moved cache clearing into a single POST /clearCache?level=<level> endpoint. This ensures that resetting one level no longer flushes the entire shared cache, each reset now evicts only entries for the targeted level (5d02696).

Browser cache toggle (Levels 1–4)

• Added a Browser cache checkbox to the Controls block on each vulnerable level (4178173).

• When OFF, the server emits:

  Cache-Control: public, s-maxage=60, max-age=0
  

  instead of:

  Cache-Control: public, max-age=60
  

This ensures the browser always revalidates while the shared cache layer (the one being poisoned) keeps its 60-second TTL.

• I think s-maxage directive preserves scanner detection.

• Level 5 (secure variant) remains unchanged.

---

Let me know if there's anything else you'd like me to adjust!

I've opened the PR at SasanLabs/VulnerableApp-facade#112

[preetkaran20]

Amazing job @luks-santos One of the best change.

[preetkaran20]

Merged the PR @luks-santos Amazing work!!!!!

[preetkaran20]

🎉 Thanks for contributing @luks-santos!
We’d love to stay in touch and grow SasanLabs 🚀
👉 Please fill this (takes 30 sec):
https://docs.google.com/forms/d/e/1FAIpQLSfwWVdnULUhtfruA-DN328NwKnBGebaWg9U5y0xivLLxxoMog/viewform?usp=pp_url&entry.1414771947=luks-santos

Also consider ⭐ starring the repo if you like it!

🎯 Want to keep going? Here's a good next issue for you:
👉 #497 - Add NOSQL Injection vulnerability.

[preetkaran20]

@all-contributors please add @luks-santos for code

[allcontributors]

@preetkaran20

I've put up a pull request to add @luks-santos! 🎉