[サイバーセキュリティ]詳細CSRF攻撃

ディレクトリ

CSRF攻撃は何ですか
プロセスCSRF攻撃
CSRF攻撃の一般的なタイプ
CSRFの脆弱性テスト
CSRF攻撃を防ぎます
参照

CSRF攻撃は何ですか

CSRF（クロスサイトリクエストフォージェリ）は、多くの場合、CSRFまたはXSRFと略称も「ワンクリック攻撃」や「セッションライディング」と呼ばれる「クロスサイトリクエストフォージェリ」、の略です。CSRFクロスサイトスクリプティング攻撃（XSS）のように聞こえるが、それはXSSと非常に異なっており、ほとんどのオッズで攻撃中国名。XSSは、エクスプロイトによってCSRFながら、サイト内の信頼できるユーザーを偽装、信頼を攻撃するために信頼されているユーザーからの要求-site。XSS攻撃と比較すると、CSRF攻撃は、多くの場合、非常に人気がありません（したがって、そのリソースを防ぐために非常にまれである）と擁護することは困難で、それがXSSよりも危険と考えられています。

最初にあなたのアイデンティティを盗んだ攻撃をし、自分の名前でいくつかの不正な操作を実行します。私たちは、CSRF攻撃を理解することができます。CSRFは、あなたが商品を購入するには、アカウントを盗む機密情報を入手、あるいは、メールを送信するために、あなたのアカウントを使用することができます。唯一の要求は、ユーザーのブラウザから送信されますが、要求自体が自発的にユーザーによって送信されることを保証することはできませんことを保証するための簡単な認証：CSRF攻撃は抜け穴のウェブユーザID認証という事実を利用します。

プロセスCSRF攻撃

攻撃処理

CSRF攻撃や攻撃の原則を次のように

ブラウザを開いCユーザーは、信頼できるサイトAを訪問し、ユーザー名とパスワードの要求は、ウェブサイトAをご覧ください。入力します。
ユーザー情報が検証された後に、サイトA Cookie情報が生成され、ブラウザに返され、その後、ユーザサイトAログインの成功は、通常、サイトAにリクエストを送信することができます。
ユーザーがサイトAを出ていないまで、同じブラウザで、タブページの訪問Bを開きます。
サイトBはユーザーの要求を受信した後、コード攻撃の一部を返し、要求がサードパーティのサイトAへのアクセスを必要とする発行します。
、コードのブラウザ攻撃を受けたサイトBの要求に応じて、ユーザの知識なしにCookie情報を搬送する際に、サイトAへの要求ウェブサイトでは、Cookie情報は、Bが実行されたサイトから悪意のあるコードが得られ、処理されたリクエストのCへのユーザー権限をCに基づいて要求が実際に、Bによって開始されていることを知りません。

上記のプロセスからわかるように、あなたはCSRF攻撃に到達したい、次の2つの基本的な条件を満たしている必要があります。

ログインはAサイトを信頼して、ローカルにクッキーを生成します。
Aの場合には、外の重要なサイトB.へのアクセスではありません

CSRF攻撃の一般的なタイプ

CSRFを入力GET
のみHTTPリクエストを必要とします。私たちは、単純なCSRFを構築することができます。
例：

银行站点A：它以GET请求来完毕银行转账的操作，如：http://www.mybank.com/Transfer.php?toBankId=11&money=1000 
危急站点B：它里面有一段HTML的代码例如以下：

<img src=http://www.mybank.com/Transfer.php?toBankId=11&money=1000>

まず第一に、あなたは銀行のサイトAでログインし、緊急サイトBを訪問し、その後、1000年あなたの銀行口座が少ないでしょう。なぜこれがそうですか？その理由は、リソースを更新するGETリクエストを使用して、HTTPの仕様に違反している銀行のサイトです。重要なサイトBにアクセスする前に、）あなたは、銀行サイトAをすでにログインしている、そしてBは、正当な要求であるが、ここで不謹慎な要素があります。だからあなたのブラウザはここ（サイトA Cookieの発行銀行は、サードパーティのリソースを要求する方法を取得するためのリソースを取得するための要求を取得持参サードパーティの銀行のサイトを指しますが、オリジナルの本はhttp：// WWW。 mybank.com/Transfer.php?toBankId=11&money=1000、銀行のサイトサーバーの結果が要求を受信すると、これはリソースの更新操作（転送動作）であるので、我々はすぐに操作を転送したと感じています。

CSRF POSTタイプ
：のような害のタイプは大きくないGET、我々は一般的に使用されるフォームが自動的に送信された利用CSRFのこの種の、

<form action=http://wooyun.org/csrf.php method=POST>
    <input type="text" name="xx" value="11" />
</form>
<script> document.forms[0].submit(); </script>

自動的にユーザーをシミュレートするために同等の、フォームを送信するページを訪問した後、POST操作を完了します。

CSRFの脆弱性テスト

CSRFの探傷は、最も簡単な方法は、リファラーフィールドの再送信を除去する、パケット正常要求をフェッチするために提出も有効である場合、それは実質的にCSRF脆弱性の存在を決定することができるされ、比較的面倒な作業です。

CSRFの脆弱性研究の深化と、そのようようにCSRFTester、CSRF要求BuilderおよびなどCSRFの脆弱性に対するテストのためのいくつかの特別なツールを新興。次のように例としてCSRFTesterツールに、テスト原理CSRF脆弱性検出ツールは次のとおりです。CSRFTesterテストを使用する場合は、あなたが最初になど私たちは、ブラウザ内のリンクを訪問したすべての情報、およびすべてのフォームを、取得する必要があり、および変更CSRFTesterに対応することにより、フォームやその他の情報は、偽造クライアントの要求に相当する、再送信してください。変更要求がWebサーバーに受け入れられた後、テストが成功した場合には、CSRFの脆弱性があり、当然のことながら、このセクションのツールは、CSRF攻撃のために使用することができます。

