GitBook: [#3293] No subject

network-services-pentesting/pentesting-web/xss-to-rce-electron-desktop-apps/electron-contextisolation-rce-via-electron-internal-code.md

@@ -1,4 +1,4 @@
-
+# Electron contextIsolation RCE via Electron internal code
 
 <details>
 
@@ -16,8 +16,7 @@ Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
 
 </details>
 
-
-# Example 1
+## Example 1
 
 Example from [https://speakerdeck.com/masatokinugawa/electron-abusing-the-lack-of-context-isolation-curecon-en?slide=41](https://speakerdeck.com/masatokinugawa/electron-abusing-the-lack-of-context-isolation-curecon-en?slide=41)
 
@@ -44,7 +43,7 @@ Then it goes here:
 
 Where "self" is Node's process object:
 
-![](<../../../.gitbook/assets/image (652).png>)
+![](<../../../.gitbook/assets/image (652) (1).png>)
 
 The process object has a references to "require" function:
 
@@ -63,7 +62,6 @@ location.reload();//Trigger the "exit" event
 </script>
 ```
 
-
 <details>
 
 <summary><strong>Support HackTricks and get benefits!</strong></summary>
@@ -79,5 +77,3 @@ Get the [**official PEASS & HackTricks swag**](https://peass.creator-spring.com)
 **Share your hacking tricks submitting PRs to the** [**hacktricks github repo**](https://github.com/carlospolop/hacktricks)**.**
 
 </details>
-
-

pentesting-web/http-request-smuggling/request-smuggling-in-http-2-downgrades.md

@@ -102,7 +102,7 @@ The **problem** with **HTTP/1.1** is that if you **receive 2 HTTP responses** yo
 
 However, this technique can be used **in HTTP/2** because if the endpoint was **vulnerable** and you smuggled one request, you will see the **headers of the response to the smuggled request in the response from the reverse proxy**:
 
-![](<../../.gitbook/assets/image (652) (1) (1).png>)
+![](<../../.gitbook/assets/image (652) (1) (1) (1).png>)
 
 ### Tunnel-vision Problem
 

pentesting-web/xs-search.md

@@ -101,6 +101,7 @@ In this case if `example.com/404` is not found `attacker.com/?error` will be loa
 * **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.
+* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#onload-events)
 
 ### unload/beforeunload Timing
 
@@ -108,6 +109,7 @@ In this case if `example.com/404` is not found `attacker.com/?error` will be loa
 * **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.
+* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events](https://xsleaks.dev/docs/attacks/timing-attacks/network-timing/#unload-events)
 
 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**.
 
@@ -117,6 +119,7 @@ The [`unload`](https://developer.mozilla.org/en-US/docs/Web/API/Window/unload\_e
 * **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.
+* **Code Example**: [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)
 
 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.
 
@@ -126,6 +129,7 @@ If a page doesn’t have any [Framing Protections](https://xsleaks.dev/docs/defe
 * **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.
+* **Code Example**:
 
 Suppose that you can **insert** the **page** that has the **secret** content **inside an Iframe**.
 
@@ -146,6 +150,7 @@ Then, you can **distinguish between** a **correctly** loaded page or page that h
 * **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).**
+* **Code Example:**
 
 Check the more information link for more information about the attack.
 
@@ -155,6 +160,7 @@ Check the more information link for more information about the attack.
 * **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.
+* **Code Example**: [https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet](https://xsleaks.dev/docs/attacks/id-attribute/#code-snippet)
 
 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.
@@ -165,6 +171,7 @@ You can perform the same attack with **`portal`** tags.
 * **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
+* **Code Example**: `Any code listening for all postMessages.`
 
 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).
 
@@ -175,6 +182,8 @@ Applications often use [postMessage broadcasts](https://developer.mozilla.org/en
 * **Inclusion Methods**: Frames, Pop-ups
 * **Detectable Difference**: API Usage
 * **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.1)
+* **Summary**: Exhausting the WebSocket connection limit leaks the number of WebSocket connections of a cross-origin page.
+* **Code Example**: [https://xsinator.com/testing.html#WebSocket%20Leak%20(FF)](https://xsinator.com/testing.html#WebSocket%20Leak%20\(FF\)), [https://xsinator.com/testing.html#WebSocket%20Leak%20(GC)](https://xsinator.com/testing.html#WebSocket%20Leak%20\(GC\))
 
 It is possible to identify if, and how many, **WebSocket connections a target page uses**. It allows an attacker to detect application states and leak information tied to the number of WebSocket connections.
 
@@ -185,6 +194,8 @@ If one **origin** uses the **maximum amount of WebSocket** connection objects, r
 * **Inclusion Methods**: Frames, Pop-ups
 * **Detectable Difference**: API Usage
 * **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.1)
+* **Summary**: Detect Payment Request because only one can be active at a time.
+* **Code Example**: [https://xsinator.com/testing.html#Payment%20API%20Leak](https://xsinator.com/testing.html#Payment%20API%20Leak)
 
 This XS-Leak enables an attacker to **detect when a cross-origin page initiates a payment request**.
 
@@ -196,6 +207,7 @@ Because **only one request payment can be active** at the same time, if the targ
 * **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.
+* **Code Example**:
 
 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**.
@@ -210,6 +222,7 @@ In an execution timing it's possible to **eliminate** **network factors** to obt
 * **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;
+* **Code Example**:
 
 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.
 
@@ -223,6 +236,7 @@ In an execution timing it's possible to **eliminate** **network factors** to obt
 * **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.
+* **Code Example**:
 
 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:
 
@@ -246,6 +260,7 @@ This API can be used to measure the time of a request or to detect the use of X-
 * **Detectable Difference**: Status Code
 * **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
 * **Summary:** A request that results in errors will not create a resource timing entry.
+* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Error%20Leak](https://xsinator.com/testing.html#Performance%20API%20Error%20Leak)
 
 It is possible to **differentiate between HTTP response status codes** because requests that lead to an **error** do **not create a performance entry**.
 
@@ -255,6 +270,7 @@ It is possible to **differentiate between HTTP response status codes** because r
 * **Detectable Difference**: Status Code
 * **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
 * **Summary:** Due to a browser bug, requests that result in errors are loaded twice.
+* **Code Example**: [https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak](https://xsinator.com/testing.html#Style%20Reload%20Error%20Leak)
 
 In the previous technique it was also identified two cases where browser bugs in GC lead to **resources being loaded twice when they fail to load**. This will result in multiple entries in the Performance API and can thus be detected.
 
@@ -264,6 +280,7 @@ In the previous technique it was also identified two cases where browser bugs in
 * **Detectable Difference**: Status Code
 * **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
 * **Summary:** Requests that result in an error can not be merged.
+* **Code Example**: [https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak)
 
 The technique was found in a table in the mentioned paper but no description of the technique was found on it. However, you can find the source code checking for it in [https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak](https://xsinator.com/testing.html#Request%20Merging%20Error%20Leak)
 
@@ -273,6 +290,7 @@ The technique was found in a table in the mentioned paper but no description of
 * **Detectable Difference**: Page Content
 * **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
 * **Summary:** Empty responses do not create resource timing entries.
+* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak](https://xsinator.com/testing.html#Performance%20API%20Empty%20Page%20Leak)
 
 An attacker can detect if a request resulted in an empty HTTP response body because e**mpty pages do not create a performance entry in some browsers**.
 
@@ -282,6 +300,7 @@ An attacker can detect if a request resulted in an empty HTTP response body beca
 * **Detectable Difference**: Page Content
 * **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
 * **Summary:** Detect presence of specific elements in a webpage with the XSS-Auditor in SA.
+* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak](https://xsinator.com/testing.html#Performance%20API%20XSS%20Auditor%20Leak)
 
 In SA, it is possible to detect if the XSSAuditor was triggered and thus leak sensitive information. The XSS-Auditor is a built-in feature of SA and GC (now removed) designed to mitigate Cross-Site Scripting (XSS) attacks. In 2013, Braun and Heiderich \[7] showed that the XSS-Auditor can be used to block benign scripts with false positives. Based on their technique, researchers exfiltrate information and detect specific content on a cross-origin page. These XS-Leaks were first described in a bug report by Terada and later in a blog post by Heyes . However, the discovered techniques applied only to the XSS-Auditor in GC and do not work in SA. We found that blocked pages will not create Performance API entries. That means an attacker can still leak sensitive information with the XSS-Auditor in SA.
 
@@ -291,6 +310,7 @@ In SA, it is possible to detect if the XSSAuditor was triggered and thus leak se
 * **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), [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.
+* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leak](https://xsinator.com/testing.html#Performance%20API%20X-Frame%20Leak)
 
 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.**
@@ -301,6 +321,7 @@ Same happens if you use an **embed** **tag.**
 * **Detectable Difference**: Header
 * **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
 * **Summary:** Downloads do not create resource timing entries in the Performance API.
+* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20Download%20Detection](https://xsinator.com/testing.html#Performance%20API%20Download%20Detection)
 
 Similar, to the XS-Leak described, a **resource that is downloaded** because of the ContentDisposition header, also does **not create a performance entry**. This technique works in all major browsers.
 
@@ -310,6 +331,7 @@ Similar, to the XS-Leak described, a **resource that is downloaded** because of
 * **Detectable Difference**: Redirect
 * **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
 * **Summary:** Resource timing entry leaks the start time of a redirect.
+* **Code Example**: [https://xsinator.com/testing.html#Redirect%20Start%20Leak](https://xsinator.com/testing.html#Redirect%20Start%20Leak)
 
 We found one XS-Leak instance that abuses the behavior of some browsers which log too much information for cross-origin requests. The standard defines a subset of attributes that should be set to zero for cross-origin resources. However, in **SA** it is possible to detect if the user is **redirected** by the target page, by querying the **Performance API** and checking for the **redirectStart timing data**.
 
@@ -319,6 +341,7 @@ We found one XS-Leak instance that abuses the behavior of some browsers which lo
 * **Detectable Difference**: Redirect
 * **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
 * **Summary:** The duration of timing entries is negative when a redirect occurs.
+* **Code Example**: [https://xsinator.com/testing.html#Duration%20Redirect%20Leak](https://xsinator.com/testing.html#Duration%20Redirect%20Leak)
 
 In GC, the **duration** for requests that result in a **redirect** is **negative** and can thus be **distinguished** from requests that do not result in a redirect.
 
@@ -328,6 +351,7 @@ In GC, the **duration** for requests that result in a **redirect** is **negative
 * **Detectable Difference**: Header
 * **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.2)
 * **Summary:** Resource protected with CORP do not create resource timing entries.
+* **Code Example**: [https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak](https://xsinator.com/testing.html#Performance%20API%20CORP%20Leak)
 
 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.
 
@@ -337,6 +361,7 @@ In some cases, the **nextHopProtocol entry** can be used as a leak technique. In
 * **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.
+* **Code Example**:
 
 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**.\
@@ -349,6 +374,7 @@ This could also be done with a Timing attack (check the paper for more info).
 * **Detectable Difference**: Timing
 * **More info**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources)
 * **Summary:** Detect if a resource was stored in the cache.
+* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#detecting-cached-resources)
 
 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)
@@ -359,6 +385,7 @@ For more info: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-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.
+* **Code Example**: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration](https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/#network-duration)
 
 ## Error Messages Technique
 
@@ -368,6 +395,41 @@ For more info: [https://xsleaks.dev/docs/attacks/timing-attacks/performance-api/
 * **Detectable Difference**: Status Code
 * **More info**: [https://bugs.chromium.org/p/chromium/issues/detail?id=828265](https://bugs.chromium.org/p/chromium/issues/detail?id=828265)
 * **Summary:** In FF, it is possible to accurately leak a cross-origin request’s status code.
+* **Code Example**: [https://jsbin.com/nejatopusi/1/edit?html,css,js,output](https://jsbin.com/nejatopusi/1/edit?html,css,js,output)
+
+```javascript
+// Code saved here in case it dissapear from the link
+// Based on MDN MediaError example: https://mdn.github.io/dom-examples/media/mediaerror/
+window.addEventListener("load", startup, false);
+function displayErrorMessage(msg) {
+  document.getElementById("log").innerHTML += msg;
+}
+
+function startup() {
+  let audioElement = document.getElementById("audio");
+ // "https://mdn.github.io/dom-examples/media/mediaerror/assets/good.mp3";
+  document.getElementById("startTest").addEventListener("click", function() {
+    audioElement.src = document.getElementById("testUrl").value;
+  }, false);
+  // Create the event handler
+  var errHandler = function() {
+    let err = this.error;    
+    let message = err.message;
+    let status = "";
+    
+    // Chrome error.message when the request loads successfully: "DEMUXER_ERROR_COULD_NOT_OPEN: FFmpegDemuxer: open context failed"
+    // Firefox error.message when the request loads successfully: "Failed to init decoder"
+    if((message.indexOf("DEMUXER_ERROR_COULD_NOT_OPEN") != -1) || (message.indexOf("Failed to init decoder") != -1)){
+      status = "Success";
+    }else{
+      status = "Error";
+    }
+    displayErrorMessage("<strong>Status: " + status + "</strong> (Error code:" + err.code + " / Error Message: " + err.message + ")<br>");
+  };
+  audioElement.onerror = errHandler;
+}
+
+```
 
 The message property of the **`MediaError`** interface contains a **different string for resources that loads successfully**. This allows an attacker to infer the response status for a cross-origin resource.
 
@@ -377,6 +439,7 @@ The message property of the **`MediaError`** interface contains a **different st
 * **Detectable Difference**: Header
 * **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
 * **Summary:** In SA CORS error messages leak the full URL of redirects.
+* **Code Example**: [https://xsinator.com/testing.html#CORS%20Error%20Leak](https://xsinator.com/testing.html#CORS%20Error%20Leak)
 
 This technique allows an attacker to leak the target of a redirect that is initiated by a cross-origin site.
 
@@ -388,6 +451,7 @@ CORS allows publicly accessible web resources to be read and used from any websi
 * **Detectable Difference**: Header
 * **More info**: [https://xsinator.com/paper.pdf](https://xsinator.com/paper.pdf) (5.3)
 * **Summary:** In SA CORS error messages leak the full URL of redirects.
+* **Code Example**: [https://xsinator.com/testing.html#SRI%20Error%20Leak](https://xsinator.com/testing.html#SRI%20Error%20Leak)
 
 An attacker can leak the size of cross-origin responses due to **verbose error messages**.
 
@@ -399,6 +463,7 @@ The integrity attribute defines a cryptographic hash by which the browser can ve
 * **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), [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.
+* **Code Example**: [https://xsinator.com/testing.html#CSP%20Violation%20Leak](https://xsinator.com/testing.html#CSP%20Violation%20Leak)
 
 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.
@@ -409,6 +474,7 @@ Modern browsers won't indicate the URL it was redirected to, but you can still d
 * **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.
+* **Code Example:**&#x20;
 
 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**.
 
@@ -420,6 +486,7 @@ If a page loads an image only if the user is logged in, you can **invalidate** t
 * **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.
+* **Code Example**: [https://xsinator.com/testing.html#CSP%20Directive%20Leak](https://xsinator.com/testing.html#CSP%20Directive%20Leak)
 
 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.
 
@@ -431,6 +498,7 @@ This allows an attacker to detect specific CSP directive of a crossorigin page,
 * **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.
+* **Code Example**: [https://xsinator.com/testing.html#CORP%20Leak](https://xsinator.com/testing.html#CORP%20Leak)
 
 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**.
 
@@ -440,6 +508,7 @@ The CORP header is a relatively new web platform security feature that when set
 * **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.
+* **Code Example**: [https://xsinator.com/testing.html#CORB%20Leak](https://xsinator.com/testing.html#CORB%20Leak)
 
 Check the more information link for more information about the attack.
 
@@ -449,6 +518,7 @@ Check the more information link for more information about the attack.
 * **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.
+* **Code Example**: [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)
 
 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.
@@ -461,6 +531,7 @@ In case the **Origin header** is being **reflected** in the header `Access-Contr
 * **Detectable Difference**: Status Code
 * **More info**: [https://web-in-security.blogspot.com/2021/02/security-and-privacy-of-social-logins-part3.html](https://web-in-security.blogspot.com/2021/02/security-and-privacy-of-social-logins-part3.html)
 * **Summary:** GC and SA allow to check the response’s type (opaque-redirect) after the redirect is finished.
+* **Code Example**: [https://xsinator.com/testing.html#Fetch%20Redirect%20Leak](https://xsinator.com/testing.html#Fetch%20Redirect%20Leak)
 
 Submitting a request using the Fetch API with `redirect: "manual"` and other params, it's possible to read the `response.type` attribute and if it's equals to `opaqueredirect` then the response was a redirect.
 
@@ -470,6 +541,7 @@ Submitting a request using the Fetch API with `redirect: "manual"` and other par
 * **Detectable Difference**: Header
 * **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.
+* **Code Example**: [https://xsinator.com/testing.html#COOP%20Leak](https://xsinator.com/testing.html#COOP%20Leak)
 
 An attacker can leak if the Cross-Origin Opener Policy (COOP) header is available within a cross-origin HTTP response.
 
@@ -481,6 +553,7 @@ Web applications can deploy COOP response header to prevent other websites from
 * **Detectable Difference**: Status Code
 * **More info**: [https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects](https://xsleaks.dev/docs/attacks/navigations/#server-side-redirects)
 * **Summary:** Gather the length of a URL that triggers an error on a specific server.
+* **Code Example**: [https://xsinator.com/testing.html#URL%20Max%20Length%20Leak](https://xsinator.com/testing.html#URL%20Max%20Length%20Leak)
 
 If a server-side redirect uses **user input inside the redirection** and **extra data**. It's possible to detect this behaviour because usually **servers** has a **limit request length**. If the **user data** is that **length - 1**, because the **redirect** is using **that data** and **adding** something **extra**, it will trigger an **error detectable via Error Events**.
 
@@ -490,6 +563,7 @@ If a server-side redirect uses **user input inside the redirection** and **extra
 * **Detectable Difference**: Status Code
 * **More info**: [https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.g63edc858f3\_0\_76](https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.g63edc858f3\_0\_76)
 * **Summary:** Abuse the redirect limit to detect redirects.
+* **Code Example**: [https://xsinator.com/testing.html#Max%20Redirect%20Leak](https://xsinator.com/testing.html#Max%20Redirect%20Leak)
 
 If the **max** number of **redirects** to follow of a browser is **20**, an attacker could try to load his page with **19 redirects** and finally **send the victim** to the tested page. If an **error** is triggered, then the page was trying to **redirect the victim**.
 
@@ -499,6 +573,7 @@ If the **max** number of **redirects** to follow of a browser is **20**, an atta
 * **Detectable Difference**: Redirects
 * **More info**: [https://xsleaks.dev/docs/attacks/navigations/](https://xsleaks.dev/docs/attacks/navigations/)
 * **Summary:** JavaScript code manipulates the browser history and can be accessed by the length property.
+* **Code Example**: [https://xsinator.com/testing.html#History%20Length%20Leak](https://xsinator.com/testing.html#History%20Length%20Leak)
 
 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.\
 **Checking `history.length`**, making a user **navigate** to a page, **change** it **back** to the same-origin and **checking** the new value of **`history.length`**.
@@ -509,6 +584,7 @@ The **History API** allows JavaScript code to manipulate the browser history, wh
 * **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).
+* **Code Example**: [https://xsinator.com/testing.html#Frame%20Count%20Leak](https://xsinator.com/testing.html#Frame%20Count%20Leak)
 
 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.
@@ -521,6 +597,7 @@ An example of this technique is that in chrome, a **PDF** can be **detected** wi
 * **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
+* **Code Example**: [https://xsleaks.dev/docs/attacks/element-leaks/](https://xsleaks.dev/docs/attacks/element-leaks/), [https://xsinator.com/testing.html#Media%20Dimensions%20Leak](https://xsinator.com/testing.html#Media%20Dimensions%20Leak), [https://xsinator.com/testing.html#Media%20Duration%20Leak](https://xsinator.com/testing.html#Media%20Duration%20Leak)
 
 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.
 
@@ -537,6 +614,7 @@ Some HTMLElements will leak some information to cross-origins such as the type o
 * **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.
+* **Code Example**: [https://xsinator.com/testing.html#CSS%20Property%20Leak](https://xsinator.com/testing.html#CSS%20Property%20Leak)
 
 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.
@@ -547,6 +625,7 @@ As a leak technique, the attacker can use the `window.getComputedStyle` method t
 * **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
+* **Code Example**:&#x20;
 
 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. \
@@ -554,12 +633,13 @@ So, it may be needed to trick the user into clicking an area that the CSS has af
 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
+### ContentDocument X-Frame Leak
 
 * **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**.
+* **Code Example**: [https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak](https://xsinator.com/testing.html#ContentDocument%20X-Frame%20Leak)
 
 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 **Chrome’s 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.
 
@@ -569,6 +649,7 @@ In Chrome, when a page is not allowed to be embedded on a cross-origin page, bec
 * **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.
+* **Code Example**: [https://xsleaks.dev/docs/attacks/navigations/#download-bar](https://xsleaks.dev/docs/attacks/navigations/#download-bar)
 
 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.
 
@@ -592,17 +673,29 @@ Same technique as the previous one but using `window.open` instead of iframes.
 * **Detectable Difference**: Timing
 * **More info**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass)
 * **Summary:** Attacker can detect downloads by using iframes. If the iframe is still accessible, the file was downloaded.
+* **Code Example**: [https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass](https://xsleaks.dev/docs/attacks/navigations/#partitioned-http-cache-bypass)
 
 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_.
 
 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.
 
+### Manual Redirect <a href="#fetch-with-abortcontroller" id="fetch-with-abortcontroller"></a>
+
+* **Inclusion Methods**: Fetch API
+* **Detectable Difference**: Redirects
+* **More info**: [ttps://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.gae7bf0b4f7\_0\_1234](https://docs.google.com/presentation/d/1rlnxXUYHY9CHgCMckZsCGH4VopLo4DYMvAcOltma0og/edit#slide=id.gae7bf0b4f7\_0\_1234)
+* **Summary:** It's possible to find out if a response to a fetch request is a redirect
+* **Code Example**:&#x20;
+
+![](<../.gitbook/assets/image (652).png>)
+
 ### Fetch with AbortController <a href="#fetch-with-abortcontroller" id="fetch-with-abortcontroller"></a>
 
 * **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.
+* **Code Example**: [https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller](https://xsleaks.dev/docs/attacks/cache-probing/#fetch-with-abortcontroller)
 
 [**`AbortController`**](https://developer.mozilla.org/en-US/docs/Web/API/AbortController) **** could be combined with _**fetch**_ and _**setTimeout**_ to both detect whether the **resource is cached** and to evict a specific resource from the browser cache. A nice feature of this technique is that the probing occurs without caching new content in the process.
 
@@ -612,6 +705,7 @@ Before accessing the cache is faster than loading a resource, it's possible to t
 * **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**.
+* **Code Example**: [https://xsleaks.dev/docs/attacks/element-leaks/#script-tag](https://xsleaks.dev/docs/attacks/element-leaks/#script-tag)
 
 ### Service Workers <a href="#service-workers" id="service-workers"></a>
 
@@ -619,6 +713,7 @@ Before accessing the cache is faster than loading a resource, it's possible to t
 * **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.
+* **Code Example**:
 
 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.
@@ -636,6 +731,7 @@ In an execution timing it's possible to **eliminate** **network factors** to obt
 * **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.
+* **Code Example**: [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)
 
 ### Cross-Window Timing
 
@@ -643,6 +739,7 @@ In an execution timing it's possible to **eliminate** **network factors** to obt
 * **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.
+* **Code Example**: [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)
 
 ## With HTML or Re Injection
 

todo/hardware-hacking/radio.md

@@ -58,7 +58,7 @@ With [**SigDigger** ](https://github.com/BatchDrake/SigDigger)synchronize with t
 
 ![](<../../.gitbook/assets/image (660).png>)
 
-![](<../../.gitbook/assets/image (652) (1).png>)
+![](<../../.gitbook/assets/image (652) (1) (1).png>)
 
 * **After recovering the bits you might need to process them someway**. For example, in Manchester codification a up+down will be a 1 or 0 and a down+up will be the other one. So pairs of 1s and 0s (ups and downs) will be a real 1 or a real 0.
 * Even if a signal is using Manchester codification (it's impossible to find more than two 0s or 1s in a row), you might **find several 1s or 0s together in the preamble**!