偽造防止トークンソルトの使用は何ですか?
-
05-07-2019 - |
質問
ASP.NET MVC 1.0には、クロスサイトリクエストフォージェリのセキュリティ問題を処理するための新しい機能があります。
<%= Html.AntiForgeryToken() %>
[ValidateAntiForgeryToken]
public ViewResult SubmitUpdate()
{
// ... etc
}
htmlフォームで生成されたトークンは、新しいフォームがレンダリングされるたびに変化し続けることがわかりました。
これらのトークンの生成方法を知りたいですか?また、ソフトウェアを使用してこのサイトをスキャンすると、別のセキュリティ問題が報告されます。セッションが修正されました。どうして?トークンは常に変更されているため、この問題はどのように発生しますか?
そして、別の関数、「塩」があります。 antiForgeryToken
の場合、これが何のために使用されているかは本当に知っています。トークンを生成するために、トークンは常に変化するので、なぜそのような機能があるのですか?
解決
AntiForgeryTokenに関する多くの情報はこちら: http://blog.codeville.net/2008/09/01/prevent-cross-site-request-forgery-csrf-using-aspnet-mvcs-antiforgerytoken-helper/
これは、クロスサイトリクエストフォージェリ(CSRF)を防ぐためです。フォームを「保存」をクリックしてサーバー上で何らかのアクションを実行する、つまりユーザーの詳細を保存するのは、かなり標準的な動作です。フォームを送信したユーザーが本人であることをどのように確認しますか?ほとんどの場合、CookieまたはWindowsベースの認証を使用します。
攻撃者が、あなたを少し隠されたIFRAMEでまったく同じフォームを送信するサイトに誘惑した場合はどうなりますか? Cookieはそのまま送信され、サーバーは正当なリクエストとは異なるリクエストを認識しません。 (Gmailが発見したように: http://www.gnucitizen。 org / blog / google-gmail-e-mail-hijack-technique / )
偽造防止トークンは、ページが生成されるたびに追加のCookieトークンを作成することにより、この形式の攻撃を防ぎます。トークンはフォームとCookieの両方にあります。フォームとCookieが一致しない場合、CSRF攻撃があります(攻撃者は上記の攻撃を使用して偽造防止トークンを読み取ることができないため)。
そして、上記の記事から、塩は何をしますか:
塩は単なる任意の文字列です。異なるソルト値は、異なる偽造防止トークンが生成されることを意味します。これは、攻撃者がなんとか有効なトークンを取得できたとしても、異なるソルト値が必要なアプリケーションの他の部分でトークンを再利用できないことを意味します。
更新:トークンはどのように生成されますか? ソースをダウンロードします、AntiForgeryDataSerializer、AntiForgeryDataクラスをご覧ください。
他のヒント
いくつかの無関係な問題を尋ねました:
- セキュリティソフトウェアが「セッション修正」を報告している理由がわかりません。レポートに付属のドキュメントを読んでみてください
- 偽造防止トークン:
これは、(おそらく)各リクエストが有効であることを検証するために使用されます。そのため、誰かがページ?x = 1
へのリンクを表示しようとすると、トークンも渡されない場合、リクエストは拒否されます。さらに、同じアイテムの重複した投稿を防ぐことができます。 「投稿」を2回クリックすると、トークンが変更される可能性があり(各リクエスト)、このようなケースは次のようなもので検出されます。
Session["nextToken"] = token;
WriteToken(token);
...
if( !Request["nextToken"] == Session["nextToken"] ){
...
}
// note: order in code is slightly different, you must take the token
// before regenerating it, obviously
これ(保護する攻撃)の用語は「CSRF」と呼ばれると思います。 (クロスサイトリクエストフォージェリー)、最近。