42

XML呼び出しを行うためにXMLHTTPRequestを使用しても、ドメイン境界を越えて呼び出しを行うべきではないと決定されたのはなぜですか?JavaScript、画像、CSS、iframe、および他のドメインから考えられる他のほぼすべてのコンテンツを取得できます。Ajax HTTPリクエストがドメインの境界を越えることが許可されていないのはなぜですか?それが悪用されているのを私が見ることができる唯一の方法を考えると、誰かがJavascriptをページに挿入した場合、それを置くのは奇妙な制限のように思えます。ただし、この場合、ドキュメントにimg、script、またはiframe要素を追加するだけで、サードパーティのURLを要求してサーバーに送信できます。

[編集]

いくつかの回答は次の理由を指摘していますが、これを許可しない主な理由を作成しない理由を指摘しましょう。

XSRF(クロスサイトリクエストフォージェリ、CSRF、XSRFとも呼ばれます)

これをまったく使用せずにXSRF攻撃を行うことができます。原則として、XMLHTTPRequestはまったく使用されません。これは、すべての主要なブラウザーと互換性のある方法でXMLHTTPRequestを作成することが非常に難しいためです。URLをロードする場合は、URLにimgタグを追加する方がはるかに簡単です。

サードパーティのサイトへの投稿

<script type="text/javascript">
  $.post("http://some-bank.com/transfer-money.php", 
         { amount: "10000", to_account: "xxxx" })
</script>

で達成することができます

<body onload="document.getElementById('InvisbleForm').submit()"
    <div style="display:none">
        <form id="InvisbleForm" action="http://some-bank.com/transfer-money.php" method="POST">
            <input type="hidden" name="amount" value="10000">
            <input type="hidden" name="to_account" value="xxxxx">
        </form>
    </div>
</body>

JPunyon:なぜこの脆弱性を新機能に残すのですか?

あなたはこれ以上不安を生み出していません。あなたはそれを良い方法で使いたいと思っている開発者に不便をかけているだけです。この機能を悪(別名素晴らしい)に使用したい人は、他の方法を使用することができます。

結論

彼が重大な問題を指摘したので、私はbobinceからの答えを正しいとマークしています。XMLHTTPRequestを使用すると、クレデンシャル(Cookie)を使用して宛先サイトに投稿し、サイトから返送されたデータを読み取り、個人のクレデンシャルを送信できるため、確認フォームを含む一連のフォームを送信するJavaScriptを調整できます。 、XSRFを防止するために配置されたランダムキーが生成された状態で完了します。このようにして、銀行のようにターゲットサイトを閲覧することができ、銀行のWebサーバーは、これらすべてのフォームを送信するのは通常のユーザーだけではないことを認識できません。

4

9 に答える 9

37

Ajax HTTP リクエストがドメイン境界を越えることが許可されていないのはなぜですか。

AJAX 要求は (a) ユーザー資格情報と共に送信され、(b) 呼び出し元は返されたデータを読み取ることができるためです。

これらの要因が組み合わさった結果、脆弱性が発生する可能性があります。ユーザー資格情報を省略したクロスドメイン AJAX のフォームを追加する提案があります。

img、script、または iframe 要素をドキュメントに追加するだけです

これらのメソッドのいずれも、呼び出し元が返されたデータを読み取ることを許可しません。

(許可されたクロスドメイン スクリプティングのために意図的にそれを許可するように設定されているスクリプト、または誰かがひどいコックアップを作成したスクリプトを除きます。)

これをまったく使用せずに XSS 攻撃を行うことができます。第三者サイトへの投稿

それは XSS 攻撃ではありません。それがクロスサイト リクエスト フォージェリ攻撃 (XSRF) です。XSRF 攻撃を解決する既知の方法があります。たとえば、ワンタイム トークンまたは暗号化トークンを含めて、送信がユーザーから意図的に送信されたものであり、攻撃者のコードから起動されたものではないことを確認します。

クロスドメイン AJAX を許可すると、このセーフガードが失われます。攻撃コードは、銀行サイトからページを要求し、そのページ上の認証トークンを読み取り、2 番目の AJAX 要求でそれらを送信して転送を実行する可能性があります。そして、それクロスサイト スクリプティング攻撃になります。

于 2009-01-21T20:53:22.333 に答える
8

POST との重要な違い:

<body onload="document.getElementById('InvisbleForm').submit()" ...

そしてAjaxは、POSTを実行した後、ブラウザがページを置き換え、Ajax呼び出しを実行した後ではありません。POST の結果は次のようになります。

  1. ユーザーにはっきりと見えます。
  2. my-bank.comからの応答ページが制御を引き継ぐため、攻撃はこの時点で停止します。ワンクリック送金を実装する銀行はありません。

クロスドメイン Ajax が許可される場合、XSRF のシナリオは次のようになります。

  1. ユーザーが何らかの方法で にアクセスしwww.bad-guy.comます。
  2. ブラウザの他のインスタンスで開いているページがない場合my-bank.com、攻撃は失敗します。
  3. しかし、そのようなページが開かれ、ユーザーがすでにユーザー名/パスワードを入力している場合、これは、ブラウザーのキャッシュにこのセッションの Cookie があることを意味します。
  4. からのページの JavaScript コードが へwww.bad-guy.comの Ajax 呼び出しを行いmy-bank.comます。
  5. ブラウザーの場合、これは通常の HTTP 呼び出しであり、my-bank の Cookie を送信する必要がmy-bank.comあり、それらを送信します。
  6. 銀行は、この呼び出しをユーザーの通常のアクティビティと区別できないため、この要求を処理します。
  7. JavaScript コードが応答を読み取ることができるという事実は重要ではありません。攻撃の場合、これは必要ないかもしれません。本当に重要なのは、コンピュータの前にいるユーザーが、このやり取りが行われていることに気付かないことです。彼はwww.bad-guy.comページ上の素敵な写真を見ます。
  8. これが必要な場合、 JavaScript コードは他のいくつかの呼び出しを行いmy-bank.comます。

要点は、インジェクションやページの改ざんが必要ないということです。

より良い解決策は、呼び出し自体を許可し、Cookie を送信しないことです。これは、大規模な開発を必要としない非常に単純なソリューションです。多くの場合、Ajax 呼び出しは保護されていない場所に送られ、Cookie を送信しなくても制限はありません。

現在議論されている CORS (Cross Origin Resource Sharing) は、とりわけ、Cookie を送信する/送信しないことについて述べています。

于 2012-10-12T23:12:28.730 に答える
2

まあ、どうやらあなただけがそのように感じているのではありません...

http://www.google.com/search?q=xmlhttp+cross+site

編集:上記の検索からリンクされた興味深い議論があります:

http://blogs.msdn.com/ie/archive/2008/06/23/securing-cross-site-xmlhttprequest.aspx

クロスサイトxmlhttpリクエスト(IE 8、FF3など)を許可する提案が進行中のようですが、自分のサイトのコードを書いているときにそれらがあったらいいのにと思います:)そして互換性の問題があります...どこにでもあるようになるまでにはしばらく時間がかかります。

于 2009-01-21T20:11:41.263 に答える
2

サーバーにHTTPリクエストを送信すると、サーバーによって設定されたCookieもブラウザによってサーバーに返送されます。サーバーはこれらのCookieを使用して、ユーザーがログインしていることなどを確認します。

これは、JavaScriptの助けを借りて、ユーザーがこれについて何も知らなくても、他のWebサイトで情報を盗んだり不正なコマンドを実行したりする悪意のある攻撃者によって悪用される可能性があります。

たとえば、次のJavaScriptコード(jQueryを想定)があるサイトにアクセスするようにユーザーに依頼できます。

<script type="text/javascript">
  $.post("http://some-bank.com/transfer-money.php", 
         { amount: "10000", to_account: "xxxx" })
</script>

上記のコードの実行中にユーザーが実際に銀行にログインした場合、攻撃者はアカウントXXXに10,000米ドルを送金した可能性があります。

この種の攻撃は、クロスサイトリクエストフォージェリ(XSRF)と呼ばれます。これについての詳細はウィキペディアにあります。

これは主に、同一生成元ポリシーが存在するためであり、ブラウザーでは、生成元とは異なるドメインでXMLHttpRequestsを実行できません。

クロスドメインXHRを実際に許可するためにいくつかの議論が行われていますが、これが実際に受け入れられるかどうかを確認する必要があります。

于 2009-01-21T20:18:28.800 に答える
1

<form>データを投稿することはできますが、読むことはできません。あなたと一緒XHRに両方を行うことができます。

Page likehttp://bank.example.com/display_my_passwordは、XSRF(パスワードを設定せずに表示するだけであると想定)およびフレーム(同一生成元ポリシーを持っている)に対して安全です。ただし、クロスドメインXHRは脆弱性になります。

于 2009-01-21T20:59:48.063 に答える
1

あなたが言ったように、それは悪い目的に使われる可能性があるので、それは懸念です。また、意図的に使用することもできるため、クロスドメインプロトコルが開発されています。

2つの最大の懸念事項は、クロスサイトスクリプティング(XSS)およびクロスサイトリクエストフォージェリ(CSRF)と組み合わせて使用​​する場合です。どちらも深刻な脅威です(そのため、OWASPトップ10とSANS 25になりました)。

私がそれが悪用されているのを見ることができる唯一の方法は、誰かがJavascriptを注入した場合です

これはXSSです非常に多くのアプリがまだ脆弱であり、ブラウザのセキュリティモデルがXドメインAJAXを妨げない場合、それらはユーザーをかなりの攻撃ベクトルにさらしています。

ドキュメントにimg、script、またはiframe要素を追加するだけで、サードパーティのURLをリクエストできます。

はい。ただし、これらはHTTP_REFERRERを送信し、CSRFを防ぐために(他の方法で)ブロックすることができます。AJAX呼び出しは、ヘッダーをより簡単にスプーフィングでき、従来のCSRF保護を回避する他の手段を可能にします。

于 2009-01-21T20:28:17.720 に答える
1

これを通常のXSRF攻撃と区別するもう一つの点は、javascriptを介して取得したデータでも処理できることです。

于 2009-01-21T20:34:53.883 に答える
1

何が大きな問題なのかわからない?AJAX 呼び出しを他のドメインに送信し、最初にアプリケーションに送信してから、フィルタリングされたデータで別の場所に転送し、本当に必要な場合は返されたデータを解析し、それをユーザーにフィードします。

機密性の高い AJAX リクエストを処理しますか? ヘッダーをチェックしたり、セッション時間データを保存したり、受信した IP アドレスを信頼できるソースやアプリケーションに絞り込んだりして、受信した吸盤を突き止めます。

私が将来的に見たいと思っているのは、Web サーバー、フレームワーク、および CMS でデフォルトですべての着信要求に対して強固なセキュリティを確保し、外部ソースからの要求を解析するリソースを明示的に定義することです。

于 2009-01-21T20:43:11.793 に答える
0

疑いを持たない訪問者をサービス拒否攻撃者に変えます。

また、Facebookのものをすべて盗むクロスサイトスクリプトを想像してみてください。IFrameを開き、Facebook.comに移動します

あなたはすでにFacebook(cookie)にログインしていて、データ/友達を読み取ります。そして、より厄介なことをします。

于 2009-01-21T20:09:31.720 に答える