CSRF攻撃を防ぎます

1.確認HTTP Refererフィールドを
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攻撃、正当なユーザーへのアクセスの拒否。

リファラー検証要約方法

長所：使いやすい、開発は簡単では、ある程度のCSRF攻撃を防ぐことができます。
短所：このメカニズムは完全にブラウザに依存しているが、リファラー・フィールドは、意図的に改ざんされる可能性が高い、または無効になっています。

2.リクエストトークンを追加し、確認するために
トークンが類似したクラスのセッションID値の長いリストとしてサーバからクライアントに返される（長い暴力の推測ソリューションを防ぐためです）。ブラウザが自動的に我々は検出することにより、オーバー送信できるようにCSRFは、トークン取得することができない（非表示のフォーム入力タグを格納する属性を追加する一般的な形式）リンク先のウェブサイト、トークンホールドクッキーを依頼するマッピングされたときCSRFは、クッキーベルトに依存しています要求に応じて、データパケットか否かを決定するための正しいトークン値を有します。

原則を明確にした後、防衛トークン、およびトークンの方法は非常に困難な複雑さを感じているので、我々は、トークンの面で設計します。

私たちは、最初のトークンCSRF攻撃を防ぐことができ、すべてのリクエストトークンの撤退を同じにすることができる前に、ユーザは、このプロセス全体にログオンした後に、同じではありませんすべての要求を必要としない問題を定義します。そのため（に想定されていない他のトークンベースの脆弱性は、このセッションを漏らす）、ハッカーがユーザーのtokneを取得することはできません、なぜすべての要求は新しいトークンを生成する必要があり、それ。ケース（各リクエストトークンと同じ考え方がリプレイ攻撃の影響を受けているべきではありません）フィルタ試験フィルターアンチリプレイをテストするだけでなく、反CSRFは、トークンデザインがはるかに簡単です。

トークンのデザインとしてセッションIDの使用：自分自身をもたらすために、ブラウザでCSRFのクッキーには、利用者の性質は、我々は他の値を渡すことはできません、これに基づいて（つまり、攻撃者はどのくらいのセッションIDを知りません）失われていないセッションIDちょうどセッションIDトークンを直接に（または特定の値をほぼ意味、トークンのために行うセッションID MD5取られることがこのような計算を行うことができる）など。同様の判定コードセッションであれば[ "ID"] == $ _POST [ "トークン"]

トークンセッションID設計返す：セッションIDを生成しながら、クライアントに（サーバートークンがセッション変数に格納されていてもよい）トークン生成し、クライアントは、各要求のトークンの形の形で格納された値を送信します。セッションであれば、同様の判断コード[「トークン」] == $ _POST [「トークン」]

この方法では、リファラーチェックのいくつかのより安全であるユーザがセッションからログアウトした後にトークンが、セッション中に発生し、配置することができ、その後、各要求にトークン、リクエストトークンと比較する、しかし困難メソッドは、パラメータとしてリクエストトークンを結合する方法です。それはURLのなるように、GET要求の後、トークンは、要求アドレスに添付されますHTTP：// URL csrftoken = tokenvalue？。POSTリクエストの場合は、最終の形で追加しますだから要求入れトークンをパラメータとして追加されます。しかし、それぞれの要求はトークンを追加するためにあなたは、非常に多くの要求を受け入れることができ、サイト、非常に面倒であり、欠場するのは簡単です、一般的に使用される方法は、すべての時間が横断するためにはJavaScriptを使用して、ページがロードされますすべてのラベルとDOMの形のDOM全体の木はトークンを追加しました。このような要求は、ほとんどを解決しますが、ページがロードされた後、動的に生成されたHTMLコードのために、このメソッドは効果がありません、プログラマは手動でコーディングにトークンを追加する必要があります。もう一つの問題は、ハッカーによって傍受されないように、セキュリティトークンストレージ自体を保護する方法です。

要約の検証トークン方法

安全性の程度は、リファラーの道よりも高くなります。
少し複雑な実装。
セキュリティトークンストアを確認する必要があります。

前記HTTPヘッダとカスタム属性検証
この方法のトークンと認証の使用であり、その差のための方法は、ここではHTTPリクエストのパラメータとしてトークンに配置されていないことであるが、それカスタムへのHTTPヘッダがの属性。このクラスでのXMLHttpRequestは、クラスは、すべてのHTTPヘッダーとcsrftoken性、およびトークン値に変換するための1回限りのリクエストであってもよいです。これは、リクエストトークン不便で同じ時間に参加する方法を解くのXMLHttpRequestでアドレスを要求し、ブラウザのアドレスバーに記録されません、他のサイトにトークン漏れを心配しないでリファラーを通過します。

しかし、この方法の制限は非常に大きいです。通常、局所非同期ページリフレッシュ要求のために使用される方法へのAjaxのXMLHttpRequestは、このクラスを開始するためのすべての適当ではないですが、後方、前方に実行するように要求されたページによって得られたクラスがさわやか、ブラウザで記録することができません、コレクションや他の操作、ユーザーに不便。また、レガシーシステムなしCSRF保護は保護にこのアプローチを使用することで、すべての要求はそうほとんど価格が受け入れられない間違いなくサイト全体を書き換えるために、XMLHttpRequestのリクエストを変更する必要があります。

ヘッド属性検証モードの概要

トークンリークする比較的シンプルですが、簡単ではありません使用します
機会の少ない使用、偉大な制限。