ジュリアンの答えからのリンクに基づいて、それは非常に簡単です。少し危険に見えますが、重大なことは何もありません。
ウェブの仕組み
あなたがウェブサイトを持っていると想像してください。ブラウザはそのWebサイトにHTTPトラフィックを送信します。このトラフィックにはセッションCookieが含まれます。サイトはTLSで保護されている必要があります。そうでない場合、セッションCookieは誰でも読めるようにクリアテキストでインターネットを介して送信されます。また、セッションCookie（およびその他の機密Cookie）を「セキュア」フラグで保護して、HTTPトラフィック経由で送信されないようにする必要があります。そうしないと、ブラウザは、クリアテキストのHTTPリクエストを傍受するサーバーに送信するだけです。また、HSTSを使用して、サーバーでのhttpの使用を防ぐことができます。
ブラウザがWebサーバーと通信しようとすると、IP-インターネットプロトコルを介して通信します。インターネットプロトコルはホスト名を使用せず、IPアドレスを使用します-127.0.0.1のように10進数で区切られた4つの値。ブラウザはdns *を使用して、接続するホスト名のIPアドレスを学習します。 Webサーバーには関連するDNSサーバーがあり、そのジョブは「このホストはどのIPアドレスですか」に応答することです。インターネット上のすべての名前付きホストは、DNSサーバーでサポートされています。 DNSが安全であると仮定します**;ブラウザは、実際のDNSサーバーからサーバーの実際のIPアドレスを取得します。
問題の設定ミスのクラス
しかし、DNSサーバーが正しく構成されておらず、間違ったIPアドレスを返すとどうなりますか？目的のサーバーが1.1.1.1のwww.example.comであり、サーバーがevil.comに属している6.6.6.6を返す場合がある場合、ブラウザーは何をしますか？ブラウザは6.6.6.6、evil.comに接続します。
さて、これは最初の赤面ではそれほど悪くありません。トラフィックがどのようにTLSで保護されているか覚えていますか？まあ、TLSはブラウザに6.6.6.6がexample.comではないことを検出させます。6.6.6.6にはexample.comの証明書に対応する秘密鍵がないためです。ブラウザはevil.comへの接続試行を拒否します。
ああ、でもTLSが6.6.6.6への接続に使用されていない場合はどうなりますか？その場合、リスクがあります。 Cookieでセキュアフラグを使用したことを覚えているため、Cookieは送信されません。ただし、あるドメインから提供されたページを別のドメインから提供されたページから保護する同じドメインポリシーは機能しなくなります。これらのサーバーは両方とも同じドメインにあります。理論的には、6.6.6.6の悪意のあるJavaScriptは、1.1.1.1が提供するページと対話できるはずです。これは悪いです。突然動作を開始する他の攻撃があるかもしれません。
ありがたいことに、この誤った設定は実際には起こりません。 example.comが所有するDNSサーバーは、evil.comのIPアドレスをexample.comを表すかのように処理する理由はありません。これを引き起こすタイプミスはありそうもない。タイプミスが発生した場合でも、攻撃者が機会の機会を利用する時間を確保する前に、ユーザーは停止に気づくでしょう。
問題の特定の設定ミス
しかし、一般的な設定ミスがあるとどうなりますか？セキュリティフォーカスメッセージには、ローカルホストの定義の最後にピリオドを置くのを忘れることがリストされています。サーバーが構成ファイルを解析する方法により、localhostは、完全修飾ドメイン自体ではなく、現在のドメイン内のホスト名として解釈されます。 example.comに戻ります。example.comがlocalhostを誤って定義している場合、localhost.example.comの解決可能なIPアドレスを取得します。
Example.comドメイン内に存在するlocalhost.example.comのこのルーティング可能なアドレスには、ループバックIPアドレスが割り当てられています。ループバックアドレスは、コンピュータが「自分」を意味することを知っている特別なアドレスです。ループバックアドレスに接続しようとすると、定義により、常にメッセージを送信するマシンに接続します。実際、ループバックアドレスが使用されている場合、ほとんどのオペレーティングシステムはメッセージをネットワークに送信することすらありません。トラフィックは完全にローカルマシンにとどまります。
影響
Evil.comが元の設定ミスでのexample.comの使用を攻撃するのと同じように、コンピューターはexample.comの使用を攻撃できます。リスクを実際に下げると思われる主なことは、攻撃者があなたと同じマシン上にいる必要があるということです。そうでない場合、ローカルマシンからブラウザへのHTTPトラフィックを提供するためのネットワークポートを開くことができません。
攻撃者がローカルマシンにいない場合、攻撃者はこの特定の設定ミスを利用できません。
例
これを試して、これがどのように機能するかを理解するのに役立つ例を見てみましょう。被害者のビクトリアは、vicki.com、IP 2.2.2.2へのシェルアクセスでログに記録されます。攻撃者のマロリーも、シェルアクセスでvicki.comにログインしています。他の攻撃者であるEvelynがevil.comを6.6.6.6で制御しています。
Vickiはvicki.comシェル内でWebブラウザーを開き、example.comドメインにlocalhostを含めるように誤って構成されたDNSエントリがあるexample.comを参照します。 Vickiは周りをクリックして何かを行い、最終的には何らかの理由でlocalhost.example.comへのリンクをたどります。
マロリーはこの不測の事態に備えました。彼はvicki.comで悪意のあるJavaScriptを使用してHTTPサーバーを実行しています。 Vickiのブラウザは、Malloryの悪意のあるページをロードし、JavaScriptペイロードを実行します。 MalloryのJavaScriptは、example.comのvickiのアカウントにアクセスできるようになり、vickiが実行できるすべてのことをvickiとして実行できるようになりました。ヴィッキが今彼女だけに送られたプライベートメッセージを読むことができれば、マロリーもできる。彼女がユーザーアカウントを削除できたら、今度はマロリーも削除できます。マロリーは、文字通り、Vickiがブラウザを閉じるまで、Vickiが行うのと同じレベルのVickiのアカウントへのアクセスです。***マロリーは、文字通り、別の攻撃方法を使用してクロスサイトスクリプティングペイロードを配信しました。
ここではEvelynは何もせず、evil.comは機能しませんでした。同じサイトのスクリプティングでは、攻撃者はあなたがいるのとまったく同じマシン上にいる必要があります。 Evelynには、vicki.comへのそのようなアクセス権がありません。 evil.comには、vicki.comへのそのようなアクセス権がありません。
また、Vickiはブラウザにlocalhostをロードする必要があったことにも注意してください。サーバーには通常localhostへのリンクが含まれていないため、vickiに悪意のあるページを読み込ませるには、何らかのソーシャルエンジニアリングが必要になる可能性があります。
リスク：中
構成の誤り、攻撃者が既にシステムに存在していること、および攻撃を実行するためのソーシャルエンジニアリングの必要性の間では、これはすべて深刻ではありません。 CVSSv2でスコアを付ける必要がある場合は、vickiが例の管理者であると想定して、6.0（AV：L/AC：H/Au：S/C：C/I：C/A：C）を与えます。 com、彼女のWebアクセスには完全な管理アクセスが含まれます。 cvssのNVD範囲はこれらのメディアを呼び出します（ https://nvd.nist.gov/cvss.cfm ）
「同じサイトのスクリプト」という名前について
セキュリティ分野の多くの名前と同様に、これは少し誤称です。 xss攻撃を実行しているのは、実際には同じサイトではありません。同じドメインですが、サイトはローカルマシンであり、問題のWebサイトではありません。これは、xss/JavaScriptインジェクションの問題でもありませんが、同じドメインポリシーをバイパスし、ローカルホストからのインジェクトされていないJavaScriptが、誤って構成されたドメインによって提供されるページのコンテキストで実行できるようにするDNSの構成ミスです。
「DNSの誤った構成による同じドメインポリシーのバイパス」のような名前を付けた方がより正確でしたが、それほどセクシーではありません。
文末脚注
*私は、システムのリゾルバーを使用してすべての詳細を故意に省略し、この回答を合理的な長さに保ち、詳細で読者を失わないようにします。
**それは完全に安全ではないことを知っていますが、答えた質問に焦点を当てることができるようにそれを偽っています
***マロリーが彼のアクセスを持続することを可能にする他の脆弱性がないと仮定します。
私はこれのすべての詳細を理解するふりをすることはできませんが、これは危険であるように見えますします。
元の投稿 こちら を参照してください。
これは表面的には無害に見えるかもしれませんが、実際には攻撃者がRFC2109（HTTP状態管理メカニズム）と同じOriginの制限を騙し、したがって状態管理データを乗っ取ることができます。
このわずかな設定ミスの結果、影響を受けるドメインのサイトにマルチユーザーシステムから安全にアクセスすることができなくなります。攻撃は簡単です...