XSinator linking (#137)

* Update corp.md

* Use References

* Update corp.md

* COOP

* Update corp.md

* Update window-references.md

* Update corb.md

* Update navigations.md

* Update id-attribute.md

* Update element-leaks.md

* Update performance-api.md

* Update frame-counting.md

* Update navigations.md

* Update navigations.md

* duration & dimensions

* Update performance-api.md

* Update error-events.md

* Update cache-probing.md

* Update connection-pool.md

* Update navigations.md

* Run Demo

* Demo link

* Demo link

* Run demo

* Run demo

* Run demo

* Run demo

* Update navigations.md

* Update connection-pool.md

* Update performance-api.md

* Update window-references.md

Author: NDevTK

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

@@ -45,7 +45,7 @@ The interesting behavior is that CORB creates a valid resource out of the reques
 CORB can also allow attackers to detect when the `nosniff` header is present in the request. This problem originated due to the fact that CORB is only enforced depending on the presence of this header and some sniffing algorithms. The example below shows two distinguishable states:
 
 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.
-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 under [certain conditions](https://developer.mozilla.org/en-US/docs/Web/API/HTMLScriptElement).
+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 under [certain conditions](https://developer.mozilla.org/en-US/docs/Web/API/HTMLScriptElement). [Run demo](https://xsinator.com/testing.html#CORB%20Leak)
 
 ## Defense
 

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

@@ -18,7 +18,7 @@ weight = 2
 
 [Cross-Origin Resource Policy]({{< ref "/docs/defenses/opt-in/corp.md" >}}) (CORP) is a web platform security feature that allows websites to prevent certain resources from being loaded by other origins. This protection complements [CORB]({{< ref "/docs/defenses/secure-defaults/corb.md" >}}) since it is an opt-in defense, whereas CORB blocks some cross-origin reads by default. Unfortunately, similar to [CORB]({{< ref "corb.md" >}}), applications can introduce a new XS-Leak if they misconfigure the use of this protection.
 
-A webpage will introduce an XS-Leak if `CORP` is enforced based on user data. If a page search feature enforces `CORP` when showing results, but doesn't do so when returning no results, an attacker will be able to distinguish the two scenarios. This occurs because a page/resource protected by `CORP` will return an error when fetched cross-origin.
+A webpage will introduce an XS-Leak if `CORP` is enforced based on user data. If a page search feature enforces `CORP` when showing results, but doesn't do so when returning no results, an attacker will be able to distinguish the two scenarios. This occurs because a page/resource protected by `CORP` will return an error when fetched cross-origin.  [Run demo](https://xsinator.com/testing.html#CORP%20Leak)
 
 ## Defense
 
@@ -29,4 +29,3 @@ An application can avoid this XS-Leak if it guarantees `CORP` is deployed in all
 |                                         ✔️                                          |                          ❌                          |                                 ❌                                 | [RIP]({{< ref "/docs/defenses/isolation-policies/resource-isolation" >}}) 🔗 [NIP]({{< ref "/docs/defenses/isolation-policies/navigation-isolation" >}}) |
 
 🔗 – Defense mechanisms must be combined to be effective against different scenarios.
-

content/docs/attacks/cache-probing.md

@@ -62,7 +62,7 @@ For example, Flask framework [promotes](https://flask-cors.readthedocs.io/en/lat
 
 If a resource hosted on `server.com` is requested from `target.com` then the origin could be reflected in the response headers as: `Access-Control-Allow-Origin: target.com`. If the resource is cached, this information is stored together with the resource in the browser cache. With that, if `attacker.com` tries to fetch the same resource there are two possible scenarios:
 - The resource is not in cache: the resource could be fetched and stored together with the `Access-Control-Allow-Origin: attacker.com` header.
-- The resource was already in cache: fetch attempt will try to fetch the resource from the cache but it will also generate a CORS error due to the ACAO header value mismatch with the requesting origin (`target.com` origin was expected but `attacker.com` was provided). Here below is provided an example code snippet epxloting this vulnerability to infer the cache status of the victim's browser. 
+- The resource was already in cache: fetch attempt will try to fetch the resource from the cache but it will also generate a CORS error due to the ACAO header value mismatch with the requesting origin (`target.com` origin was expected but `attacker.com` was provided). Here below is provided an example code snippet epxloting this vulnerability to infer the cache status of the victim's browser. [Run demo](https://xsinator.com/testing.html#Cache%20Leak%20(CORS))
 ```javascript
 // The function simply takes a url and fetches it in CORS mode.
 // If the fetch raises an error, it will be a CORS error due to the 

content/docs/attacks/element-leaks.md

@@ -15,12 +15,12 @@ weight = 2
 Some HTML Elements might be used to leak a portion of data to a cross-origin page.
 For example, the below media resources can leak information about its size, duration, type. 
 
-- [HTMLMediaElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement) leaks the media `duration` and the `buffered` times.
+- [HTMLMediaElement](https://developer.mozilla.org/en-US/docs/Web/API/HTMLMediaElement) leaks the media `duration` and the `buffered` times. [Run demo](https://xsinator.com/testing.html#Media%20Duration%20Leak)
 - [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.
+  and [`image.decode()`](https://developer.mozilla.org/en-US/docs/Web/API/HTMLImageElement/decode) will get rejected. [Run demo](https://xsinator.com/testing.html#Media%20Dimensions%20Leak)
 
 It's possible to differentiate between media types via unique property for a given media type. For example, it is `videoWidth` for a `<video>`, or `duration` for an `<audio>`. The below snippet shows an example code that returns the type of a resource. 
 ```javascript
@@ -68,7 +68,7 @@ async function isType(url, type = "script") {
 
 ## Abusing getComputedStyle
 [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. 
-This function just checks if there has been a style applied to the body.
+This function just checks if there has been a style applied to the body. [Run demo](https://xsinator.com/testing.html#CSS%20Property%20Leak)
 ```javascript
 async function isCSS(url) {
     let link = document.createElement('link');

content/docs/attacks/error-events.md

@@ -26,7 +26,7 @@ For example, attackers can detect whether a user is logged in to a service by ch
 
 Error events can be thrown from a large variety of HTML tags, and some behaviors vary from browser to browser [^4]. For instance, the behavior can depend on the loaded resources, HTML tags, presence of certain headers (e.g. `nosniff`, `Content-Type`), or the enforcement of default browser protections, etc.
 
-The principle of leaking information with error events can be abstracted and applied to a variety of XS-Leaks. For example, one technique for [Cache Probing]({{< ref "cache-probing.md" >}}) uses Error Events to detect if a certain image was cached by the browser.
+The principle of leaking information with error events can be abstracted and applied to a variety of XS-Leaks. For example, one technique for [Cache Probing]({{< ref "cache-probing.md" >}}) uses Error Events to detect if a certain image was cached by the browser. [Run demo](https://xsinator.com/testing.html#Event%20Handler%20Leak%20(Script))
 
 ## Code Snippet
 The below snippet demonstrates how an Error Event can be detected with the `<script>` tag:

content/docs/attacks/frame-counting.md

@@ -23,7 +23,7 @@ Window references allow cross-origin pages to get access to some of the attribut
 
 One of the accessible attributes is `window.length` which provides the number of frames in the window. This attribute can provide valuable information about a page to an attacker.
 
-Websites commonly use frames (or `iframes`) and this choice doesn't necessarily imply security issues. There are, however, cases where a website might change the number of frames on a page depending on some user information. For example, this could happen on a page that changes its layout depending on the `GET` parameters and the victim's data. It might be possible for an attacker to infer information about the victim by measuring the value of `window.length` on different pages.
+Websites commonly use frames (or `iframes`) and this choice doesn't necessarily imply security issues. There are, however, cases where a website might change the number of frames on a page depending on some user information. For example, this could happen on a page that changes its layout depending on the `GET` parameters and the victim's data. It might be possible for an attacker to infer information about the victim by measuring the value of `window.length` on different pages. [Run demo](https://xsinator.com/testing.html#Frame%20Count%20Leak)
 
 ## Code Snippet
 The below snippet demonstrates how to access the information about the number of frames on a cross-site page:

content/docs/attacks/id-attribute.md

@@ -23,7 +23,7 @@ weight = 3
 
 The `id` attribute is widely used to identify `HTML` elements. Unfortunately, cross-origin websites can determine whether a given `id` is set anywhere on a page by leveraging the `focus` event and `URL` fragments. If `https://example.com/foo#bar` is loaded, the browser attempts to scroll to the element with `id="bar"`. This can be detected cross-origin by loading `https://example.com/foo#bar` in an iframe; if there is an element with `id="bar"`, the `focus` event fires. The `blur` event can also be used for the same purpose [^1].
 
-Some web applications set `id` attributes in `focusable` elements that can lead to disclosing user information. These `id`s can either contain information directly related to the user (e.g. a secret), or information associated with a user state (e.g. account status).
+Some web applications set `id` attributes in `focusable` elements that can lead to disclosing user information. These `id`s can either contain information directly related to the user (e.g. a secret), or information associated with a user state (e.g. account status). [Run demo](https://xsinator.com/testing.html#Id%20Attribute%20Leak)
 
 ## Code snippet
 

content/docs/attacks/navigations.md

@@ -29,7 +29,7 @@ Detecting if a cross-site page triggered a navigation (or didn't) can be useful
 To detect if any kind of navigation occurred, an attacker can:
 
 - Use an `iframe` and count the number of times the `onload` event is triggered.
-- Check the value of `history.length`, which is accessible through any window reference. This provides the number of entries in the history of a victim that were either changed by `history.pushState` or by regular navigations. To get the value of `history.length`, an attacker changes the location of the window reference to the target website, then changes back to same-origin, and finally reads the value.
+- Check the value of `history.length`, which is accessible through any window reference. This provides the number of entries in the history of a victim that were either changed by `history.pushState` or by regular navigations. To get the value of `history.length`, an attacker changes the location of the window reference to the target website, then changes back to same-origin, and finally reads the value. [Run demo](https://xsinator.com/testing.html#History%20Length%20Leak)
 
 ## Download Trigger
 
@@ -62,7 +62,7 @@ This attack is only possible in Chromium-based browsers with automatic downloads
 
 ### Download Navigation (with iframes)
 
-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.
+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. [Run demo](https://xsinator.com/testing.html#Download%20Detection)
 
 The following snippet can be used to detect whether such a navigation has occurred and therefore detect a download attempt:
 
@@ -130,7 +130,7 @@ An example of this attack can be seen [here](https://xsleaks.github.io/xsleaks/e
 
 ### CSP Violations
 
-[Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) (CSP) is an in-depth defense mechanism against XSS and data injection attacks. When a CSP is violated, a `SecurityPolicyViolationEvent` is thrown. An attacker can set up a CSP using the [`connect-src` directive](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/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 [^2] [^3].
+[Content-Security-Policy](https://developer.mozilla.org/en-US/docs/Web/HTTP/CSP) (CSP) is an in-depth defense mechanism against XSS and data injection attacks. When a CSP is violated, a `SecurityPolicyViolationEvent` is thrown. An attacker can set up a CSP using the [`connect-src` directive](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/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 [^2] [^3]. [Run demo](https://xsinator.com/testing.html#CSP%20Violation%20Leak)
 
 The example below triggers a `SecurityPolicyViolationEvent` if the website set in the fetch API (line 6) redirects to a website other than `https://example.org`:
 

content/docs/attacks/timing-attacks/connection-pool.md

@@ -14,7 +14,7 @@ defenses = [
 menu = "main"
 +++
 
-Another way to measure the network timing of a request consists of abusing the socket pool of a browser [^1]. 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.
+Another way to measure the network timing of a request consists of abusing the socket pool of a browser [^1]. 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. [Run demo (Chrome)](https://xsinator.com/testing.html#WebSocket%20Leak%20(GC)) [Run demo (Firefox)](https://xsinator.com/testing.html#WebSocket%20Leak%20(FF))
 
 To exploit the existence of this limit, attackers can:
 1. Check what the limit of the browser is, for example 256 global sockets for TCP and 6000 global sockets for UDP. [^2][^7]

content/docs/attacks/timing-attacks/performance-api.md

@@ -44,7 +44,7 @@ await getNetworkDuration('https://example.org');
 {{< hint info >}} Unlike other browsers, Firefox provides the measurements in milliseconds. {{< /hint >}}
 
 ## Detecting X-Frame-Options
-If displaying a page inside an embed (e.g. because of the `X-Frame-Options` header) it will not be added to the `performance` object in Chrome.
+If displaying a page inside an embed (e.g. because of the `X-Frame-Options` header) it will not be added to the `performance` object in Chrome. [Run demo](https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leak)
 ```javascript
 async function isFrameBlocked(url) {
     let href = new URL(url).href;
@@ -68,7 +68,7 @@ await isFrameBlocked('https://example.org');
 # Detecting cached resources
 
 With the `performance` API it is possible to detect whether a resource was cached or not.
-Unless [Cross-Origin Read Blocking]({{< ref "../../defenses/secure-defaults/corb.md" >}}) is triggered (resource is html) the resource will get cached in the processs of the check.  
+Unless [Cross-Origin Read Blocking]({{< ref "../../defenses/secure-defaults/corb.md" >}}) is triggered (resource is html) the resource will get cached in the processs of the check.  [Run demo](https://xsinator.com/testing.html#Duration%20Redirect%20Leak)
 ```javascript
 async function ifCached2(url) {
     let href = new URL(url).href;