GitBook: [#2787] gitbook freezing again

pentesting-web/xss-cross-site-scripting/README.md

@@ -799,6 +799,10 @@ function handleResponse() {
 A service worker is a **script** that your browser **runs** in the **background**, separate from a web page, opening the door to features that don't need a web page or user interaction. ([More info about what is a service worker here](https://developers.google.com/web/fundamentals/primers/service-workers)).\
 The goal of this attack is to **create service workers** on the **victim session** inside the **vulnerable** web **domain** that grant the **attacker control** over **all the pages** the **victim** will load in **that domain**.
 
+You can see them in the **Service Workers** field in the **Application** tab of **Developer Tools**. You can also look at [chrome://serviceworker-internals](https://chromium.googlesource.com/chromium/src/+/main/docs/security/chrome%3A/serviceworker-internals).
+
+If the victim didn't grant push notifications permissions the service worker won't be able to receive communications from the server if the user doesn't access the attacker  page again. This will prevent for example, maintain conversations with all the pages that accessed the attacker web page so web a exploit if found the SW can receive it and execute it. However, if the victim grants push notifications permissions this could be a risk.
+
 In order to exploit this vulnerability you need to find:
 
 * A way to **upload arbitrary JS** files to the server and a **XSS to load the service worker** of the uploaded JS file
@@ -841,6 +845,8 @@ var sw = "/jsonp?callback=onfetch=function(e){ e.respondWith(caches.match(e.requ
 
 There is **C2** dedicated to the **exploitation of Service Workers** called [**Shadow Workers**](https://shadow-workers.github.io) that will be very useful to abuse these vulnerabilities.
 
+In an XSS situation, the 24 hour cache directive limit ensures that a malicious or compromised SW will outlive a fix to the XSS vulnerability by a maximum of 24 hours (assuming the client is online). Site operators can shrink the window of vulnerability by setting lower TTLs on SW scripts. We also encourage developers to [build a kill-switch SW](https://stackoverflow.com/questions/33986976/how-can-i-remove-a-buggy-service-worker-or-implement-a-kill-switch/38980776#38980776).
+
 ### Polyglots
 
 {% embed url="https://github.com/carlospolop/Auto_Wordlists/blob/main/wordlists/xss_polyglots.txt" %}

pentesting/pentesting-web/special-http-headers.md

@@ -8,12 +8,12 @@
 
 Rewrite **IP source**:
 
-* `X-Originating-IP: 127.0.0.1` 
+* `X-Originating-IP: 127.0.0.1` 
 * `X-Forwarded-For: 127.0.0.1`
 * `X-Forwarded:  127.0.0.1`
 * `Forwarded-For: 127.0.0.1`
 * `X-Forwarded-Host: 127.0.0.1`
-* `X-Remote-IP: 127.0.0.1` 
+* `X-Remote-IP: 127.0.0.1` 
 * `X-Remote-Addr: 127.0.0.1`
 * `X-ProxyUser-Ip: 127.0.0.1`
 * `X-Original-URL: 127.0.0.1`
@@ -56,7 +56,7 @@ A hop-by-hop header is a header which is designed to be processed and consumed b
 
 * **`X-Cache`** in the response may have the value **`miss`** when the request wasn't cached and the value **`hit`** when it is cached
 * **`Cache-Control`** indicates if a resource is being cached and when will be the next time the resource will be cached again: `Cache-Control: public, max-age=1800`
-*  **`Vary`** is often used in the response to **indicate additional headers** that are treated as** part of the cache key** even if they are normally unkeyed.
+*  **`Vary`** is often used in the response to **indicate additional headers** that are treated as** part of the cache key** even if they are normally unkeyed.
 * **`Age`** defines the times in seconds the object has been in the proxy cache.
 
 {% content-ref url="../../pentesting-web/cache-deception.md" %}
@@ -112,6 +112,36 @@ From a pentest point of view this information is usually "useless", but if the r
 * **`Content-Disposition`**:  In a regular HTTP response, the **`Content-Disposition`** response header is a header indicating if the content is expected to be displayed _inline_ in the browser, that is, as a Web page or as part of a Web page, or as an _attachment_, that is downloaded and saved locally.
   * `Content-Disposition: attachment; filename="filename.jpg"`
 
+## Security Headers
+
+### Content Security Policy (CSP) <a href="csp" id="csp"></a>
+
+{% content-ref url="../../pentesting-web/content-security-policy-csp-bypass.md" %}
+[content-security-policy-csp-bypass.md](../../pentesting-web/content-security-policy-csp-bypass.md)
+{% endcontent-ref %}
+
+### Trusted Types <a href="tt" id="tt"></a>
+
+Trusted Types provide the tools to write, security review, and maintain applications free of DOM XSS. They can be enabled via [CSP](https://web.dev/security-headers/#csp) and make JavaScript code secure by default by limiting dangerous web APIs to only accept a special object—a Trusted Type.
+
+To create these objects you can define security policies in which you can ensure that security rules (such as escaping or sanitization) are consistently applied before the data is written to the DOM. These policies are then the only places in code that could potentially introduce DOM XSS.
+
+Example usa
+
+```http
+Content-Security-Policy: require-trusted-types-for 'script'
+```
+
+```javascript
+// Feature detectionif (window.trustedTypes && trustedTypes.createPolicy) {  // Name and create a policy  const policy = trustedTypes.createPolicy('escapePolicy', {    createHTML: str => {      return str.replace(/\</g, '&lt;').replace(/>/g, '&gt;');    }  });}
+```
+
+```javascript
+// Assignment of raw strings is blocked by Trusted Types.el.innerHTML = 'some string'; // This throws an exception.// Assignment of Trusted Types is accepted safely.const escaped = policy.createHTML('<img src=x onerror=alert(1)>');el.innerHTML = escaped;  // '&lt;img src=x onerror=alert(1)&gt;'
+```
+
+
+
 ## Resources
 
 * [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers)