クロスサイトフォレージを防止する方法について少し混乱します。まだ。私はそこに豊富な情報があることを知っていますが、私は混乱しています。AJAXサービスでのクロスサイト偽造
はSteven Anderson's postでは、彼は次のようにフォームを説明します
<body onload="document.getElementById('fm1').submit()">
<form id="fm1" action="http://yoursite/UserProfile/SubmitUpdate" method="post">
<input name="email" value="[email protected]" />
<input name="hobby" value="Defacing websites" />
</form>
</body>
他の誰かのサイトで。
解決策は、サーバによって生成された "偽造防止"トークンで、隠された形式のリクエストでPOSTされます。それはクールですが、ハッカーがフォームページをダウンロードし、トークンを抽出してそれをポストするのを止めるのは何ですか？
私のウェブサイトへのサインアップでは、現在入力されているユーザー名をサーバーに送信するAJAX機能が必要です（使用可能かどうかに応じて「真/偽」と回答する必要があります）。これはonKeyが発生するため、ユーザーはまだ使用されていないユーザー名を選択できます。 「新規ユーザー」の条件がすべて満たされると、「送信」ボタンが有効になります。
明らかに、これはハッカーがサービスを利用して利用可能かどうかを「テスト」するための機会です。インターネットバンキングレベルのリスクではないことはわかっていますが、ハッカーではなく、私のアプリケーションからのリクエストだけです。
これらのクエリはどのように考えられますか？
UPDATE：私のシナリオでは、だから、
。トークン（クライアントのIPアドレスのハッシュされた値）を生成し、ユーザー名が利用可能かどうかについての情報があれば、サービスはこれを受け取ることを期待しています。
- ドメイン外のユーザーが単にサービスを呼び出しているなどの問題が残ります。 /generateTokenこれはクライアントのIPを見ています...知っているハッカーかもしれません。その後、/ isUsernameAvailableに提出され
戻り
{ token: 4uru32br }
？トークン= 4uru32br & partialUsername = usernam
それは私を得るのでしょうか？
"ハッカーがフォームページをダウンロードするだけで、トークンを抽出してポストするのは何ですか？ハッカーは、被害者の代わりに自分のトークンを落とします。 – PeeHaa
CSRFトークンは、リクエスト偽装とはまったく異なる問題であるため、ログイン試行を抑制していません。 – PeeHaa