セキュリティ

クロスサイトリクエストフォージェリ（CSRF）とは

2019年11月25日

クロスサイトリクエストフォージェリ（CSRF）とは

クロスサイトリクエストフォージェリ（CSRF）とは、会員サイトなどでログイン状態を保持したまま「悪意のある攻撃者」が作成した罠サイトのボタンやリンクを押下することで、利用者の意図しない形でリクエストを送られてしまう攻撃です。

具体的にどういうことですか？
クロスサイトリクエストフォージェリ（CSRF）の説明は複雑なので、ここからは図を利用して分かりやすく説明していきます。

スポンサーリンク

クロスサイトリクエストフォージェリ（CSRF）の説明の前に、セッションIDがどのようなものか理解しておくことをお勧めします。セッションIDの説明は以下をご覧ください。

参考

[CSRFの流れ1] 会員サイトにログインする

悪意のある攻撃者がターゲットとしているWebサイト（以下図の例ではAサイト）に利用者がログインします。

AサイトのWebサーバは利用者が入力した「ID」と「パスワード」が正しいかチェックします。

[CSRFの流れ1] 会員サイトにログインする

[CSRFの流れ2] セッションIDを発行する

AサイトのWebサーバは、利用者が入力したログイン情報（IDとパスワード）が正しければ「セッションID」を払い出します。そして利用者に「ログイン成功」のレスポンスと共に払い出した「セッションID」を返却します。

セッションIDはCookieなどを利用しクライアント側（利用者側）に保存されます。

[CSRFの流れ2] セッションIDを発行する

[CSRFの流れ3] ログイン状態を維持したまま別サイトを閲覧する

Aサイトにログイン成功した利用者が、Aサイトからログアウトせず（ログイン状態を維持したまま）、別のサイトを閲覧します。会員サイトなどにログインした状態で、他のサイトを閲覧することはよくある操作だと思います。

もし、たまたま（もしくは「なりすましメール」等で誘導された）閲覧したサイトが「悪意のある攻撃者」が用意した罠サイトだったらどうなるでしょう。

[CSRFの流れ3] ログイン状態を維持したまま別サイトを閲覧する

[CSRFの流れ4] 罠サイトのリンクやボタンを押下

Aサイトにログインした状態のまま「悪意のある攻撃者」が用意した罠サイトを閲覧、そして罠サイトにあるリンクやボタンをクリックすると、AサイトのWebサーバに利用者が意図していない情報が送られてしまうのです。

そしてこの時、クライアント側（利用者側）のCookieに保存されていた「セッションID」も自動的に送られます。

その結果、AサイトのWebサーバは「セッションID」が正しいので、正常のリクエストと判断しリクエストを受理してしまうのです。

[CSRFの流れ4] 利用者の意図しない情報がターゲットのWebサーバへ送られてしまう

[CSRFの流れ5] 利用者の意図しない処理が勝手に行われてしまう

「悪意のある攻撃者」が作った罠サイトにより、利用者の意図しない情報がAサイトのWebサーバに送信され、会員サイトからの強制退会、SNSの強制投稿、ネットショップの強制購入、不正な送金などの操作が行われてしまうのです。

これがクロスサイトリクエストフォージェリ（CSRF）による攻撃例です。

[CSRFの流れ5] 退会や送金、購入といった利用者の意図しない操作が行われてしまう

クロスサイトリクエストフォージェリ（CSRF）の攻撃例

スポンサーリンク

正規なサイトの例

例えば、以下のようなサイトがあるとします。

金額と口座番号を入力することで、指定された口座番号へ送金する仕組みです。

csrf攻撃例1

HTMLの内容は以下、formタグの送信先は「http://〇〇〇.co.jp/csrfSample/add」です。

<html>
<body>
<div>
  <h1>銀行振り込み</h1>
  送金する金額と口座番号を入力してください。<br>
  <form action="http://〇〇〇.co.jp/csrfSample/add" method="post">
    　金額　：<input type="text" name="money" size="10"/>円<br />
    口座番号：<input type="text" name="accountNumber" size="30" /><br /><br />
    <input type="submit" value="　登録　" />
  </form>
</body>
</html>

罠サイトの例

次の罠サイトの例です。

見た目はただの「恋愛占い」サイトで何も問題ないように見えます。

CSRF攻撃例2

しかしHTMLの内容を見ると、お金と口座番号の情報が「hidden」タグで隠されています。そしてformタグの送信先は「http://〇〇〇.co.jp/csrfSample/add」と、正規サイトと同じ宛先を指しています。

この結果、金額100万円を「1234567」の口座番号へ振り込むという利用者の意図しない情報が、正規サイトへ送られ登録されてしまうのです。

<html>
<body>
<div>
  <h1>恋愛占い</h1>
  恋愛占いを開始する場合は「占い開始」をクリックしてください。<br><br>
  <form action="http://〇〇〇.co.jp/csrfSample/add" method="post">
    <input type="hidden" name="money" value="1000000"/>
    <input type="hidden" name="accountNumber" value="1234567" />
    <input type="submit" value="占い開始" />
  </form>
</body>
</html>

クロスサイトリクエストフォージェリ（CSRF）の対策

スポンサーリンク

[CSRF対策] セッションIDとは別に機密情報を保持する

クロスサイトリクエストフォージェリ（CSRF）の対策は、セッション管理とは別に機密情報を保持するという手法です。

例えば入力画面を表示する際に、Webサーバで機密情報を作成し（ログイン時に生成）画面側は機密情報を「hidden」パラメータで保持。そして登録完了の際に「登録内容」と一緒に機密情報をWebサーバに送るという流れです。

Webサーバは「セッションID」と「機密情報」を確認し、リクエストが正しい画面から送られてきたことを保証します。

CSRF対策1

セッション管理で使用するセッションIDとは別に機密情報を保持することで、「悪意のある攻撃者」は機密情報を入手しなければ、攻撃は成立しなくなります。

CSRF2

機密情報は、セッション管理で使用している「セッションID」を用いる方法や、セッションIDとは別のIDをログイン時に暗号論的擬似乱数生成器を用いて生成する方法などが考えられます。

また機密情報は「hidden」パラメータで保持し、リクエストは「POST」メソッドで行うようにしましょう。「POST」ではなく「GET」メソッドで使用した場合、外部サイトに送信されるRefererに秘密情報が含まれ、外部に流出してしまう可能性があります。

helpful