0

このサイトで何十もの素晴らしい投稿を読んだ後、この質問をするためにサインアップしました. これは、明らかにアプリケーションのセキュリティに焦点を当てた私の未回答の質問です。

REST サービスの呼び出し時に次のヘッダーを返すサイトの場合:

Content-Type: application/json
Access-Control-Allow-Origin: *

このような寛大な CORS ポリシーを認識することは、機密データを返すサービスにとっては悪い習慣ですが、攻撃者が認証された被害者に代わって認証された REST サービス (Cookie 認証)を呼び出すことができるかどうかを証明する必要があります。攻撃者は対応を可視化できます。

このフラグは、クロスドメイン リクエストとともに関連する Cookie を送信するようにブラウザに指示することを理解しています。

withCredentials: true

私は、ブラウザが返された応答を攻撃者が解釈することを拒否することを観察しました。つまり、JSON オブジェクトはブラウザに返されますが (プロキシまたはパケット キャプチャによって証明されるように)、攻撃者がアクセスできる DOM には決して到達できません。彼女自身。

たとえば、jQuery 経由で前述の REST サービスを呼び出すと、Chrome は「資格情報フラグが true の場合、Access-Control-Allow-Origin でワイルドカードを使用できません」というメッセージを生成します。JSONP を試行すると、「Uncaught SyntaxError: Unexpected token :」というメッセージが表示されます。これは、適切なコールバック文字列を返すように REST サービス ロジックを変更するアクセス権がないためです。

脅威アクターが過度に寛容な CORS ポリシーを首尾よく活用して REST サービスを呼び出し、被害者の認証済みセッションに代わってその応答を取得/解析/返すことは本当に不可能なのでしょうか?

私はそれを恐れています：

  • 1つか2つのトリックを知らない
  • 一部のブラウザーは、このような「攻撃」を積極的に防止しない場合があります。

私は開発者ではないので、どんな洞察も大歓迎です-ありがとう!

4

2 に答える 2

0

Apache を使用している場合は、 .htaccess を追加できます。

SetEnvIf Origin "^http(s)?://(.*)$" origin_is=$0 
Header set Access-Control-Allow-Origin %{origin_is}e env=origin_is

このディレクティブは、要求にドメイン名で値が付けられた Acess-control-allow-origin を追加します。応答ヘッダーで、Origin 要求の値をコピーします。

于 2016-01-15T12:16:31.020 に答える