CSRF全体のクロスサイトリクエストフォージェリは、クロスサイトリクエストフォージェリのドメイン。XSS、SQLインジェクションやその他の攻撃にこの攻撃の相対は比較的遅く発見された、この攻撃の条件と回避するための方法で今日を脱ぎました。
攻撃処理
-
ABCは、ユーザーが銀行のウェブサイトを運営してログオンし、また、攻撃者が事前に構成されたウェブサイトを訪問したとします。
-
ABCのリンクがされ、攻撃者のサイトに特定のリンクをクリックした
http://www.bank.com/xxxx銀行がマネーサーバを運び、このリンクのパラメータに従って動作します転送されます、銀行を指します。 -
操作を実行する前に銀行振込・サーバは、セッションがログインするかどうかを検証するために実施されますが、理由はABCのあなたの銀行のウェブサイトへのリンク、また、攻撃者がログオンした
www.bank.com攻撃は、銀行のサーバーへのセッションIDのリンクを運びますので、。 -
セッションIDが正しいので、操作が転送操作を実行するために、私が開始された場合、その銀行が決定します。
ショー
上記の説明によると、我々は攻撃をシミュレートするためのプロセスを見てください。
-
そこ
www.bank.comにwww.hacker.comユーザーのログインABCはwww.bank.com後にサイト上でクリックしたwww.hacker.comリンクのクリックのトリックがしたいことはありません -
このリンクはする
www.bank.comポストを開始することを要求する。ドメイン名リクエストのでwww.bank.com、リクエストが運ぶwww.bank.comセッションIDを。
www.hacker.com的代码
<!DOCTYPE html>
<html lang="en"> <head> <meta charset="UTF-8"> <title>Title</title> </head> <body> <form method="post" action="http://www.bank.com/transfer.php"> <input type="hidden" name="from" value="abc"> <input type="hidden" name="money" value="10000"> <input type="hidden" name="to" value="hacker"> <input type="button" onclick="submit()" value="点击抽大奖"> </form> </body>見つけることができるwww.hacker.comWebページには、含まれているwww.bank.comポストを開始する要求を。そして隠されたフォームは、ユーザーがトリックをクリックするだけで一つのボタンはありません。
完全なサンプルコードはできるGitHubの上で見つかった。ポータル。
予防
あなたは攻撃CSRF上記の例から見ることができます。ハッカーは、クッキーを取得することはできません、解決のために、サーバから返されたコンテンツのための方法はありません。実行するだけのものはサーバーにリクエストを送信することである。サーバデータの変更要求を送信することにより、上記の例では攻撃者は被害者の銀行のデータベースの量が変化したように、操作を転送するためのリンクをクリックするようユーザーを誘導します。
CSRF攻撃の原則と目的を理解し、我々は防衛の二つの手段を提案しています
リファラー検証
HTTPプロトコルによると、httpリクエストの元のアドレスを記録し、フィールドのリファラのHTTPリクエストヘッダに含まれている。通常の状況下では、転送動作のPOSTリクエストの実装はwww.bank.com/transfer.phpをクリックしなければならないwww.bank.com、トリガするためにWebページのボタンの操作今回の移転をリファラ要求がなければなりませんwww.bank.com。そして、あなたはCSRFハッカーの攻撃になりたい場合は、唯一の自分のサイトのことができますwww.hacker.com。リクエストフォージェリのリファラにリクエストフォージェリはあるwww.hacker.comので、我々はポストを比較することで、要求をリファラ。ないwww.bank.com要求が正当であるかどうかを判断することができます。
このように検証は、比較的単純である限り、あなたはリクエストのリファラを投稿することができますが、原因リファラにブラウザが提供される前に改ざんのプロトコルのHTTPリファラ値で必須ではありませんが、サイトの開発者が。チェックインするが、セキュリティは、ウェブサイトを横断してはならないとして、他の人によって保証されています。
トークン検証
それは上記のスタイルから発見され、転送形態を偽造する攻撃者は、そのサイトは、トークン検証値によって決定されたサーバへの追加データの要求とともにサーバに提出.tokenフォームを検証するために、ランダムなトークンで添加することができますポスト要求は正当ではありません。それは、トークンの値を知る方法がないので、攻撃者は、ページに情報を取得する方法はありませんので。そう何の偽形式トークン値を。サーバーは、要求が偽造されたかを決定することができます。