GitBook: [#3290] No subject

This commit is contained in:
CPol 2022-06-28 12:20:37 +00:00 committed by gitbook-bot
parent fa0d025cbf
commit 01b17a9ec2
No known key found for this signature in database
GPG key ID: 07D2180C7B12D0FF

View file

@ -61,9 +61,9 @@ Excluded XS-Leaks. We had to exclude XS-Leaks that rely on service workers as th
## Event Handler Techniques
### Event Handler Error
### Onload/Onerror
* **Inclusion Methods**: Frames, HTML ELements
* **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)
* **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.
@ -81,6 +81,25 @@ 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.
### CORB - Onerror
* **Inclusion Methods**: HTML Elements
* **Detectable Difference**: Status Code & Headers
* **More info**: [https://xsleaks.dev/docs/attacks/browser-features/corb/](https://xsleaks.dev/docs/attacks/browser-features/corb/)
* **Summary**: Attackers can observe when CORB is enforced if a response returns a _CORB protected_ `Content-Type` (and `nosniff`) with the status code `2xx` which results in CORB stripping the body and headers from the response. Detecting this protection allows an attacker to **leak** the combination of both the **status code** (success vs. error) and the **`Content-Type` (protected by CORB or not).**
Check the more information link for more information about the attack.
### onblur
* **Inclusion Methods**: Frames
* **Detectable Difference**: Page Content
* **More info**: [https://xsleaks.dev/docs/attacks/id-attribute/](https://xsleaks.dev/docs/attacks/id-attribute/), [https://xsleaks.dev/docs/attacks/experiments/portals/](https://xsleaks.dev/docs/attacks/experiments/portals/)
* **Summary**: Leak sensitive data from the id or name attribute.
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.
## Global Limits Techniques
### WebSocket API
@ -154,10 +173,11 @@ 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)
* **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)
* **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`**.
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`**.\
Same happens if you use an **embed** **tag.**
### Download Detection
@ -195,6 +215,18 @@ In GC, the **duration** for requests that result in a **redirect** is **negative
In some cases, the **nextHopProtocol entry** can be used as a leak technique. In GC, when the **CORP header** is set, the nextHopProtocol will be **empty**. Note that SA will not create a performance entry at all for CORP-enabled resources.
### Service Worker
* **Inclusion Methods**: Frames
* **Detectable Difference**: API Usage
* **More info**: [https://www.ndss-symposium.org/ndss-paper/awakening-the-webs-sleeper-agents-misusing-service-workers-for-privacy-leakage/](https://www.ndss-symposium.org/ndss-paper/awakening-the-webs-sleeper-agents-misusing-service-workers-for-privacy-leakage/)
* **Summary:** Detect if a service worker is registered for a specific origin.
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)
## Error Messages Technique
### Media Error
@ -238,6 +270,46 @@ The integrity attribute defines a cryptographic hash by which the browser can ve
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**.\
Modern browsers won't indicate the URL it was redirected to, but you can still detect that a cross-origin redirect was triggered.
### Cache
* **Inclusion Methods**: Frames, Pop-ups
* **Detectable Difference**: Page Content
* **More info**: [https://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events](https://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events), [https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html](https://sirdarckcat.blogspot.com/2019/03/http-cache-cross-site-leaks.html)
* **Summary:** Clear the file from the cache. Opens target page checks if the file is present in the cache.
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**.
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**.
### CSP Directive
* **Inclusion Methods**: Frames
* **Detectable Difference**: Header
* **More info**: [https://bugs.chromium.org/p/chromium/issues/detail?id=1105875](https://bugs.chromium.org/p/chromium/issues/detail?id=1105875)
* **Summary:** CSP header directives can be probed with the CSP iframe attribute.
A new feature in GC allows web pages to proposes a CSP by setting an attribute on an iframe element. The policy directives are transmitted along with the HTTP request. Normally, the embedded content must explicitly allow this with an HTTP header, **otherwise an error page is displayed**. However, if the iframe already ships a CSP and the new policy is not stricter, the page will display normally.
This allows an attacker to detect specific CSP directive of a crossorigin page, if it is possible to **detect the error page**. Although, this bug is now marked as fixed, we found a **new leak technique that can detect the error page, because the underlying problem was never fixed.**
### **CORP**
* **Inclusion Methods**: Fetch API
* **Detectable Difference**: Header
* **More info**: [**https://xsleaks.dev/docs/attacks/browser-features/corp/**](https://xsleaks.dev/docs/attacks/browser-features/corp/)****
* **Summary:** Resource protected with CORP throws error when fetched.
The CORP header is a relatively new web platform security feature that when set b**locks no-cors cross-origin requests to the given resource**. The presence of the header can be detected, because a resource protected with CORP will **throw an error when fetched**.
### CORB
* **Inclusion Methods**: HTML Elements
* **Detectable Difference**: Headers
* **More info**: [https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header](https://xsleaks.dev/docs/attacks/browser-features/corb/#detecting-the-nosniff-header)
* **Summary**: CORB can allow attackers to detect when the **`nosniff` header is present** in the request.
Check the more information link for more information about the attack.
##  Readable Attributes Technique
### Fetch Redirect
@ -287,9 +359,73 @@ If the **max** number of **redirects** to follow of a browser is **20**, an atta
The **History API** allows JavaScript code to manipulate the browser history, which **saves the pages visited by a user**. An attacker can use the length property as an inclusion method: to detect JavaScript and HTML navigation. Multiple works have studied the browser history and show how to abuse it to determine **whether a user has accessed a certain website** \[44, 47, 54, 75].
### Frame Counting
* **Inclusion Methods**: Frames, Pop-ups
* **Detectable Difference**: Page Content
* **More info**: [https://xsleaks.dev/docs/attacks/frame-counting/](https://xsleaks.dev/docs/attacks/frame-counting/)
* **Summary:** Read number of frames (window.length).
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.
### HTMLElements
* **Inclusion Methods**: HTML Elements
* **Detectable Difference**: Page Content
* **More info**: [https://xsleaks.dev/docs/attacks/element-leaks/](https://xsleaks.dev/docs/attacks/element-leaks/)
* **Summary:** Read the leaked value to distinguish between 2 possible states
Some webpages may **dynamically generate media files** depending on user information or add watermarks that change media size. An attacker can use information leaked by those HTML elements to distinguish between possible states.
Some HTMLElements will leak some information to cross-origins such as the type of media they are:
* [HTMLMediaElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement) leaks the media `duration` and the `buffered` times.
* [HTMLVideoElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement) leaks the `videoHeight` and `videoWidth` some browsers may also have `webkitVideoDecodedByteCount`, `webkitAudioDecodedByteCount` and `webkitDecodedFrameCount`
* [getVideoPlaybackQuality()](https://developer.mozilla.org/en-US/docs/Web/API/VideoPlaybackQuality) leaks the `totalVideoFrames`.
* [HTMLImageElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement) leaks the `height` and `width` but if the image is invalid they will be 0 and [`image.decode()`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/decode) will get rejected.
### CSS Property
* **Inclusion Methods**: HTML Elements
* **Detectable Difference**: Page Content
* **More info**: [https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle](https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle), [https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html](https://scarybeastsecurity.blogspot.com/2008/08/cross-domain-leaks-of-site-logins.html)
* **Summary:** Detect website styling depending on the status of the user.
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.
### ContentDocument XFO
* **Inclusion Methods**: Frames
* **Detectable Difference**: Headers
* **More info**: [https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdf](https://www.ndss-symposium.org/wp-content/uploads/2020/02/24278-paper.pdf)
* **Summary:** In GC, when a page is not allowed to be embedded on a cross-origin page because of **X-Frame-Options, an error page is shown**.
In Chrome, when a page is not allowed to be embedded on a cross-origin page, because the **X-FrameOptions** (XFO) header is set to deny or same-origin, an **error page is shown instead**. For objects, this error page can be **detected by checking the `contentDocument` property**. Typically, this property returns null because access to a cross-origin embedded document is not allowed. However, due to **Chromes rendering** of the error page, an **empty document object** is returned instead. This does not work for iframes or in other browsers. Developers may forget to set X-Frame-Options for all pages and especially error pages often miss this header. As a leak technique, an attacker may be able to differentiate between different user states by checking for it.
### Download Detection
* **Inclusion Methods**: Frames, Pop-ups
* **Detectable Difference**: Headers
* **More info**: [https://xsleaks.dev/docs/attacks/navigations/#download-trigger](https://xsleaks.dev/docs/attacks/navigations/#download-trigger)
* **Summary:** Attacker can detect downloads by using iframes. If the iframe is still accessible, the file was downloaded.
The `Content-Disposition` header ([`Content-Disposition: attachment`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition)) indicates if the browser is either supposed to downloaded content or displayed it inline.
If only a logged in user would be able to **access a page which will download a file** because it's using the header. It's possible to detect that behaviour.
#### Download bar <a href="#download-bar" id="download-bar"></a>
In Chromium-based browsers, when a file is downloaded, a preview of the download process **appears in a bar at the bottom**, integrated into the browser window. By **monitoring the window height**, attackers can detect whether the “download bar” opened.
#### Download Navigation (with iframes) <a href="#download-navigation-with-iframes" id="download-navigation-with-iframes"></a>
Another way to test for the [`Content-Disposition: attachment`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition) header is to **check if a navigation occurred**. If a page load causes a download, it does not trigger a navigation and the **window stays within the same origin**.
#### Download Navigation (without iframes) <a href="#download-navigation-without-iframes" id="download-navigation-without-iframes"></a>
Same technique as the previous one but using `window.open` instead of iframes.
## Time attack
@ -425,22 +561,11 @@ Then, you can use Chrome XSS Auditor to **launch an error** when a **valid respo
For more information: [https://www.youtube.com/watch?v=HcrQy0C-hEA](https://www.youtube.com/watch?v=HcrQy0C-hEA)
## Frame Counting
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.\
For more info: [https://xsleaks.dev/docs/attacks/frame-counting/](https://xsleaks.dev/docs/attacks/frame-counting/)
## Navigations
Detecting if a **cross-site page triggered a navigation** (or didnt) 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/)
### Download Trigger <a href="#download-trigger" id="download-trigger"></a>
If only a logged in user would be able to **access a page which will download a file** because it's using the [`Content-Disposition: attachment`](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition) header. It'o possible to detect that behaviour.\
For more info: [https://xsleaks.dev/docs/attacks/navigations/#download-trigger](https://xsleaks.dev/docs/attacks/navigations/#download-trigger)
### 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.\
@ -455,11 +580,6 @@ For more info: [https://xsleaks.dev/docs/attacks/cache-probing/](https://xsleaks
You could use a [**timing technique**](xs-search.md#time-attack) to check if the resource was cached.
### Error Events
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), **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**.\
For more info: [https://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events](https://xsleaks.dev/docs/attacks/cache-probing/#cache-probing-with-error-events)
### 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.**\
@ -486,27 +606,11 @@ For more info: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-c
## Element Leaks
### HTMLElements
Some HTMLElements will leak some information to cross-origins such as the type of media they are.
* [HTMLMediaElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement) leaks the media `duration` and the `buffered` times.
* [HTMLVideoElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLVideoElement) leaks the `videoHeight` and `videoWidth` some browsers may also have `webkitVideoDecodedByteCount`, `webkitAudioDecodedByteCount` and `webkitDecodedFrameCount`
* [getVideoPlaybackQuality()](https://developer.mozilla.org/en-US/docs/Web/API/VideoPlaybackQuality) leaks the `totalVideoFrames`.
* [HTMLImageElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement) leaks the `height` and `width` but if the image is invalid they will be 0 and [`image.decode()`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/decode) will get rejected.
For more info: [https://xsleaks.dev/docs/attacks/element-leaks/](https://xsleaks.dev/docs/attacks/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 its 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)
### Abusing getComputedStyle <a href="#abusing-getcomputedstyle" id="abusing-getcomputedstyle"></a>
[getComputedStyle](https://developer.mozilla.org/en-US/docs/Web/API/Window/getComputedStyle) can be used to read an embedded to the current page CSS style sheets. Including those loaded from different origins.\
For more info: [https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle](https://xsleaks.dev/docs/attacks/element-leaks/#abusing-getcomputedstyle)
### 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`.\
@ -523,26 +627,12 @@ For more info: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](http
If JavaScript is disabled its 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. Its 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)
## ID Leak
It's possible to l**oad 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.\
For more info: [https://xsleaks.dev/docs/attacks/id-attribute/](https://xsleaks.dev/docs/attacks/id-attribute/)\
You can perform the same attack with **`portal`** tags, for more info: [https://xsleaks.dev/docs/attacks/experiments/portals/](https://xsleaks.dev/docs/attacks/experiments/portals/)
## 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/)
## CORB & CORP Leaks
You can find [what is **CORP** in this page](../network-services-pentesting/pentesting-web/special-http-headers.md#corp).\
You can find [what is **CORB** in this page](../network-services-pentesting/pentesting-web/special-http-headers.md#corp-1).
A page could leak if it's using these headers to protect in some specific cases.\
For more info: [https://xsleaks.dev/docs/attacks/browser-features/corb/](https://xsleaks.dev/docs/attacks/browser-features/corb/) and [https://xsleaks.dev/docs/attacks/browser-features/corp/](https://xsleaks.dev/docs/attacks/browser-features/corp/)
## With HTML 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**.