owned this note
owned this note
Published
Linked with GitHub
# Portswigger Web Cache Poisoning 🥶
<style>body {text-align: justify}</style>
Hi, dưới đây là writeup của 13/13 bài lab về lỗ hổng [Web Cache Poisoning](https://portswigger.net/web-security/web-cache-poisoning) mình đã solve trong quá trình ôn tập thi chứng chỉ của Portswigger.
### 1. Web cache poisoning with an unkeyed header
##### Description
> This lab is vulnerable to web cache poisoning because it handles input from an unkeyed header in an unsafe way. An unsuspecting user regularly visits the site's home page. To solve this lab, poison the cache with a response that executes `alert(document.cookie)` in the visitor's browser.
##### Writeup
Dùng Param Miner scan thì thấy [X-Forwarded-Host](https://stackoverflow.com/questions/19084340/real-life-usage-of-the-x-forwarded-host-header) bị unkeyed bởi cache.
Ngoài ra value của header X-Forwarded-Host được thêm vào `src` của tag script.
Dựa vào đó, gửi request với X-Forwarded-Host có giá trị như sau:
`abc.com"></script><script>alert(document.cookie);</script>`
Gửi đến khi `X-Cache: hit`.
Show response thấy alert thành công.
Khi victim truy cập trang chủ cũng sẽ bị alert do nhận response từ cache. Ta solve thành công challenge.
### 2. Web cache poisoning with an unkeyed cookie
##### Description
> This lab is vulnerable to web cache poisoning because cookies aren't included in the cache key. An unsuspecting user regularly visits the site's home page. To solve this lab, poison the cache with a response that executes `alert(1)` in the visitor's browser
##### Writeup
Ứng dụng này không include cookie vào cache keys. Trong đó có cookie `fehost` được chèn trực tiếp giá trị vào script.
Thực hiện gửi request với cookie `fehost=abc` kèm theo cache buster bằng `?abc=1`, ta thấy chuỗi `abc` đã được thêm vào script.
Gửi thêm đến khi `X-Cache: hit`.
Lúc này khi query đến `/?abc=1` mà không chứa cookie `fehost` thì mình vẫn nhận được cached response giống với response ở trên.
Bây giờ, xóa cache buster và gửi request với `fehost=abc"-alert(1)-"abc` để inject XSS.
Gửi thêm đến khi `X-Cache: hit`.
Show response thử thì ta thấy alert thành công.
Lúc này victim truy cập trang chủ và nhận được cached response chứa XSS payload → ta solve được challenge.
### 3. Web cache poisoning with multiple headers
##### Description
> This lab contains a web cache poisoning vulnerability that is only exploitable when you use multiple headers to craft a malicious request. A user visits the home page roughly once a minute. To solve this lab, poison the cache with a response that executes `alert(document.cookie)` in the visitor's browser.
##### Writeup
Sử dụng Param Miner ta thấy cache unkey header `X-Forwared-Scheme`.
Sử dụng cache buster `?abcd=1` và test thử với `X-Forwared-Scheme: https` thì thấy vẫn nhận response bình thường.
Tuy nhiên khi gửi `X-Forwared-Scheme` khác `https` thì sẽ được trả về 302 và redirect về `https`.
Tận dụng thêm 1 unkeyed header `X-Forwarded-Host` kết hợp với `X-Forwared-Scheme` khác `https`, ta có thể redirect user về đường dẫn `https://<X-Forwarded-Host>/?abcd=1`.
Như vậy ta chỉ cần tạo exploit server chứa đoạn script XSS về truyền địa chỉ vào `X-Forwarded-Host`, ta sẽ trigger được XSS.
Tuy nhiên exploit server không cho phép thiết lập như vậy tại `/`. Ta phải tìm endpoint khác. Để ý rằng khi load trang chủ ứng dụng thì sẽ có request đến `/resources/js/tracking.js`. Đường dẫn này cũng được cached (dựa vào `X-Cache`).
Do đó ta sẽ tạo exploit server với đường dẫn tương tự nhưng chứa XSS payload.
Thực hiện các bước chèn:
- X-Forwarded-Host: `<EXPLOIT-SERVER>`
- X-Forwarded-Scheme: khác HTTPS
và gửi request đến `/resources/js/tracking.js`, ta redirect được user về exploit-server chứa XSS payload. Gửi request đến khi được cached.
Do các header trên không được keyed nên victim truy cập trang chủ → load đường dẫn trên → được nhận cached response → bị XSS.
Như vậy ta solve được challenge.
### 4. Targeted web cache poisoning using an unknown header
##### Description
> This lab is vulnerable to web cache poisoning. A victim user will view any comments that you post. To solve this lab, you need to poison the cache with a response that executes `alert(document.cookie)` in the visitor's browser. However, you also need to make sure that the response is served to the specific subset of users to which the intended victim belongs.
##### Writeup
Param Miner chỉ ra cache của ứng dụng ignore `X-Host` header.
Ngoài ra, giá trị của `X-Host` được chèn vào `src` của tag script.
Như vậy ta đã xác định được unkeyed header và ta có thể chèn XSS payload ở đó.
Ứng dụng còn cho biết `User-Agent` là 1 cache key nhờ vào header `Vary` tại response. Bây giờ ta chỉ cần đi tìm `User-Agent` của nạn nhân để thực hiện web cache poisoning với chỉ user này thôi.
Ta thấy các bài post có chức năng comment với comment có thể là HTML code.
Bây giờ ta chỉ cần chèn payload sau để khi victim xem comment thì sẽ request đến exploit-server: `<img src="https://<EXPLOIT-SERVER>">`.
Sau khi comment và đợi 1 chút, check log của exploit server ta thấy request từ victim chứa `User-Agent`.
Lấy `User-Agent` đó kèm theo `X-Host` là XSS payload, ta đã có thể poison cache thành công với victim đã xác định. Nhớ là phải gửi đến khi `X-Cache: hit`.
Như vậy ta solve được challenge.
### 5. Web cache poisoning via an unkeyed query string
##### Description
> This lab is vulnerable to web cache poisoning because the query string is unkeyed. A user regularly visits this site's home page using Chrome. To solve the lab, poison the home page with a response that executes `alert(1)` in the victim's browser.
##### Writeup
Gửi request đến `/` với query string `abc=1` thì thấy cả URL chứa query string được gán vào `href` của link canonical → có thể XSS. Ngoài ra, khi ta thay đổi query string thì `X-Cache: hit` chứng tỏ query string không thuộc cache keys.
Khi đó ta sẽ không thể dùng cache buster trên param. Thử nghiệm ta thấy sử dụng cache buster tại header Origin thành công khi server trả về `X-Cache: miss` → Origin là 1 cache key. Gửi thêm với param `abc=1` cho đến khi chứng tỏ mình nhận được response từ cache (`X-Cache: hit`).
Lúc này truy cập `/` với cùng cache buster ta thấy param `abc=1` vẫn tồn tại trong link canonical.
Tương tự các bước trên ta thử param là XSS payload như dưới. Gửi với cache buster cho đến khi `X-Cache: hit`.
Truy cập `/` với cùng cache buster ta thấy payload XSS vẫn được load thành công. → Ta đã poison cache thành công.
Bây giờ chỉ việc gửi XSS payload qua query string tương tự ở trên cho đến khi `X-Cache: hit`.
Đợi victim truy cập `/` và ta solve được challenge.
### 6. Web cache poisoning via an unkeyed query parameter
##### Description
> This lab is vulnerable to web cache poisoning because it excludes a certain parameter from the cache key. A user regularly visits this site's home page using Chrome.
>
> To solve the lab, poison the cache with a response that executes `alert(1)` in the victim's browser.
**Chú ý:** UTM params thông thường bị ignore bởi cache.
##### Writeup
Tương tự bài trên, ta dùng cache buster tại Origin header. Thử gửi request với các param `abcd=2` và `utm_content=1` cho đến khi `X-Cache:hit`. Để ý ta có thể XSS tại canonical link.
Xóa param `utm_content=1` đi và gửi lại request với cùng cache buster ta thấy nhận được response giống trên → cache key không chứa param `utm_content`.
Bắt đầu tấn công XSS bằng cách gửi request đến `/` với param `utm_content=<XSS payload>` (nhớ xóa cache buster) cho đến khi `X-Cache:hit`.
Xóa param `utm_content=<XSS payload>` đi và send lại request ta thấy XSS payload vẫn được load thành công.
Victim chắc chắn bị dính XSS khi truy cập cache version của trang chủ → ta solve được challenge.
### 7. Parameter cloaking
##### Description
> This lab is vulnerable to web cache poisoning because it excludes a certain parameter from the cache key. There is also inconsistent parameter parsing between the cache and the back-end. A user regularly visits this site's home page using Chrome.
>
> To solve the lab, use the parameter cloaking technique to poison the cache with a response that executes alert(1) in the victim's browser.
##### Writeup
Mỗi khi load trang chủ thì một hàm `setCountryCookie()` được thực thi từ file `/js/geolocate.js` bằng tham số `callback`.
Sử dụng cache buster tại Origin header. Gửi request đến khi `X-Cache: Hit`.
Sử dụng cùng cache buster, ta thấy UTM params bị unkeyed bởi cache.
Sử dụng kĩ thuật parameter cloaking với tham số callback với payload sau:
```
/js/geolocate.js?callback=setCountryCookie&utm_content=1;callback=alert(1)
```
Gửi lần đầu ta thấy, hàm `alert(1)` đã được gọi → Server chấp nhận tham số `callback=alert(1)` cuối cùng chứ không phải `callback=setCountryCookie`.
Gửi đến khi `X-Cache: Hit`.
Đối với cache, khi query cùng cache buster với mỗi param `callback=setCountryCookie` thì được trả về cache version của request trên chứa `alert(1)` → nó ignore luôn `utm_content=1;callback=alert(1)` vì nó coi đây chỉ là 1 tham số `utm_content`.
Bây giờ xóa cache buster và sử dụng parameter cloaking payload ở trên.
Load lại đường dẫn `/js/geolocate.js?callback=setCountryCookie` ta thấy alert(1) được gọi.
Victim sẽ bị dính `alert(1)` khi load trang chủ → ta solve được challenge.
### 8. Web cache poisoning via a fat GET request
##### Description
> This lab is vulnerable to web cache poisoning. It accepts GET requests that have a body, but does not include the body in the cache key. A user regularly visits this site's home page using Chrome.
>
> To solve the lab, poison the cache with a response that executes `alert(1)` in the victim's browser.
##### Writeup
Tương tự bài trên ta sẽ nhắm đến tham số `callback` tại `/js/geolocate.js`. Gửi param `callback=alert(1)` dưới body với method GET và cache buster tại Origin header thì thấy hàm `alert(1)` đã được gọi. → ứng dụng chấp nhận GET requests có chứa body. (Gửi cho đến khi `X-Cache: hit`)
Xóa body và gửi request với cùng cache buster ta thấy hàm `alert(1)` vẫn được gọi → poison thành công.
Xóa cache buster và gửi request với body `callback=alert(1)` cho đến khi `X-Cache: hit` để poison cache.
Khi đó victim sẽ bị dính `alert(1)` khi load trang chủ → ta solve được challenge.
### 9. URL normalization
##### Description
> This lab contains an XSS vulnerability that is not directly exploitable due to browser URL-encoding.
>
> To solve the lab, take advantage of the cache's normalization process to exploit this vulnerability. Find the XSS vulnerability and inject a payload that will execute alert(1) in the victim's browser. Then, deliver the malicious URL to the victim.
##### Writeup
Khi truy cập 1 đường dẫn không tồn tại, trang web reflect lại đường dẫn đó ra output → nhìn có vẻ reflected XSS.
Escape tag `<p>` và thêm XSS payload vào đường dẫn như hình dưới, ta thấy alert(1) đã được thực thi.
Tuy nhiên có 1 điều, khi mình truy cập đường dẫn này trên URL thì bị fail do browser đã url-encode payload trên rồi mới gửi server. Do đó, mình cần kết hợp lỗi của cache trong việc nomarlize URL để có thể khiến nạn nhân truy cập đường dẫn trên URL mà vẫn bị dính XSS.
Cách làm như sau:
- Gửi lại request tấn công giống lúc nãy cho đến khi `X-Cache:hit`, tức là response đã được cached chứa unencoded XSS payload.
- Lập tức truy cập lại đường dẫn trên URL, ta XSS thành công.
Giải thích:
- Khi attacker gửi XSS payload qua Repeater thì không bị URL-encoded bởi proxy → server xử lí bình thường và lưu vào cache.
- Khi nạn nhân truy cập malicious URL trên browser, browser sẽ URL-encode nó, nhưng khi qua bước URL normalization của cache, cache hiểu là cùng cache keys → trả về response giống như response chứa unencoded payload của attacker → bị XSS.
Như vậy, ta solve được challenge.
### 10. Cache key injection
##### Description
> This lab contains multiple independent vulnerabilities, including cache key injection. A user regularly visits this site's home page using Chrome.
>
> To solve the lab, combine the vulnerabilities to execute `alert(1)` in the victim's browser. Note that you will need to make use of the `Pragma: x-get-cache-key` header in order to solve this lab.
##### Writeup
Khi truy cập trang chủ, ứng dụng redirect user từ `/login?lang=en` về `/login/?lang=en`. Để ý, `/login?lang=en` sẽ có cache. Như vậy, để nạn nhân bị tấn công, ta cần gửi request sao cho match với cache key `/login?lang=en`.
Mặt khác, `utm-content` bị ignore bởi cache nên ta có thể dùng param này để bắt đầu poison.
Sau khi redirect, trang web import 1 file js tại `/js/localize.js?lang=en&cors=0` → tham số `lang` ở đây được lấy từ URL. Request này cũng có cache hỗ trợ.
Lúc này mình nảy ra ý tưởng rằng: mình sẽ cố gắng poison cache tại `/js/localize.js?lang=en&cors=0` rồi quay lại poison cache `/login?lang=en` sao cho ứng dụng load response `/js/localize.js?lang=en&cors=0` sau khi đã bị poisoned.
- Poison cache tại `/js/localize.js?lang=en&cors=0`:
`utm_content` cũng bị ignore bởi cache trong khi Origin là 1 cache key.
Thay đổi `cors=1` thì thấy mình có thể header injection khi server trả về `Access-Control-Allow-Origin` chứa giá trị chính là giá trị mình truyền ở header Origin.
Gửi request như sau để header injection thông header `Origin` trả về `alert(1)` với `Content-Length: 8`. Lý do để tham số `x=1` mình sẽ giải thích sau. Chú ý, đây chính là bước poison nên cần gửi cho đến khi `X-Cache: hit`.
Sau khi đọc `X-Cache-Key`, mình có thể request lại như sau để có cùng cache key mà không can thiệp vào Origin. Mục đích của việc này là để victim truy cập vào.
Lúc này để ý, `x=1` được dùng để tránh khiến `cors=1$$origin...` → không thể header injection.
- Poison cache tại `/login?lang=en`:
Tại `/login?lang=en`, ta thực hiện truyền tham số như dưới vf gửi request đến khi `X-Cache: hit`. Khi đó ta đạt được 2 mục đích:
- Cache sẽ ignore `utm_content` và chỉ chứa cache key là `/login?lang=en` → match với request nạn nhân truy cập
- Trang chủ sẽ import file js `/js/localize.js` với đường dẫn như sau:
Như đã phân tích ở trên, đường dẫn này match cache key với request poison nên nó sẽ trả về `alert(1)`. Chú ý ở đây dùng `%23 (#)` ở cuối để "cắt" `&cors=0`.
Bây giờ nạn nhân truy cập trang chủ sẽ bị dính `alert(1)`.
### 11. Internal cache poisoning
##### Description
> This lab is vulnerable to web cache poisoning. It uses multiple layers of caching. A user regularly visits this site's home page using Chrome.
>
> To solve the lab, poison the internal cache so that the home page executes `alert(document.cookie)` in the victim's browser.
##### Writeup
Dùng Param Miner thấy X-Forwarded-Host được hỗ trợ bởi ứng dụng.
Gửi request với `X-Forwarded-Host: abc` kèm theo dynamic cache buster (dùng Param Miner), ta thấy link canonical và địa chỉ load `analytics.js` đều trỏ về `//abc`, trong khi địa chỉ load `geolocate.js` vẫn giữ nguyên như ban đầu.
Tuy nhiên, gửi thêm vài lần thì thấy địa chỉ load `geolocate.js` cũng đã trỏ về `//abc`. → fragment này được cache bởi internal cache; và query string bị unkeyed bởi internal cache do ta vẫn hit cache mặc dù cache buster tại query string thay đổi.
Xóa `X-Forwarded-Host: abc` và gửi lại request, ta thấy địa chỉ load `geolocate.js` vẫn trỏ về `//abc` còn 2 cái kia thì không → `X-Forwarded-Host` unkeyed bởi internal cache nhưng là keyed đối với external cache.
Bây giờ chỉ việc tạo file `/js/geolocate.js` chứa `alert(document.cookie)`.
Nhét exploit-server domain vào `X-Forwarded-Host` và gửi cho đến khi hostname load file `/js/geolocate.js` trở thành exploit-server.
Xóa `X-Forwarded-Host`, ta thấy hostname load file `/js/geolocate.js` vẫn là exploit-server.
Lúc này nạn nhân truy cập trang chủ sẽ load `/js/geolocate.js` của exploit-server và bị alert → Ta solve thành công.
### 12. Web cache poisoning to exploit a DOM vulnerability via a cache with strict cacheability criteria
##### Description
> This lab contains a DOM-based vulnerability that can be exploited as part of a web cache poisoning attack. A user visits the home page roughly once a minute. Note that the cache used by this lab has stricter criteria for deciding which responses are cacheable, so you will need to study the cache behavior closely.
>
> To solve the lab, poison the cache with a response that executes `alert(document.cookie)` in the visitor's browser.
##### Writeup
Ứng dụng support `X-Forwarded-Host`.
và giá trị của nó được gán vào `data.host`.
Sau đó, hàm `initGeoLocate()` được gọi với tham số `//data.host/resources/json/geolocate.json` attacker có thể control được.
Hàm `initGeoLocate()` bị dính DOM-XSS khi sau khi lấy lấy response về từ jsonUrl, nó thực hiện parse JSON và lấy `j.country` đưa vào sink innerHTML để render.
→ Tạo exploit-server với đường dẫn `/resources/json/geolocate.json` chứa nội dung:
```json
{
"country": "<img src=1 onerror=alert(document.cookie) />"
}
```
Nhớ thêm `Access-Control-Allow-Origin: *` để support CORS.
Bây giờ chỉ việc poison cache với header `X-Forwarded-Host: <Exploit-server>`. Chú ý, cache chỉ cache với các request có cookie vì khi không có cookie, server trả về set-cookie → nếu cache thì có thể các user có thể nhận được cache response → chung cookie.
Gửi request cho đến khi cache hit. Victim truy cập trang chủ sẽ bị dính DOM-XSS. Ta solve được challenge.
---
## Notes
Web cache poisoning is an advanced technique whereby an attacker exploits the behavior of a web server and cache so that a harmful HTTP response is served to other users.
***Cache keys***: is used to identify equivalent requests to serve cache
- This would contain the request line and `Host` header
- **Ignore "unkeyed"** components which are **not** included in cache keys.
Generally speaking, constructing a *basic web cache poisoning attack* involves the following steps:
- Identify and evaluate **unkeyed** inputs
- Elicit a harmful response from the back-end server
- Get the response cached
**Detect:**
- Cache design flaw: ignore unkeyed
- Cache key flaw:
- Excluding the query string
- Filtering out specific query parameters
- Normalizing input in keyed components
**Countermeasures:**
- Do not use cache
- Don't accept fat GET requests
- Rewrite the request when excluding sth from cache keys
- Patch client-side vulns even if it's unexploitable.
###### tags: `portswigger`, `web-cache-poisoning`, `advanced`
Google Drive
Gist
Clipboard
Sign in with Wallet
