クロスドメインAjaxがセキュリティ上の懸念事項であるのはなぜですか？
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サーバーは、これらすべてのフォームを送信するのが通常のユーザーだけではないことを認識できません。
AjaxHTTPリクエストがドメインの境界を越えることが許可されていないのはなぜですか。
AJAXリクエストは（a）ユーザー資格情報を使用して送信され、（b）呼び出し元が返されたデータを読み取れるようにするためです。
脆弱性をもたらす可能性があるのは、これらの要因の組み合わせです。ユーザー資格情報を省略したクロスドメインAJAXの形式を追加する提案があります。
img、script、またはiframe要素をドキュメントに追加するだけです。
これらのメソッドはいずれも、呼び出し元が返されたデータを読み取ることを許可しません。
（許可されたクロスドメインスクリプティングのために、それを許可するように意図的に設定されているスクリプト、または誰かがひどいコックアップを行ったスクリプトを除きます。）
これをまったく使用せずにXSS攻撃を行うことができます。サードパーティのサイトへの投稿
それはXSS攻撃ではありません。これはクロスサイトリクエストフォージェリ攻撃（XSRF）です。 XSRF攻撃を解決する既知の方法があります。たとえば、送信がユーザーから意図的に送信されたものであり、攻撃者のコードから起動されたものではないことを確認するための1回限りのトークンまたは暗号化トークンを含めるなどです。
クロスドメインを許可した場合AJAXこのセーフガードは失われます。攻撃コードは銀行サイトからページを要求し、そのページの認証トークンを読み取り、すぐに送信する可能性がありますAJAX転送を実行するように要求します。そして、それはwouldクロスサイトスクリプティング攻撃です。
POST間の重要な違い：
<body onload="document.getElementById('InvisbleForm').submit()" ...
そしてAjaxは、POSTを実行した後、ブラウザがページを置き換え、Ajax呼び出しを実行した後ではありません。 POSTの結果は次のようになります。
- ユーザーにはっきりと見える。
my-bank.comからの応答ページが制御するため、この時点で攻撃はスタックします。 ワンクリック転送を実装する銀行はありません。
XSRFのシナリオは、クロスドメインAjaxが許可される場合、次のようになります。
- ユーザーはどういうわけか
www.bad-guy.comにアクセスします。 - ブラウザの他のインスタンスで
my-bank.comに開かれたページがない場合、攻撃は失敗します。 - ただし、そのようなページが開かれ、ユーザーがすでにユーザー名/パスワードを入力している場合、これは、ブラウザーのキャッシュにこのセッションのCookieがあることを意味します。
www.bad-guy.comのページのJavaScriptコードは、my-bank.comへのAjax呼び出しを行います。- ブラウザの場合、これは通常のHTTP呼び出しであり、my-bankCookieを
my-bank.comに送信する必要があり、それらを送信します。 - 銀行は、この呼び出しをユーザーの通常のアクティビティと区別できないため、この要求を処理します。
- JavaScriptコードが応答を読み取ることができるという事実は重要ではありません。攻撃の場合、これは必要ないかもしれません。本当に重要なのは、コンピューターの前にいるユーザーは、この対話が行われていることに気付かないということです。彼は
www.bad-guy.comページで素敵な写真を見るでしょう。 - JavaScriptコードは、必要に応じて
my-bank.comを他にもいくつか呼び出します。
要点は、インジェクションやページの改ざんは必要ないということです。
より良い解決策は、呼び出し自体を許可するが、Cookieを送信しないことです。これは非常にシンプルなソリューションであり、大規模な開発は必要ありません。多くの場合、Ajax呼び出しは保護されていない場所に送信され、Cookieを送信しないことは制限されません。
現在議論されているCORS（Cross Origin Resource Sharing）は、とりわけ、Cookieの送信/非送信について説明しています。
そうですね、そう感じているのはあなただけではないようです...
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など）を許可する提案が進行中のようですが、自分のサイトのコードを書いているときにそれらがあったらいいのにと思います:)そして互換性の問題があります...ユビキタスになるまでにはしばらく時間がかかります。
サーバーに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）と呼ばれます。これについての詳細は ウィキペディア にあります。
これは主に、同一生成元ポリシーが存在し、ブラウザがOriginとは異なるドメインでXMLHttpRequestsを実行することを許可しないこの理由によるものです。
クロスドメインXHRを実際に許可するために進行中の議論がいくつかありますが、これが本当に受け入れられるかどうかを確認する必要があります。
<form>を使用すると、データを投稿することはできますが、読み取ることはできません。 XHRを使用すると、両方を実行できます。
http://bank.example.com/display_my_passwordのようなページは、XSRF（パスワードを表示するだけで設定しないと仮定）およびフレーム（同一生成元ポリシー）に対して安全です。ただし、クロスドメインXHRは脆弱性になります。
あなたが言ったように、それは悪い目的に使われる可能性があるので、それは懸念です。また、意図的に使用することもできるため、クロスドメインプロトコルが開発されています。
2つの最大の懸念は、クロスサイトスクリプティング（XSS）およびクロスサイトリクエストフォージェリ（CSRF）と組み合わせて使用する場合です。どちらも深刻な脅威です（そのため、OWASPトップ10とSANS 25になりました）。
それが悪用されているのを私が見ることができる唯一の方法は、誰かがJavascriptを注入した場合です
これはXSSです。まだ脆弱なアプリが多すぎます。ブラウザのセキュリティモデルでXドメインAJAXが妨げられない場合、ユーザーはかなりの攻撃経路にさらされています。
ドキュメントにimg、script、またはiframe要素を追加するだけで、サードパーティのURLをリクエストできます。
はい。ただし、これらはHTTP_REFERRERを送信し、（他の方法で）CSRFを防ぐためにブロックすることができます。 AJAX呼び出しはヘッダーをより簡単にスプーフィングでき、従来のCSRF保護を回避する他の手段を可能にします。
これを通常のXSRF攻撃と区別するもう一つの点は、javascriptを介して取得したデータでも処理できることだと思います。
大きな問題が何なのかわかりませんか？ AJAX呼び出しを他のドメインに送信し、アプリケーションに送信してから、フィルター処理されたデータを使用して他の場所に転送し、本当に必要な場合は返されたデータを解析して、ユーザーにフィードします。
機密性の高いAJAXリクエストを処理しますか？ヘッダーをチェックするか、セッション時間データを保存するか、信頼できるソースまたはアプリケーションに着信IPアドレスをフィルタリングすることで、着信吸盤を釘付けにします。
私が個人的に将来見たいのは、Webサーバー、フレームワーク、CMSでデフォルトですべての受信リクエストに対して堅固なセキュリティを確保し、外部ソースからのリクエストを解析するリソースを明示的に定義することです。
疑いを持たない訪問者をサービス拒否攻撃者に変えます。
また、Facebookのものをすべて盗むクロスサイトスクリプトを想像してみてください。 IFrameを開き、Facebook.comに移動します
あなたはすでにFacebook（cookie）にログインしていて、データ/友達を読み取ります。そして、より厄介なことをします。