web-dev-qa-db-ja.com

ランダムなWebページがhttp://127.0.0.1/private.txtに対してAjaxリクエストを行った場合はどうなりますか？

私は自分のマシンではなく、すべての管理パネルに対してlocalhost-only Webサーバー（PHPの組み込みのもの）を実行しています。ランダムなWebページに http://127.0.0.1/private.txt へのAjax呼び出しを行うJavaScriptスニペットがあり、そのWebページにアクセスすると、ブラウザーが作成されるのではないかと心配しています。 （Firefox）そのURLから返されたすべてのデータをフェッチし、それを使用して、たとえば別のAjaxリクエストで自分のサーバーにデータを送り返すことができます。

http://127.0.0.1/private.txt が1958年以降の私の日記全体を返すと仮定しましょう。私は絶対に自分のFirefoxブラウザー以外のものとやり取りしたくありませんが、私が考えられる限りでは、これは大きなプライバシー/セキュリティ問題になる可能性があります。このリクエストが許可されるという私の考えが間違っているといいのですが。何らかの「クロスドメインポリシー」がそれをブロックしているといいのですが。特に127.0.0.1からなので、これはある種の特別なケースになるはずです。

これを止めるのは何でしょうか？私の推論で何が欠けていますか？

privacyhttpfirefoxsecurity-theater
9
ParanoidAndroid

読書

クロスオリジンリソースシェアリング [〜＃〜] cors [〜＃〜] と同一生成元ポリシー [〜＃〜] sop [〜＃〜] はここに友達です。問題のJavaScriptはhttp://127.0.0.1でホストされていないため、SOPに違反し、ブラウザのCORSのデフォルトルールによりJavaScriptがreading =応答それはあなたの当面の質問をカバーします-あなたはデフォルトで保護されています。

書き込み

ただし、その「読む」部分が重要です。ブラウザは、すべての状況でサーバーにリクエストを送信します。 CORSが行う唯一のことは、JavaScriptが応答を受信しないようにすることです。そのため、CORSは攻撃者が他の場所からデータを読み取ることを阻止しますが、他の場所へのデータの送信を阻止しません。

その結果、リクエストの受信によりアプリケーションが重要な状態変更を行うと、問題が発生する可能性があります。有益なことに、CSRFトークンはそのような攻撃からユーザーを保護します。明確にするために、攻撃者が他の場所にリクエストを送信するためにJavaScriptは必要ありません（ h/t mti2935 ）-アクセスしたページに埋め込まれたimgタグは、任意のサーバーにGETリクエストをトリガーし、サーバーがGETリクエストの結果としてアクションを実行した場合、攻撃者が望ましくないアクションをトリガーするのは特に簡単です。

したがって、アプリケーションがCSRF保護なしで状態変更を行い、攻撃者がエンドポイントについて知っている場合、問題が発生している可能性があります。実際の例では、安全ではなく一般的に使用されているルーターがこのように悪用されています。ホームルーターによってホストされているWebアプリケーションの次の架空のURLについて考えてみます。

http://admin:[email protected]/enable_remote_admin_access

リモート管理アクセスを可能にし（別名、インターネットからルーターの管理セクションにログインできるように構成を調整します）、既知のURLを持ち、基本認証が必要です。ルーターには、よく知られたデフォルトのユーザー名とパスワードが付属しています。 （admin：admin）。その結果、攻撃者は上記のURLに単純なGETリクエストを行うWebページを作成します。攻撃者はルーターから応答を受け取りません（CORSのため）が、ルーターは引き続き要求を受信し、脆弱であれば、インターネットからの管理者接続を受け入れる準備ができています。次に、悪意のあるスクリプトが被害者のIPアドレスを使用して自宅に電話をかけ、別の簡単なスクリプトがIPアドレスをチェックして、アクセス可能なルーターがあるかどうかを確認します。その場合、攻撃者が間違ったページにアクセスし、共通の脆弱なルーターを使用していたために、攻撃者は被害者のホームネットワークを完全に制御できるようになります。

算術

もちろん、カスタムアプリケーションはブラインドアタックであるため、このような利点を活用することははるかに困難です。彼らが何を攻撃しているかについての情報がなければ、成功することはほぼ不可能です。その結果、攻撃対象領域が非常に小さいため、実際のリスクレベルは低くなる可能性があります。それでも、覚えておくべきいくつかの警告があります：

  1. 標的型攻撃が発生した場合、すべての賭けはオフになります。攻撃者が、脆弱性のあるソフトウェアをローカルで実行していることを知っている場合は、間違ったリンクにアクセスする必要があります。
  2. CORS設定は重要です。ローカルアプリが過度に寛容なCORS構成を使用している場合、攻撃者could結果を読み取り、アプリケーションを「参照」します。
  3. ネットワークの構成方法によっては、基本的なポートスキャンが可能になる場合があります。
  4. DNS rebinding （ h/t EdC ）は、攻撃者がSOPおよびCORSを回避することを可能にする可能性があります。このような攻撃には障害が存在する可能性があります。しかし、断固とした攻撃者はそれを使用することで成功の確率を向上させることができます。
11
Conor Mancone