Skip to content

Commit 7f52379

Browse files
authored
Hint boxes improvements (#73)
* Make hints more intuitive * Applied new hint boxes * New color palette * typo * Apply suggestions from goedi02
1 parent 46c3542 commit 7f52379

File tree

21 files changed

+129
-134
lines changed

21 files changed

+129
-134
lines changed

content/_index.md

+9-9
Original file line numberDiff line numberDiff line change
@@ -12,7 +12,7 @@ Cross-Site Leaks (aka XS-Leaks, XSLeaks) are a class of vulnerabilities derived
1212

1313
## The principle of an XS-Leak
1414

15-
The fact that websites interact with each other is core to the behavior of the web. Browsers provide a wide variety of interfaces to support such interactions between different web applications. These interfaces have different security measures built on top which are intended to constrain the behavior of websites (e.g. the [Same-Origin Policy](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy)). XS-Leaks take advantage of small pieces of information that can leak during these interactions in order to infer sensitive information about users such as their data on other websites, operating systems they use, or internal networks they are connected to.
15+
The fact that websites interact with each other is core to the behavior of the web. Browsers provide a wide variety of interfaces to support such interactions between different web applications. These interfaces have different security measures built on top which are intended to constrain the behavior of websites (e.g. the [Same-Origin Policy](https://developer.mozilla.org/en-US/docs/Web/Security/Same-origin_policy)). XS-Leaks take advantage of small pieces of information that can leak during these interactions in order to infer sensitive information about users such as their data on other websites, operating systems they use, or internal networks they are connected to.
1616

1717
These pieces of information usually have a binary form and are referred to as "oracles". These oracles usually answer with *YES* or *NO* to cleverly prepared questions. For example, an oracle can be asked:
1818

@@ -34,7 +34,7 @@ Browsers provide a wide range of different APIs that, while well-intended, can e
3434

3535
Websites are generally not allowed to access data on other websites. For example, *evil.com* is forbidden from explicitly reading a response from *bank.com*, but *evil.com* can attempt to load a script from *bank.com* since that was originally judged to be harmless [^harmless]. However, *evil.com* can also determine whether or not the script successfully loaded.
3636

37-
{{< hint info >}}
37+
{{< hint example >}}
3838

3939
Suppose that *bank.com* has an API endpoint that returns data about a user's receipt for a given query.
4040

@@ -89,10 +89,10 @@ In addition, we would also like to acknowledge the users who [contributed](https
8989

9090

9191
## References
92-
[^side-channel]: Side Channel Vulnerabilities on the Web - Detection and Prevention, [link](https://owasp.org/www-pdf-archive/Side_Channel_Vulnerabilities.pdf)
93-
[^csrf]: Cross Site Request Forgery (CSRF), [link](https://owasp.org/www-community/attacks/csrf)
94-
[^browser-features]: In some cases, these features are maintained to preserve backwards compatibility. But, in other cases, new features are added to browsers regardless of the fact that they introduce potential Cross-Site Leaks (e.g. [Scroll to Text Fragment]({{< ref "scroll-to-text-fragment.md" >}})), as the benefits are considered to outweigh the downsides.
95-
[^harmless]: Websites being able to interact and include resources from each other is a key part of how the web works. For example, many websites allow users to post content that includes images embedded from elsewhere on the web. Fundamentally, this is an intended behavior of the web. But, over time, the downsides of this sort of interaction have become better understood.
96-
[^old-wiki]: Browser Side Channels, [link](https://github.com/xsleaks/xsleaks/wiki/Browser-Side-Channels)
97-
[^xs-search-first]: Cross-Site Search Attacks, [link](https://446h.cybersec.fun/xssearch.pdf)
98-
[^spectre]: Meltdown and Spectre, [link](https://spectreattack.com/)
92+
[^side-channel]: Side Channel Vulnerabilities on the Web - Detection and Prevention, [link](https://owasp.org/www-pdf-archive/Side_Channel_Vulnerabilities.pdf)
93+
[^csrf]: Cross Site Request Forgery (CSRF), [link](https://owasp.org/www-community/attacks/csrf)
94+
[^browser-features]: In some cases, these features are maintained to preserve backwards compatibility. But, in other cases, new features are added to browsers regardless of the fact that they introduce potential Cross-Site Leaks (e.g. [Scroll to Text Fragment]({{< ref "scroll-to-text-fragment.md" >}})), as the benefits are considered to outweigh the downsides.
95+
[^harmless]: Websites being able to interact and include resources from each other is a key part of how the web works. For example, many websites allow users to post content that includes images embedded from elsewhere on the web. Fundamentally, this is an intended behavior of the web. But, over time, the downsides of this sort of interaction have become better understood.
96+
[^old-wiki]: Browser Side Channels, [link](https://github.com/xsleaks/xsleaks/wiki/Browser-Side-Channels)
97+
[^xs-search-first]: Cross-Site Search Attacks, [link](https://446h.cybersec.fun/xssearch.pdf)
98+
[^spectre]: Meltdown and Spectre, [link](https://spectreattack.com/)

content/docs/attacks/browser-features/corb.md

+12-10
Original file line numberDiff line numberDiff line change
@@ -19,18 +19,23 @@ weight = 2
1919

2020
[Cross-Origin Read Blocking]({{< ref "../../defenses/secure-defaults/corb.md" >}}) (CORB) is a web platform security feature aimed at reducing the impact of speculative side-channel attacks such as Spectre. Unfortunately, blocking certain types of requests introduced a new type of XS-Leaks that allows attackers to detect if CORB was enforced on one request, but wasn't on another. Nevertheless, the introduced XS-Leaks are much less problematic than the issues actively protected by CORB (e.g Spectre).
2121

22+
23+
{{< hint info >}}
24+
This issue is known to Chromium, and while it [might remain unfixed](https://docs.google.com/document/d/1kdqstoT1uH5JafGmRXrtKE4yVfjUVmXitjcvJ4tbBvM/edit?ts=5f2c8004), its impact is highly reduced by the [rollout of Same-Site Cookies by default](https://blog.chromium.org/2020/05/resuming-samesite-cookie-changes-in-july.html) in Chromium-based browsers.
25+
{{< /hint >}}
26+
2227
## CORB & Error Events
2328

2429

25-
Attackers can observe when CORB is enforced if a response returns a *CORB protected* `Content-Type` (and `nosniff`) with status code `2xx` which results in CORB stripping the body and headers from the response. Detecting this protection will allow an attacker to leak the combination of both the status code (success vs. error) and the `Content-Type` (protected by CORB or not). This allows the distinction of two possible states:
26-
- One state results in a request being protected by CORB and the second a client error (404).
30+
Attackers can observe when CORB is enforced if a response returns a *CORB protected* `Content-Type` (and `nosniff`) with status code `2xx` which results in CORB stripping the body and headers from the response. Detecting this protection will allow an attacker to leak the combination of both the status code (success vs. error) and the `Content-Type` (protected by CORB or not). This allows the distinction of two possible states:
31+
- One state results in a request being protected by CORB and the second a client error (404).
2732
- One state is protected by CORB and the second is not.
2833

2934
The following steps could be observed to abuse this protection with the first example:
3035

3136
1. An attacker can embed a cross-origin resource in a `script` tag which returns `200 OK` with `text/html` as `Content-Type` and a `nosniff` Header.
32-
2. To protect sensitive contents from entering the attacker's process, `CORB` will replace the original response with an empty one.
33-
3. Since an empty response is valid JavaScript, the `onerror` event won't be fired and `onload` will fire instead.
37+
2. To protect sensitive contents from entering the attacker's process, `CORB` will replace the original response with an empty one.
38+
3. Since an empty response is valid JavaScript, the `onerror` event won't be fired and `onload` will fire instead.
3439
4. The attacker triggers a second request (corresponding to a second state), similar to 1., which returns something other than `200 OK`. The `onerror` event will fire.
3540

3641
The interesting behavior is that CORB creates a valid resource out of request which could contain something other than JavaScript (causing an error). Considering a non-CORB environment, both 1. and 4. requests would trigger an error. This introduces an XS-Leak as these situations are now distinguishable.
@@ -39,7 +44,7 @@ The interesting behavior is that CORB creates a valid resource out of request wh
3944

4045
CORB could also allow attackers to detect when the `nosniff` header is present in the request. This problem originated due to the fact CORB is only enforced depending on the presence of this header and some sniffing algorithms. The example below shows two distinguishable states:
4146

42-
1. CORB will prevent an attacker page which embeds a resource as a `script` if the resource is served with `text/html` as `Content-Type` along with the `nosniff` header.
47+
1. CORB will prevent an attacker page which embeds a resource as a `script` if the resource is served with `text/html` as `Content-Type` along with the `nosniff` header.
4348
2. If the resource does not set `nosniff` and CORB [fails](https://chromium.googlesource.com/chromium/src/+/master/services/network/cross_origin_read_blocking_explainer.md#what-types-of-content-are-protected-by-corb) to infer the `Content-Type` of the page (which remains `text/html`), a `SyntaxError` will be fired since the contents can't be parsed as valid JavaScript. This error can be caught by listening to `window.onerror` as `script` tags only trigger error events in [certain conditions](https://developer.mozilla.org/en-US/docs/Web/API/HTMLScriptElement).
4449

4550
## Defense
@@ -50,12 +55,9 @@ CORB could also allow attackers to detect when the `nosniff` header is present i
5055
| ✔️ | ✔️ |||
5156

5257

53-
{{< hint good >}}
54-
This issue is known by Chromium, and while it [might remain unfixed](https://docs.google.com/document/d/1kdqstoT1uH5JafGmRXrtKE4yVfjUVmXitjcvJ4tbBvM/edit?ts=5f2c8004), its impact is highly reduced by the [rollout of Same-Site Cookies by default](https://blog.chromium.org/2020/05/resuming-samesite-cookie-changes-in-july.html) in Chromium-based browsers.
55-
{{< /hint >}}
5658

57-
{{< hint good >}}
58-
Developers can deploy [CORP]({{< ref "../../defenses/opt-in/corp.md" >}}) in application resources to force a protection similar to CORB that does not inspect responses to decide when to act. To prevent attackers from abusing this XS-Leak, generic XS-Leaks defense mechanisms are also effective.
59+
{{< hint tip >}}
60+
Developers can deploy [CORP]({{< ref "../../defenses/opt-in/corp.md" >}}) in application's subresources to force a protection similar to CORB that does not inspect responses to decide when to act. To prevent attackers from abusing this XS-Leak, generic XS-Leaks defense mechanisms are also effective.
5961
{{< /hint >}}
6062

6163
## References

content/docs/attacks/cache-probing.md

+8-8
Original file line numberDiff line numberDiff line change
@@ -45,7 +45,7 @@ Cache Probing with [Error Events]({{< ref "../attacks/error-events.md" >}}) [^2]
4545

4646
To invalidate a resource from the cache the attacker must force the server to return an error when fetching that subresource. There are a couple of ways to achieve this:
4747

48-
- A fetch request with `cache:'reload'`option that is aborted with [`AbortController.abort()`](https://developer.mozilla.org/en-US/docs/Web/API/AbortController/abort) before new content has been received, but after the request was initiated by the browser.
48+
- A fetch request with `cache:'reload'`option that is aborted with [`AbortController.abort()`](https://developer.mozilla.org/en-US/docs/Web/API/AbortController/abort) before new content has been received, but after the request was initiated by the browser.
4949
- A request with an [overlong referer header](https://lists.archive.carbon60.com/apache/users/316239) and `'cache':'reload'`. This might not work as browsers [capped](https://github.com/whatwg/fetch/issues/903) the length of the referrer to prevent this.
5050
- A `POST` request with a `fetch` `no-cors`. Sometimes even in cases where an error is not returned the browser invalidates the cache.
5151
- Request headers such as Content-Type, Accept, Accept-Language, etc that may cause the server to fail (more application dependent).
@@ -63,20 +63,20 @@ async function ifCached(url, purge = false) {
6363
// The timeout might need to be adjusted for the attack to work properly.
6464
// Purging content seems to take slightly less time than probing
6565
var wait_time = (purge) ? 3 : 9;
66-
var timeout = await setTimeout(() => {
66+
var timeout = await setTimeout(() => {
6767
controller.abort();
6868
}, wait_time);
6969
try {
7070
// credentials option is needed for Firefox
7171
let options = {
72-
mode: "no-cors",
73-
credentials: "include",
72+
mode: "no-cors",
73+
credentials: "include",
7474
signal: signal
7575
};
76-
// If the option "cache: reload" is set, the browser will purge
76+
// If the option "cache: reload" is set, the browser will purge
7777
// the resource from the browser cache
7878
if(purge) options.cache = "reload";
79-
79+
8080
await fetch(url, options);
8181
} catch (err) {
8282
// When controller.abort() is called, the fetch will throw an Exception
@@ -88,7 +88,7 @@ async function ifCached(url, purge = false) {
8888
// wait_time which means that the resource must have arrived from the cache
8989
clearTimeout(timeout);
9090
console.log("The resource is cached");
91-
91+
9292
return true;
9393
}
9494

@@ -115,7 +115,7 @@ Currently there are no good defense mechanisms that would allow websites to full
115115

116116
A promising defense against this attack is [partitioning the HTTP cache]({{< ref "../defenses/secure-defaults/partitioned-cache.md" >}}) by the requesting origin. This browser provided protection prevents an attacker's origin from interfering with cached resources of other origins.
117117

118-
{{< hint warning >}}
118+
{{< hint important >}}
119119
As of November 2020, Partitioned Caches are not available in most browsers, so applications cannot rely on them.
120120
{{< /hint >}}
121121

content/docs/attacks/experiments/scroll-to-text-fragment.md

+4-4
Original file line numberDiff line numberDiff line change
@@ -21,7 +21,7 @@ In early discussions for the specification of this feature it was shown that sev
2121

2222
## Current Issues
2323

24-
{{< hint info >}}
24+
{{< hint warning >}}
2525
These XS-Leaks require some type of markup injection on the target page.
2626
{{< /hint >}}
2727

@@ -30,12 +30,12 @@ During the development process of STTF new attacks and tricks to detect a fragme
3030
- A web page that embeds an attacker-controlled `iframe` might allow the attacker to determine whether a scroll to the text has occurred. This can be done using the [`IntersectionObserver`](https://developer.mozilla.org/en-US/docs/Web/API/Intersection_Observer_API) API [^2] [^3] [^4].
3131
- If a page contains images with [Lazy Loading](https://web.dev/native-lazy-loading/) an attacker might known if a fragment navigation that included an image occurred by checking whether it was [cached in the browser]({{< ref "../cache-probing.md" >}}). This occurs because [Lazy Loading](https://web.dev/native-lazy-loading/) images are only fetched (and cached) when they appear in the viewport.
3232

33-
{{< hint warning >}}
33+
{{< hint important >}}
3434
Scroll to Text Fragment is only available in Chrome. Its [draft](https://wicg.github.io/scroll-to-text-fragment/) specification is under active discussion.
3535
{{< /hint >}}
3636

37-
{{< hint good >}}
38-
Scroll to Text Fragment XS-Leaks allow attackers to extract 1 bit of information at a time as it's only possible to observe whether a group of words is present in a page. This is because STTF matching is based on words, so attackers won't be able to leak information character by character.
37+
{{< hint info >}}
38+
Scroll to Text Fragment XS-Leaks allow attackers to extract 1 bit of information at a time as it's only possible to observe whether a single word exists on the page and only when a user performed some kind of interaction with the page (e.g. mouse click).
3939
{{< /hint >}}
4040

4141
## Why is this a problem?

content/docs/attacks/id-attribute.md

+4-2
Original file line numberDiff line numberDiff line change
@@ -29,15 +29,17 @@ Some web applications set `id` attributes in `focusable` elements that may lead
2929
The below snippet presents an example way of detecting the ID attribute from another site.
3030
```javascript
3131
// Listen to onblur event
32-
onblur = () => alert('Focus was lost, so there was a focusable element with the specified ID');
32+
onblur = () => {
33+
alert('Focus was lost, so there is a focusable element with the specified ID');
34+
}
3335
var ifr = document.createElement('iframe');
3436
// If a page has a focusable element with id="x" it will gain focus
3537
// E.g. <input id="x" value="test" />
3638
ifr.src = 'https://example.org/#x';
3739
document.body.appendChild(ifr);
3840
```
3941

40-
{{< hint good >}}
42+
{{< hint info >}}
4143
The above technique doesn't seem to work in Firefox.
4244
{{< /hint >}}
4345

content/docs/attacks/navigations.md

+4-4
Original file line numberDiff line numberDiff line change
@@ -55,7 +55,7 @@ setTimeout(() => {
5555
}, 2000);
5656
```
5757

58-
{{< hint warning >}}
58+
{{< hint important >}}
5959
This attack is only possible in Chromium-based browsers with automatic downloads enabled. The attack can't be also repeated since the user needs to close the download bar for it to be measurable again.
6060
{{< /hint >}}
6161

@@ -86,10 +86,10 @@ iframe.onload = () => {
8686
```
8787

8888
{{< hint info >}}
89-
When there is no navigation inside an iframe caused by a download attempt the iframe will not trigger an `onload` event directly. Because of that, in the example above, an outer iframe was used instead, that listens for `onload` event which triggers when subresources finished loading, including iframes.
89+
When there is no navigation inside an iframe caused by a download attempt, the iframe will not trigger an `onload` event directly. Because of that, in the example above, an outer iframe was used instead, that listens for `onload` event which triggers when subresources finished loading, including iframes.
9090
{{< /hint >}}
9191

92-
{{< hint info >}}
92+
{{< hint important >}}
9393
This attack will work regardless of any [Framing Protections]({{< ref "xfo" >}}), because the `X-Frame-Options` and `Content-Security-Policy` headers are ignored if `Content-Disposition: attachment` is specified.
9494
{{< /hint >}}
9595

@@ -122,7 +122,7 @@ setTimeout(() => {
122122

123123
A server-side redirect can be detected from a cross-origin page if the destination URL increases in size and contains an attacker controlled input (either in the form of a query string parameter or a path). The following technique relies on the fact that it is possible to induce an error in most web-servers by generating big requests parameters/paths. Since the redirect increases the size of the URL, it can be detected by sending exactly one character less than the server maximum capacity. That way if the size increases the server will respond with an error that can be detected from a cross-origin page (eg via Error Events).
124124

125-
{{< hint info >}}
125+
{{< hint example >}}
126126
An example of this attack can be seen [here](https://xsleaks.github.io/xsleaks/examples/redirect/).
127127
{{< /hint >}}
128128
## Cross-Origin Redirects

0 commit comments

Comments
 (0)