GitBook: [#3302] No subject

pentesting-web/xs-search.md

@@ -374,7 +374,7 @@ This could also be done with a Timing attack (check the paper for more info).
 * **Detectable Difference**: Timing
 * **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources)
 * **Summary:** Detect if a resource was stored in the cache.
-* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources)
+* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources), [https://xsinator.com/testing.html#Cache%20Leak%20(POST)](https://xsinator.com/testing.html#Cache%20Leak%20\(POST\))
 
 Using the [Performance API](xs-search.md#performance-api) it's possible to check if a resource is cached.\
 For more info: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources)
@@ -476,7 +476,7 @@ Modern browsers won't indicate the URL it was redirected to, but you can still d
 * **Summary:** Clear the file from the cache. Opens target page checks if the file is present in the cache.
 * **Code Example:** 
 
-Most browsers use one shared cache for all websites. Regardless of their origin, it is possible to deduct whether a target page has **requested a specific file**.
+Browsers might use one shared cache for all websites. Regardless of their origin, it is possible to deduct whether a target page has **requested a specific file**.
 
 If a page loads an image only if the user is logged in, you can **invalidate** the **resource** (so it's no longer cached if it was, see more info links), **perform a request** that could load that resource and try to load the resource **with a bad request** (e.g. using an overlong referer header). If the resource load **didn't trigger any error**, it's because it was **cached**.
 
@@ -557,6 +557,9 @@ Web applications can deploy COOP response header to prevent other websites from
 
 If a server-side redirect uses **user input inside the redirection** and **extra data**. It's possible to detect this behaviour because usually **servers** has a **limit request length**. If the **user data** is that **length - 1**, because the **redirect** is using **that data** and **adding** something **extra**, it will trigger an **error detectable via Error Events**.
 
+If you can somehow set cookies to a user, you can also perform this attack by **setting enough cookies** ([**cookie bomb**](hacking-with-cookies/cookie-bomb.md)) so with the **response increased size** of the **correct response** an **error** is triggered. In this case, remember that is you trigger this request from a same site, `<script>`  will automatically send the cookies (so you can check for errors).\
+An example of the **cookie bomb + XS-Search** can be found in the Intended solution of this writeup: [https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/#intended)
+
 ### Max Redirects
 
 * **Inclusion Methods**: Fetch API, Frames
@@ -673,7 +676,12 @@ Same technique as the previous one but using `window.open` instead of iframes.
 * **Detectable Difference**: Timing
 * **More info**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass)
 * **Summary:** Attacker can detect downloads by using iframes. If the iframe is still accessible, the file was downloaded.
-* **Code Example**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass)
+* **Code Example**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass), [https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722](https://gist.github.com/aszx87410/e369f595edbd0f25ada61a8eb6325722) (from [https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/))
+
+{% hint style="warning" %}
+This is why this technique is interesting: Chrome now has **cache partitioning**, and the cache key of the newly opened page is: `(https://actf.co, https://actf.co, https://sustenance.web.actf.co/?m =xxx)`, but if I open an ngrok page and use fetch in it, the cache key will be: `(https://myip.ngrok.io, https://myip.ngrok.io, https://sustenance.web.actf.co/?m=xxx)`, the **cache key is different**, so the cache cannot be shared. You can find more detail here: [Gaining security and privacy by partitioning the cache](https://developer.chrome.com/blog/http-cache-partitioning/)\
+(Comment from [**here**](https://blog.huli.tw/2022/05/05/en/angstrom-ctf-2022-writeup-en/))
+{% endhint %}
 
 If a site `example.com` includes a resource from `*.example.com/resource` then that resource will have the **same caching key** as if the resource was directly **requested through top-level navigation**. That is because the caching key is consisted of top-level _eTLD+1_ and frame _eTLD+1_.
 
@@ -694,7 +702,7 @@ Before accessing the cache is faster than loading a resource, it's possible to t
 * **Inclusion Methods**: Fetch API
 * **Detectable Difference**: Timing
 * **More info**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)
-* **Summary:** It's possible to try to load a resource and about before it's loaded. Depending on if an error is triggered, the resource was or wasn't cached.
+* **Summary:** It's possible to try to load a resource and about before it's loaded the loading is interrupted. Depending on if an error is triggered, the resource was or wasn't cached.
 * **Code Example**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)
 
 [**`AbortController`**](https://developer.mozilla.org/en-US/docs/Web/API/AbortController) **** could be combined with _**fetch**_ and _**setTimeout**_ to both detect whether the **resource is cached** and to evict a specific resource from the browser cache. A nice feature of this technique is that the probing occurs without caching new content in the process.