CSRFとは何ですか
また、「ワンクリックアタック」やセッション乗馬として知られているCSRF（クロスサイトリクエストフォージェリ）、クロスサイトリクエストフォージェリは、多くの場合、CSRFまたはXSRFと略記、サイトの悪質な使用です。それは、クロスサイトスクリプティング（XSS）のように聞こえるが、それはXSSとは非常に異なっているがCSRFは、信頼できるサイトから使用する信頼できるユーザーの要求によって変装している間、XSSは、サイトの利用でユーザーを信頼できます。XSS攻撃と比較すると、CSRF攻撃は、多くの場合、非常に人気がありません（したがって、そのリソースを防ぐために非常にまれである）と擁護することは困難で、それがXSSよりも危険と考えられています
理解することができます：
攻撃者は自分の名前にこの要求のためにサーバーに悪質なリクエストを送る、あなたのアイデンティティを盗んは完全に正当なものであるが、攻撃者は、このような自分の名前で送信するよう、必要なアクションを完了します電子メール、メッセージング、システム管理者、および、そのような仮想通貨転送などの商品のさえ購入を追加し、あなたのアカウントを盗みます。次のように：ウェブウェブプレゼンスCSRFの脆弱性、悪質なWebサイトを構築するために攻撃者のWeb Bである場合、ユーザCは、正当なユーザーのWebサイトです
CSRF攻撃
図は次のとおりです。
CSRF攻撃を完了するために、図からわかるように、被害者は順番に2つのステップを完了する必要があります。
信頼済みサイトA、およびローカルにクッキーを生成にログインします。
Aの場合は2は、外のB.危険なWebサイトへのアクセスではありません
ここを参照してください、あなたは言うかもしれない：「私は2つの条件の複数を満たしていない場合、私はCSRF攻撃ではないでしょう。」はい、それはありませんが、あなたは状況が発生しないという保証はありません。
1.あなたは、Webサイトにログオンすることを保証することはできません、ページがタブを開いて、別のサイトを訪問しないであろう。
2.あなたは、あなたのブラウザを閉じた後、あなたの地元のクッキーはすぐに、あなたの最後のセッションが終了した有効期限が切れていることを保証することはできません。（実際には、......会話を終了することはできません、ブラウザを閉じて、ほとんどの人が誤って閉じているブラウザは/ログインアップセッションを終了することと等価であると信じています）
3.上記の図は、攻撃サイト、他の脆弱性が存在し、サイト頻繁にアクセスすることができる、信頼できる人と呼ばれます。
CSRF攻撃防止
;要求にトークンを追加し、アドレスを確認し、HTTPヘッダーのカスタムプロパティと検証のHTTPのRefererフィールドを確認します。現在、防衛CSRFは、3つの主要な戦略があります攻撃します
（1）フィールドHTTPリファラを確認
HTTPプロトコルに従って、リファラーHTTPヘッダーと呼ばれるフィールドは、HTTPリクエストの送信元アドレスを記録し、そこです。通常の状況下では、要求は、アクセスする必要として、同じサイトからのセキュリティ制限ページにアクセスするには、HTTP :? //Bank.example/withdrawアカウント=ボブ＆量を= 1000000＆=のためにマロリーは、 ユーザーが最初にログインする必要がありますで、その後、bank.example転送イベントをトリガするために、ページ上のボタンをクリックしてください。このとき、転送要求のリファラー値は、通常、ドメインアドレスbank.exampleの初めに、転送ボタンページのURLになります。ハッカーは、銀行のウェブサイトでCSRF攻撃を実装する場合、ユーザーがハッカーによって銀行のウェブサイトにリクエストを送信したとき、彼は彼自身の要求の建設現場で、要求のリファラーは、ハッカー自身のサイト向けられていることができます。そのため、防衛CSRF攻撃に、サイトがドメイン名だけがbank.example始まりがあれば、その要求は、自分の銀行のサイトからのリクエストで正当なものである、その値を確認し、各転送リファラーのために銀行に依頼する必要があります。サイトリファラー言い換えるならば、ハッカーCSRF攻撃は、要求を拒否することが可能です。
この方法の明白な利点は単純で、通常のウェブサイトの開発者は、CSRFの脆弱性を心配する必要はありません、唯一の我々はそれに最後のリファラーの値をチェックするために、追加のインターセプタすべてのセキュリティに敏感な要求を統一する必要があります。特に、現在、既存のシステムのために、非常に便利なリスクがない、現在のシステムの既存のコードとロジックを変更する必要はありません。
しかし、この方法では万全ではありません。リファラ値はHTTPプロトコル上の明確な要求があるが、ブラウザによって提供されるが、各ブラウザがリファラの特定の実装のために異なる場合があり、それは、ブラウザ自体がセキュリティ上の脆弱性ではないことを保証するものではありません。リファラー検証値を使用して、それを保証するために第三者（つまりブラウザ）の安全性に依存することで、理論的には、これは安全ではありません。実際には、このようIE6やFF2などの一部のブラウザ、のために、リファラー値を改ざんするには、いくつかの方法が既に存在しています。あなたが検証できるようにbank.exampleサイトのサポートIE6ブラウザ場合、ハッカーは、CSRF攻撃を実行するために、bank.exampleドメイン名の先頭のアドレスに設定されているユーザのブラウザのリファラー値を置くことができます。
でも、最新のブラウザを使用して、ハッカーがリファラー値を改ざんすることはできませんが、この方法は疑問のままです。リファラー値がソースへのユーザーのアクセスを記録しますので、一部のユーザーは、特にいくつかのグループは、組織内の情報の一部は、ネットワーク内のリファラー値が外部ネットワークに流出することを心配し、これが自分のプライバシーを侵害するだろうと信じています。リクエストを送信するとき、それはもはやリファラーを提供するようにこのように、ユーザ自身がブラウザを設定することはできません。彼らは通常、銀行のウェブサイトを訪問すると、サイトリファラー値要求は思わなかったので、そのCSRF攻撃、正当なユーザーへのアクセスの拒否。
（2）リクエストトークンと認証のアドレスを追加します
ハッカーが完全にユーザの要求を偽造することができますので、CSRF攻撃が成功することができたハッカーが直接認証情報を知らなくても、ユーザー自身でクッキーを使用することができますので、すべてのユーザ認証情報の要求は、クッキーに存在していますセキュリティ検証を渡します。ハッカーにキー情報を要求に偽造されず、情報がクッキーに存在しないことを特徴CSRFを、抵抗します。要求が正しいトークンまたはトークンではないではない場合トークンランダムにHTTPリクエストのパラメータとして生成され、迎撃サーバ側の確立がトークンを認証するために添加することができる、おそらくCSRF攻撃は要求を拒否すると考えられています。
この方法では、リファラーチェックのいくつかのより安全であるユーザがセッションからログアウトした後にトークンが、セッション中に発生し、配置することができ、その後、各要求にトークン、リクエストトークンと比較する、しかし困難メソッドは、パラメータとしてリクエストトークンを結合する方法です。それはURLのなるように、GET要求の後、トークンは、要求アドレスに添付されますHTTP：// URL csrftoken = tokenvalue？ 。プットトークン要求は、パラメータとして追加されるように、POSTリクエストのために、フォームに、最後に追加されます。しかし、それぞれの要求はトークンを追加するためにあなたは、非常に多くの要求を受け入れることができ、サイト、非常に面倒であり、欠場するのは簡単です、一般的に使用される方法は、すべての時間が横断するためにはJavaScriptを使用して、ページがロードされますすべてのラベルとDOMの形のDOM全体の木はトークンを追加しました。このような要求は、ほとんどを解決しますが、ページがロードされた後、動的に生成されたHTMLコードのために、このメソッドは効果がありません、プログラマは手動でコーディングにトークンを追加する必要があります。
もう一つの欠点は、この方法は、セキュリティトークン自体を保証することは困難であるということです。特に、ユーザーが独自のコンテンツを公開することを可能にするサイトのようないくつかのフォーラムでは、ハッカーは、上記のアドレスで、あなた自身の個人的なウェブサイトを公開することができます。システムが戻ってこのアドレスに加えてトークンになりますので、ハッカーは、自身のウェブサイト上でこのトークンを取得することができ、我々はすぐにCSRF攻撃を開始することができます。それが外部ネットワーク上で適用されていない場合は、これを回避するために、追加したときにリンクが自分のサイトへのリンクがある場合、トークンで決定された増加させることができるシステムは、トークンは、後で追加されます。しかし、リクエストのパラメータとしてこの追加csrftokenせず、ハッカーのサイトでは、CSRF攻撃を起動するには、このトークン値のRefererによって得ることができます。これはまた、一部のユーザーが手動でブラウザのReferer機能を閉鎖することを好む理由です。
（3）HTTPヘッダおよびカスタムプロパティを検証
また、このメソッドは、認証トークンのために使用され、その差のための方法は、ここではHTTPリクエストのパラメータとしてトークンに配置されていないということですが、カスタムHTTPヘッダー属性の中でそれを置きます。このクラスでのXMLHttpRequestは、クラスは、すべてのHTTPヘッダーとcsrftoken性、およびトークン値に変換するための1回限りのリクエストであってもよいです。これは、リクエストトークン不便で同じ時間に参加する方法を解くのXMLHttpRequestでアドレスを要求し、ブラウザのアドレスバーに記録されません、他のサイトにトークン漏れを心配しないでリファラーを通過します。