web-dev-qa-db-ja.com

GETリクエストを使用したAPIエンドポイントのCSRFテスト

認証にセッションCookieのみを使用してWebサイトにログインしている場合、新しいAPIトークンをJSONでユーザーに返すAPIエンドポイントがあります。

そのエンドポイントにGETリクエストを送信する別のドメインに自動的に読み込まれるコードを記述しようとしています。その人のCookieを使用して、新しいAPIトークンを悪意を持ってフェッチできるかどうかを確認しています。私のエンドポイントが安全かどうか、またはこれが可能かどうかを確認しています。同じドメインからのログイン要求のみがそのエンドポイントに到達できるようにしたい。状態が変化しないため、これが実際にCSRFと見なされるかどうかは不明です。 CORSポリシーがあるので、それが私がこれを行うのを妨げているかどうかはわかりません。また、ワニスはX-XSS-Protection:1が有効になっているフロントエンドです。

私が試したこと、単に別のドメインページでエンドポイントをロードすること。ユーザーが別のタブにログインした。これは200を返し、ログインしたユーザーの予想されるCookieが含まれますが、JSON応答は含まれません。

<img src="https://mydomain/endpoint" width="0" height="0" border="0">

以下は、ログインしたユーザーの正しいCookieを含む200を返しますが、json応答は返しません。ブラウザの同じOriginポリシーのため、これはデータを返さないと思います。私が間違っていたら訂正してください。

document.write('<img src="https://mydomain/endpoint?cookie=' + document.cookie + '" />')

XMLHttpRequestとJQueryの両方で、ターゲットエンドポイントへのGETリクエストを実行します。これも、別のドメインからログインし、ユーザーは別のタブにログインしています。許可されていない401とCookieを返します。リクエストでcookieをキャプチャして送信するために必要なjqueryがいくつかあるかもしれません。

$.get('https://mydomain/endpoint', function(responseText) {
alert(responseText);});

Chrome成功したWebリクエストの開発者コンソールからAPIエンドポイントにcurlリクエストをコピーします。驚くべきことに、curlは予期されたパラメーターとCookieを使用しても、新しいトークンを返しません。同じOriginポリシーの。

他のアイデア、これは私が説明したことでも可能ですか?

2
mjmj

あなたが言及し始めたように、CSRFは状態を変更するアクションに対してのみ有用であるため、これは本当にCSRFの例ではありません。

から [〜#〜] owasp [〜#〜]

クロスサイトリクエストフォージェリ(CSRF)は、エンドユーザーに、現在認証されているWebアプリケーションで不要なアクションを実行させる攻撃です。攻撃者は偽造された要求への応答を確認する方法がないため、CSRF攻撃はデータの盗難ではなく、状態変更要求を特に対象としています。

さらに、応答が表示されない理由は、おそらくクロスオリジンリソースシェアリング(CORS)が原因です。

MDN web docs の状態:

セキュリティ上の理由から、ブラウザはスクリプト内から開始されたクロスオリジンHTTPリクエストを制限します。たとえば、XMLHttpRequestとFetch APIは、同じオリジンポリシーに従います。つまり、これらのAPIを使用するWebアプリケーションは、CORSヘッダーを使用しない限り、アプリケーションのロード元と同じドメインからのみHTTPリソースをリクエストできます。

したがって、リモートリソースは確かにフェッチ可能ですが、ブラウザはテストページのJavaScriptが応答を表示することを許可していません。これは、サーバーに正しいヘッダーを設定する方法を踏まなければ、デフォルトの動作です。

2
multithr3at3d

CORSが正しく構成されている限り、JavaScriptを介して別のドメインから情報を抽出することはできません。

また、JSONエンドポイントが配列ではなくオブジェクトを返すことを確認して、古いブラウザーに影響を与える古い脆弱性 JSON Hijacking から保護する必要があります。

2
Benoit Esnard