実演動画あり!クロスサイト・リクエスト・フォージェリ(CSRF)とは

クロスサイト・リクエスト・フォージェリとは?

Webサービスは通信ルールとしてHTTP(Hypertext Transfer Protocol)が利⽤されます。このHTTPは、基本的にステートレス(状態を記憶しない)な仕様で、同⼀のコンピューター同⼠の通信であっても前後の通信において関連性を持たせないルールとなっています。(WebSoketやHTTP version 2は除きます)

このため、会員制サービスのあるWebサイトにおいては、⼤半のWebサイトにおいてCookie(Webサイトが発⾏する値をWebブラウザで保存する仕組み)などを利⽤してアプリケーションレベルでユーザーを追跡するセッション管理を⾏っています。しかしこのセッション管理を⾏う際に、利⽤者の意思を確認せずにそのまま処理を完遂してしまうとユーザーに不利益を招いてしまうことがあります。

このような利⽤者の意思を確認せずに処理を実⾏することで、ユーザーに不利益を招いてしまう問題をクロスサイト・リクエスト・フォージェリ(CSRF)と呼び、この脆弱性を突く⾏為をクロスサイト・リクエスト・フォージェリ(CSRF)攻撃と⾔います。

クロスサイト・リクエスト・フォージェリ(CSRF)攻撃の仕組み

クロスサイト・リクエスト・フォージェリ(CSRF)攻撃は主にCookieを使ってセッション管理を⾏っているWebサイトで発⽣します。以下はCookieを使ってセッション管理を⾏っているWebサイトの概要です。

  • Cookieを使ったセッション管理の概要

ここでポイントとなるのが、No.5のWebブラウザが⾃動的にCookieを付与することです。これは都度、利⽤者がIDやパスワードの⼊⼒する煩わしさを無くしてくれるため、利便性は向上しますが⾃動的にCookieを付与することから、対策を⾏っていないWebサイトではクロスサイト・リクエスト・フォージェリ(CSRF)脆弱性が混⼊します。

以下はクロスサイト・リクエスト・フォージェリ(CSRF)攻撃の概要です。

  • クロスサイト・リクエスト・フォージェリ(CSRF)攻撃の概要

このクロスサイト・リクエスト・フォージェリ(CSRF)攻撃は、Cookieが利⽤者の意思に関係なく⾃動的に付与される特性を逆⼿にとって、罠ページを仕掛けることで攻撃が可能になります。またこのクロスサイト・リクエストフォージェリ攻撃が成功すると、会員制サイトからの強制的な退会やECサイトでの決済処理の完了、SNSへの投稿完了など利⽤者にとって不利益を招く恐れのある処理が実⾏されます。

なお補⾜として、最近ではセッション管理が多様化しているため、別のページでご紹介したクロスサイト・スクリプティングを悪⽤してもセッションIDが奪取できない場合、このクロスサイト・リクエスト・フォージェリ(CSRF)攻撃と併せて悪⽤する事例もあります。そのため、本項のクロスサイト・リクエストフォージェリに対する対策と同様にクロスサイト・スクリプティング対策も併せて漏れなく実施することが望ましいと⾔えます。

被害事例

以下は⽇本国内で起きたクロスサイト・リクエスト・フォージェリ(CSRF)攻撃によって被害を招いた被害事例となります。

  • はまちちゃん事件

2005年4⽉に著名なSNSサービスであるmixiにて起きた事件です。他ユーザーの⽇記にアップされたURLをクリックすると勝⼿に「ぼくはまちちゃん!」というタイトルで⽇記がアップされてしまうという現象が相次いで発⽣しました。この⽇記のアップロード処理にはクロスサイト・リクエスト・フォージェリ(CSRF)攻撃が使われており、「ぼくはまちちゃん!」というタイトルで⽇記がアップされてしまう以上の実害性のある処理は⾏われていませんで
したが、事件の発端者の狙い通り、クロスサイト・リクエスト・フォージェリ(CSRF)の影響⼒を世に知らしめる事件となりました。

  • パソコン遠隔操作事件

2012年6⽉から9⽉にかけて13件もの殺害・爆破予告が⾏われ著名なアニメ演出家を含む複数の容疑者が逮捕されました。しかし、この逮捕はいずれも誤認逮捕で、インターネット掲⽰板を経由してマルウェアに感染したコンピューターを真犯⼈が遠隔で操作しながら、予告のあったホームページのクロスサイト・リクエスト・フォージェリ(CSRF)脆弱性を突いた攻撃が⾏われていたことが後に判明しました。誤認逮捕が相次いだ事に加えてクロスサイト・リクエスト・フォージェリ(CSRF)に対する世間⼀般的な⾒解不⾜が露⾒した衝撃的な事件だったと⾔わざるをえません。

脆弱性の解説動画

クロスサイト・リクエスト・フォージェリ(CSRF)が起こる原因

Webページを遷移する際、バックグランドでWebブラウザとWebサイトは以下のようなHTTP通信を⾏っています。

  • HTTP通信(HTTPリクエストの例)
