Let me explain a little bit about Web cache before going to the lab.
Let catch the any request.
Sending the request first time. X-cache:miss (can't not find the data in cache)
Sending the request second time. X-cache:hit (find the data in cache)
(The HTTP X-Forwarded-Host header is used to identify the original request made by the client.)
In the request, X-Forwarded-Host include "shengngu.com".
In the response, "shengngu.com" is added with /resources/js/tracking.js
By this way, the attacker can control the response which user received.
Going to the exploit server.
Creating the payload.
Add X-Forwarded-Host: attacker.website
Then send the request twice.
The lab is solveddddddd.
https://viblo.asia/p/web-cache-poisoning-reborn-by-james-kettle-yMnKMMXEK7P
https://viblo.asia/p/web-cache-poisoning-lo-hong-dau-doc-bo-nho-cache-phan-1-018J2M5a4YK
https://viblo.asia/p/web-cache-poisoning-lo-hong-dau-doc-bo-nho-cache-phan-2-EvbLb5koJnk
Dùng extension Param Miner để detect unkeyed values
Varnish Cache
https://viblo.asia/p/web-cache-poisoning-lo-hong-dau-doc-bo-nho-cache-phan-3-EoW4ombkLml
Cache parameter cloaking
Web cache -> XSS
https://viblo.asia/p/web-cache-poisoning-lo-hong-dau-doc-bo-nho-cache-phan-4-zOQJwAY0VMP
Web cache -> DOS
Bởi URL ban đầu đã đạt đến giới hạn ký tự, nên khi chuyển hướng tới /login/?x=very-long-string… có thêm ký tự / đã vượt qua giới hạn, dẫn đến hệ thống không chấp nhận, trả về response lỗi
https://es-la.tenable.com/blog/identifying-web-cache-poisoning-and-web-cache-deception-how-tenable-web-app-scanning-can-help