CSRF（クロスサイトリクエストフォージェリの）、中国名：クロスサイトリクエストフォージェリ。
簡単に言えば、あなたがAは、結果が終了していなかったサイトに上陸したので、着陸地点Bに行き、サイトBはサイトであなたの法的地位によって、悪質なリクエストが含まれている、彼らは攻撃サイトAにデータを送信保持しました
、CSRF攻撃
CSRFは、図1に示すように原理は、シンプルで攻撃します。ウェブ悪質なWebサイトを構築するために、攻撃者のためにCSRFの脆弱性、ウェブBの存在があるウェブサイトは、ユーザCは、正当なユーザーのWebサイトがあります。
1.ユーザCは、ブラウザを開いて、Aは、ユーザー名とパスワードの要求は、ウェブサイトAを訪問入る信頼できるサイトを訪問します。
ユーザー情報が検証された後2、サイトA Cookie情報が生成され、ブラウザに返され、その後、ユーザサイトAログインの成功は、通常、サイトAにリクエストを送信することができます。
ユーザーがサイトAを終了していない前に3は、同じブラウザで、タブページの訪問Bを開きます。
4.サイトBは、コード攻撃の一部を返し、ユーザの要求を受け取り、要求を発行し、サードパーティのサイトAへのアクセスを必要とします。
ユーザの知識なしにCookie情報を運ぶ、サイトBの要求に応じて、コードのブラウザ攻撃を受けると5、サイトAへの要求 ウェブサイトでは、Cookie情報は、Bが実行されたサイトから悪意のあるコードが得られ、処理されたリクエストのCへのユーザー権限をCに基づいて要求が実際に、Bによって開始されていることを知りません。
（1）：私たちは、サイトを上陸させたときに、HTTPプロトコルはステートレスなので、私たちの着陸状態を維持するために、サーバプログラムは、当社のログイン情報を保存するために、セッションファイルを作成する必要がありますので。
（2）：各アクセスの間で複数のページを切り替えることができるようにするために、我々は、サーバーに応じて、ファイル配信セッションを状態を記録した最初のクライアントのブラウザに対応したセッション_します。ブラウザの後のクッキー・ファイルに書き込まれ、この値を受け取ります。次回は、あなたがサイトのコンテンツにアクセスする場合は、ローカルストアに属するサイトのクッキーsession_idのクッキーエンドのストレージを含む、すべてのクライアント・サーバ・プログラムに送信されます。サーバは、要求者の身元を検出する必要がある場合は、渡されたsession_idのクッキーが含まれているの合法性に基づいて、応答があった場合にセッションファイル、およびファイルサーバセッションの内容を検出することが可能です。テスト正当な場合、ユーザを認証するためにそれ以外の場合は違法合法的です。
（3）：ハッカーが別のページへのリンクを設定した場合、サイト転送システムへのリンクポイントは。そして、現在のユーザーが、このサイトのメンバーであり、かつ状態に上陸した（つまり、正当なSESSION_IDストアクライアントのブラウザ上のクッキーがある）ユーザーは、この後のリンクをクリックしたときに、その後、クライアントのブラウザでは、これらのユーザーを送信します情報がサーバに渡されますが、何をすべきか、リンクが特定され、ユーザーはそれがユーザーの偽のアイデンティティを行いますことを知りませんが、ユーザーにはわかりません。。
二つは、CSRFは防衛を脆弱性
3つの解決策があります。
（1）制限が参照
（2）トークンを使用して
（3）コードの技術を使用して
以下では、例えば、上記の三つの方法は、サンプルコードを使用して実施した、Java（登録商標）であろう。かかわらず、サーバー側インターセプタで使用される方法の不可欠であり、それはその後、着信要求が要件を満たしているチェック要求の結果に応じて継続か破棄するかどうかを決定する責任があります。Javaでは、フィルタによる迎撃を実現しています。私たちは、フィルターを書き、CSRF保護を傍受するために必要なすべてのリソースへのアクセスを要求するためにweb.xmlにそれを設定することができます。
2.1：HTTPのRefererフィールドを確認します。
HTTPプロトコルに従って、リファラーHTTPヘッダーと呼ばれるフィールドは、HTTPリクエストの送信元アドレスを記録し、そこです。通常の状況下では、安全なページ要求へのアクセスが制限され、同じWebサイトから取得する必要があります。たとえば、銀行振込は、ユーザーはhttpによってアクセスされる：//bank.test/testページ= 10＆ユーザID = 101＆＃038;お金= 10000ページが完成され、ユーザーが最初にbank.testをログインする必要があり、そのページ上のボタンをクリックすることによって起動転送？イベント。ユーザーがリクエストを送信すると、転送要求のリファラー値は、それが（テストドメインから始まる通常の銀行。アドレスには、このケースでは）ボタンを転送するページのURLです。攻撃者は銀行のウェブサイトでCSRF攻撃を実装する場合、ユーザーが攻撃者のWebサイトを通じて銀行に要求を送信したときと、彼は唯一の自分の要求工事現場、リクエストのリファラーは、攻撃者のサイトを指していることができます。そのため、防衛CSRF攻撃に、銀行のサイトには、ベースの銀行ならば、その値のRefererそれぞれにのみ転送要求の確認が必要です。テストドメイン名の先頭に、その要求は、自分の銀行のサイトからの要求で、正当なものです。サイトリファラーつまりは、CSRF攻撃があるかもしれない場合、要求は拒否されます。
認証コードの要求のフィルタでリファラーを以下
フィルターにリファラーを確認してください。1.リスト
// 从HTTP头中リファラー值取得 ストリングリファラ= request.getHeader（ "リファラー" ）。 // 判断リファラー是否以bank.example开头 場合（！（リファラ= NULL）&& （referer.trim（）のstartsWith（「bank.example」）））{ chain.doFilter（リクエスト、レスポンス）。 } 他{ request.getRequestDispatcher（「error.jsp」）フォワード（リクエスト、レスポンス）。 }
上記のコードはerror.jspページを行く、それ以外の場合は、CSRF攻撃であってもよいし、最初のリファラー値を取得し、それが空でなく、それがbank.exampleを開始したときに、その要求を続けるときに決定します。
2.2：トークンを使用して
トークン、トークンは、ある最大の特徴は、ランダムで予測不可能です。一般的にハッカーやソフトウェアが推測することはできません。
トークン一般的に2つの場所で使用さ：
- 1）重複したフォームの送信を防ぐために、
- 2）抗CSRF攻撃（クロスサイトリクエストフォージェリ）。
どちらも、経由原則的にセッショントークンを達成します。クライアントがページを要求すると、サーバは、乱数トークンを生成し、トークンは、（一般的に隠された形で構成された）クライアントにトークン、その後、セッションの間に配置されます。クライアントが要求を提出する次の時間は、トークンがサーバーにフォームと一緒に提出しました。
「反CSRF攻撃」に適用された場合次に、サーバはトークン値を検証します、等しい場合、セッションに等しいとトークン値は、要求が有効ではなく、偽造を証明できるかどうかが決定されます。
しかし、同じ後、最初の認証サーバ「を繰り返すようにフォームを防ぐ」ために適用された場合、セッションは、トークン値更新となりますフォームが利用者から提出されたので、再送信の利用者ならば、第二の認証は、判断を失敗します。トークンは変更されていませんが、トークン内のサーバー側のセッションが変更されました
2.2：使用コード技術
このプログラムのアイデアは、次のとおりです。ユーザーが送信するたびに、このプログラムは完全にCSRF（原則として同様のトークン機構）を解決することができますが、個人が使用中に感じる....形、エリトリアで画面上にランダムな文字列を埋めるために、ユーザーが必要です非常に良いではない用語だし、検証画像がMHTMLは、MicrosoftのIEのバージョンに影響を受ける可能性があるとして知られているバグの使用を伴う聞きました。
コードは、主にサイトでサポートされているとログインに登録されています。その役割にあるが効果的に悪意のあるログイン登録コードは、ウイルスまたは他のソフトウェアと自動着陸して、自動アプリケーションユーザを除外することができるたびに、異なる防ぐ。効果的にこのような問題を防ぎます。
これは、悪意のある攻撃から他人を防ぐことができ、コードの真の役割であり、我々はあまりにも、あなたが頻繁に確認コードを送信する場合、ユーザ登録要求は、この設定では、前に確認コードプロンプトxxの時間を送られることに注意してくださいうまく悪質なウェブサイトの影響を減らします。
だから我々は、達成するために確認コードの原則に関する一般的な知識を持っています：
まず、検証コードがクライアントに表示される画像やページの形で、サーバーによって生成されることを理解し、クライアントのユーザーは、画像識別認証コードに従って、サービス層にチェックした場合、提出確認コードを提出する登録しますチェックが成功すると、ユーザー登録と正常にログインし、それが失敗した場合、再登録するようにユーザーに尋ねます。そして、絵の理由フォーマットに設計されたコード設計、コードを確認する方法、これらの写真がどのように生成されるかを考えるが、それは視覚的にどこの検証コードを識別することは困難です。
画像をランダムにサーバ側で生成され、これらの画像は、所定のその高さと幅を設定し、ライン画像上の一部の干渉を描くことができ、もちろん、干渉ラインの数が管理され、異なるコードがプラグまたは異なるサイトコード干渉画像の程度を変化させる、一般的に、悪意のある攻撃の結果を防ぐために、干渉のより高いレベルが良くなります。しかし、それはまた、ユーザを特定することの難しさを増加し、製造ラインは、画像を識別したり、不誠実またはサボタージュに登録するマシンのいくつかの種類によって、誰かの検証コードの絵を描くように干渉プログラミングコードを防ぐためです。人間の目は簡単にコードの絵を特定できない場合、我々は人間の目よりも低い温度で、マシンの識別は、画像が確認コードを取得することは容易ではないと信じています。認証コード画像は、大文字と小文字の組み合わせであってもよく、アレイは、文字の形で、これらの文字をランダムにスプライシング生成されてもよいです。検証を達成するための画像合成後、それは、文字列の文字列に変換され、その後、バイト配列出力ストリームの形式でフロントエンドに転送され、ページに対応する位置を表示します。、生成された確認コードながらは、独自のフラグIDが付随されていない有効期限を、その後、データは、典型的には、キャッシュサーバ、ユーザ入力された認証コードと戻るに一緒に包装され、サーバ上で確認すること、その結果はフロントエンドインターフェース検証に戻します。これらは、一般的な原則検証コードです。