GitBook: [#2788] sdf

This commit is contained in:
CPol 2021-10-19 22:49:43 +00:00 committed by gitbook-bot
parent cacddb8495
commit c17b800791
No known key found for this signature in database
GPG Key ID: 07D2180C7B12D0FF
2 changed files with 93 additions and 10 deletions

View File

@ -799,10 +799,6 @@ 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
@ -845,8 +841,6 @@ 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" %}

View File

@ -126,22 +126,111 @@ Trusted Types provide the tools to write, security review, and maintain applicat
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;'); } });}
// Feature detection
if (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;'
// 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;'
```
### X-Content-Type-Options <a href="xcto" id="xcto"></a>
When a malicious HTML document is served from your domain (for example, if an image uploaded to a photo service contains valid HTML markup), some browsers will treat it as an active document and allow it to execute scripts in the context of the application, leading to a [cross-site scripting bug](https://www.google.com/about/appsecurity/learning/xss/).
`X-Content-Type-Options: nosniff` prevents it by instructing the browser that the [MIME type](https://mimesniff.spec.whatwg.org/#introduction) set in the `Content-Type` header for a given response is correct. This header is recommended for **all of your resources**.
```http
X-Content-Type-Options: nosniff
```
### X-Frame-Options <a href="xfo" id="xfo"></a>
If a malicious website can embed your site as an iframe, this may allow attackers to invoke unintended actions by the user with [clickjacking](https://portswigger.net/web-security/clickjacking). Also, in some cases [Spectre-type attacks](https://en.wikipedia.org/wiki/Spectre\_\(security\_vulnerability\)) give malicious websites a chance to learn about the contents of an embedded document.
`X-Frame-Options` indicates whether or not a browser should be allowed to render a page in a `<frame>`, `<iframe>`, `<embed>`, or `<object>`. **All documents** are recommended to send this header to indicate whether they allow being embedded by other documents.
If you need more granular control such as allowing only a specific origin to embed the document, use the [CSP](https://web.dev/security-headers/#csp) [`frame-ancestors`](https://developer.mozilla.org/docs/Web/HTTP/Headers/Content-Security-Policy/frame-ancestors) directive.
```http
X-Frame-Options: DENY
```
### Cross-Origin Resource Policy (CORP) <a href="corp" id="corp"></a>
An attacker can embed resources from another origin, for example from your site, to learn information about them by exploiting web-based [cross-site leaks](https://xsleaks.dev).
`Cross-Origin-Resource-Policy` mitigates this risk by indicating the set of websites it can be loaded by. The header takes one of three values: `same-origin`, `same-site`, and `cross-origin`. **All resources** are recommended to send this header to indicate whether they allow being loaded by other websites.
```
Cross-Origin-Resource-Policy: same-origin
```
### Cross-Origin Opener Policy (COOP) <a href="coop" id="coop"></a>
An attacker's website can open another site in a popup window to learn information about it by exploiting web-based [cross-site leaks](https://xsleaks.dev). In some cases, this may also allow the exploitation of side-channel attacks based on [Spectre](https://en.wikipedia.org/wiki/Spectre\_\(security\_vulnerability\)).
The `Cross-Origin-Opener-Policy` header provides a way for a document to isolate itself from cross-origin windows opened through `window.open()` or a link with `target="_blank"` without `rel="noopener"`. As a result, any cross-origin opener of the document will have no reference to it and will not be able to interact with it.
```http
Cross-Origin-Opener-Policy: same-origin-allow-popups
```
### Cross-Origin Resource Sharing (CORS) <a href="cors" id="cors"></a>
Unlike other items in this article, Cross-Origin Resource Sharing (CORS) is not a header, but a browser mechanism that requests and permits access to cross-origin resources.
By default, browsers enforce [the same-origin policy](https://web.dev/same-origin-policy/) to prevent a web page from accessing cross-origin resources. For example, when a cross-origin image is loaded, even though it's displayed on the web page visually, the JavaScript on the page doesn't have access to the image's data. The resource provider can relax restrictions and allow other websites to read the resource by opting-in with CORS.
```http
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Credentials: true
```
{% content-ref url="../../pentesting-web/cors-bypass.md" %}
[cors-bypass.md](../../pentesting-web/cors-bypass.md)
{% endcontent-ref %}
### Cross-Origin Embedder Policy (COEP) <a href="coep" id="coep"></a>
To reduce the ability of [Spectre-based attacks](https://en.wikipedia.org/wiki/Spectre\_\(security\_vulnerability\)) to steal cross-origin resources, features such as `SharedArrayBuffer` or `performance.measureUserAgentSpecificMemory()` are disabled by default.
`Cross-Origin-Embedder-Policy: require-corp` prevents documents and workers from loading cross-origin resources such as images, scripts, stylesheets, iframes and others unless these resources explicitly opt into being loaded via [CORS](https://web.dev/security-headers/#cors) or [CORP](https://web.dev/security-headers/#corp) headers. COEP can be combined with`Cross-Origin-Opener-Policy` to opt a document into [cross-origin isolation](https://web.dev/cross-origin-isolation-guide/).
Use `Cross-Origin-Embedder-Policy: require-corp` when you want to enable [cross-origin isolation](https://web.dev/coop-coep/) for your document.
```http
Cross-Origin-Embedder-Policy: require-corp
```
### HTTP Strict Transport Security (HSTS) <a href="hsts" id="hsts"></a>
Communication over a plain HTTP connection is not encrypted, making the transferred data accessible to network-level eavesdroppers.
`Strict-Transport-Security` header informs the browser that it should never load the site using HTTP and use HTTPS instead. Once it's set, the browser will use HTTPS instead of HTTP to access the domain without a redirect for a duration defined in the header.
```http
Strict-Transport-Security: max-age=3153600
```
## Resources
* [https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers](https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers)
* [https://web.dev/security-headers/](https://web.dev/security-headers/)