web-dev-qa-db-ja.com

「Access-Control-Allow-Origin：http：// localhost：8888」の送信は危険ですか？

最近、サイトで次のHTTPヘッダーを見つけました。これらのヘッダーは、少なくとも価値の高いターゲットとして説明できます。

Access-Control-Allow-Origin: http://localhost:8888
Access-Control-Allow-Methods: POST, GET, PUT, DELETE, OPTIONS
Access-Control-Allow-Headers: [some custom non-standard headers]

これは私には奇妙に見える、または少なくとも CORS RFC に準拠していない：

Access-Control-Allow-Originヘッダーは、応答でOriginリクエストヘッダーの値「*」または「null」を返すことにより、リソースを共有できるかどうかを示します。

戻り値が明らかにOriginリクエストヘッダー（または*またはnull）。だから、私の質問は：

  • これらのヘッダーを送信する正当な理由はありますか？私には、誤って本番環境に漏れてしまったテストで使用されているもののようです。
  • これを何らかの方法で悪用することは可能ですか？そのポートでは何かを実行しているユーザーはごく少数であり、攻撃者はとにかくそれを制御することができないため、私にはそう思われません。しかし、多分私は何かを見落としている。
  • これは問題のサイトに連絡して問題について通知することを保証するものですか？
web-applicationhttpcors
8
Anders

攻撃者がこのCORSヘッダーを利用するには、localhost：8888でJavascriptを実行する必要があります。あなたの質問に触発されて、私はlocalhost：8888で実行され、攻撃者がJavascriptを実行できるようにするサービスを探しました。私が見つけた：

[〜＃〜] mamp [〜＃〜] は、デフォルトでポート8888で実行されるWebStackであり、脆弱なSQLiteManagerが付属しています。 SQLiteManagerにはいくつかの脆弱性があり、そのうちの1つはCSRFを使用するXSSであるため、攻撃者はリモートでJavaScriptをトリガーしてlocalhost：8888のコンテキストで実行する可能性があります。その後、高価値のターゲットからデータを読み取ることができます。

この攻撃は、サイトの訪問者とMAMPのユーザーの両方であるユーザーに対してのみ機能するため、実際には起こりそうにありません。さらに、MAMPには リモートコード実行 の脆弱性もあるため、攻撃者はHTTP応答を読み取るためにCORSヘッダーを必要としません。

2
Sjoerd

これは、特にHSTSヘッダーを使用しない場合（とにかくHTTPのようにダウングレードする必要がない場合）は、典型的なMiTMシナリオで悪用可能であると思います-典型的なDNSスプーフィング攻撃は、被害者のIPを同じローカルネットワークにする可能性がありますlocalhost：8888ナビゲーションとして、それはあなたであると信じ、CORS応答で応答します。 -この種類のCORS応答ヘッダーを含むサイトが必要な理由が本当にわかりません

1
shinkurt