POST /email/change HTTP/1.1
Host: vulnerable-website.com
Content-Type: application/x-www-form-urlencoded
Content-Length: 30
Cookie: session=yvthwsztyeQkAPzeQ5gHgTvlyxHfsAfE
email=wiener@normal-user.com

上記のようなWebブラウザからWebサイトに対してページを要求するHTTPリクエストを送信するには、以下のようなHTMLにてformタグを指定します。

  • HTML(formタグ)の例
<html>
    <body>
        <form action="https://vulnerable-website.com/email/change" method="POST">
            <input type="hidden" name="email" value="pwned@evil-user.net" />
        </form>
        <script>
            document.forms[0].submit();
        </script>
    </body>
</html>

仮にログイン済みのユーザーが上記のページを罠ページとして公開している攻撃者のWebサイトを閲覧した場合、そのユーザーのセッション情報とともにHTTPリクエストを送信することになるため、上記のHTTPリクエストに伴う処理がサーバー側で受理されます。その結果、被害に遭うユーザーの意思にかかわらず、そのユーザーの処理として問題のあるサイトでは処理が実⾏されてしまいます。

このように第三者がHTTPリクエストを捏造することができてしまうことが、クロスサイト・リクエスト・フォージェリ(CSRF)が発⽣する原因です。

クロスサイト・リクエスト・フォージェリ(CSRF)攻撃への対策⼿法

クロスサイト・リクエスト・フォージェリ(CSRF)脆弱性が混⼊しないようにするためには、以下のような対策を実施する必要があります。

必須対策1(トークンの発⾏)

⼊⼒から実⾏という典型的な画⾯遷移を想定すると、送信時のパラメータとしてトークンと呼ばれる秘密情報を持たせます。その上で、処理実⾏時にサーバー側では、渡されてきたトークンの正当性を確認してから重要な処理を実⾏するようにチェック処理を設ける事で、攻撃者が知り得ないトークン情報の正当性を確認することができるため脆弱性の混⼊を防ぎます。

必須対策2(パスワードの⼊⼒)

本⼈の意思を確認するために重要な処理を実⾏する際には、本⼈しか知り得ないパスワードを送信パラメータとして必須にすることで第三者がHTTPリクエストを捏造できないようにします。場合によっては都度、パスワードの⼊⼒が必須になってしまうため、利便性は下がってしまいますが、クロスサイト・リクエスト・フォージェリ(CSRF)攻撃の対策としては有効です。

推奨対策1(CookieにSameSite属性を付与)

Cookieでセッション管理を⾏っている場合、該当のCookieにSameSite属性を付与します。SameSite属性を付与することでCookieが付与される条件を絞ることができるため、クロスサイト・リクエスト・フォージェリ(CSRF)攻撃の抑⽌として有効です。

  • SameSite属性の概要
#挙動
1LaxサードパーティのWebサイトからのHTTPリクエスト時はGETメソッドの時のみCookieを付与する
2StrictサードパーティのWebサイトからのHTTPリクエスト時はCookieを付与しない
3None従来通りどのWebサイトからのアクセスであってもCookieを付与する

※ なお、SameSite属性が何も付与されていない場合、Google Chromeではver.80以降においてSameSite=laxとして解釈するようになっています。

推奨対策2(Cookie以外の⽅式でセッション管理を⾏う)

Cookie以外の⽅法でセッション管理を⾏います。基本的にクロスサイト・リクエスト・フォージェリ(CSRF)攻撃はCookieでセッション管理を⾏っているWebサイトにおいて混⼊する問題であるため、違う⽅式(例えばBearer認証など)でセッション管理を⾏うことで、混⼊する確率を減らすことが期待できます。ただしセッション管理はWebサービス全体に関わってくる仕様であるため、新規にWebサイトを構築する際に本項の対策を検討するのが望ましいと⾔えます。

まずは手軽にツールで脆弱性診断

上述の対策手法が重要となる一方で、脆弱性が混入されていないかを検知する事も重要となります。そのためには脆弱性診断を受診する必要があり、クロスサイト・リクエスト・フォージェリ(CSRF)の脆弱性についても脆弱性診断を通じて発見する事が出来ます。

脆弱性診断とは何かについて詳しく知りたい方は脆弱性診断とは(エンジニア向け)脆弱性診断とは(⾮エンジニア向け)もぜひご参照ください。

脆弱性診断ツール「Securify Scan」では、クロスサイト・リクエスト・フォージェリ(CSRF)の脆弱性検知も対応しております。脆弱性検知やセキュリティレベルを強化したい企業様はぜひ弊社の脆弱性診断ツール「Securify Scan」を活用ください。

無償でのトライアル実施も行っておりますので、
お気軽にお問い合わせください。

Webアプリケーションの
継続的セキュリティを簡単に実現
Securify

ブログ一覧へ戻る

サービスに関するご質問・ご相談など
お気軽にお問い合わせください