CSRF攻撃：クロスサイトリクエストフォージェリの定義と防御

トピック

セキュリティ, サイバーセキュリティ

要約

クロスサイトリクエストフォージェリ（CSRF）攻撃は、認証済みのブラウザセッションを悪用して、ユーザーが意図しない不正なアクションを実行させるものです。こうした攻撃は、セッションCookie、予測可能なリクエスト構造、ソーシャルエンジニアリングを利用して、ユーザーとサーバーの両方を欺きます。効果的な防御策としては、偽造防止トークン、SameSiteクッキー、Representational State Transfer（REST）の設計原則、機密性の高いアクションを実行する前のユーザー検証の要求などが挙げられます。

Webサイトはどのようにして、悪意のあるリクエストを信頼してしまうのでしょうか？

CSRFは、認証済みのユーザーを騙して、そのユーザーのアカウントを介して悪意のある攻撃者にアクセス権を付与させる攻撃です。

CSRF攻撃では、ハッカーは被害者の認証情報を使って何らかの操作を行います。まるで魔法のようです。あるユーザーがウェブサイトにログインすると、そのユーザーのログインが本人の意図しない様々な動作をどういうわけか実行してしまいます。

CSRF攻撃がわかりにくいと感じるなら、それは意図的なものです。これらは、コーディングのノウハウ、策略、信頼、そして運に依存する攻撃です。CSRF攻撃はWebそのものと同じくらい古いと言われています。あるサイトが別のサイトにリクエストを送信するようになるとすぐに、CSRF攻撃が生まれました。

しかし、古く、巧妙な攻撃ベクトルでさえ、見つけ出して打ち破ることができます。これらの攻撃がどのように機能するか、またCSRF保護計画をまとめる際に何をすべきか（そして何を避けるべきか）についてお読みください。

CSRF攻撃の仕組みとは？

技術的な言い方をすると、CSRF攻撃とは、ハッカーがユーザーのアイデンティティと権利を乗っ取り、それらを利用して望ましくない機能を実行させるものです。平たく言うと、CSRF攻撃とは、誰かがあなたを騙し、あなたのアイデンティティを盗み、あなたのログイン情報であなたの銀行口座から送金するなど、オンラインで何かをすることです。

CSRF攻撃は、ホストサーバー上の何らかの情報を変更することを目的としています。ハッカーは、ユーザー名を変更したり、金銭を盗んだり、共通の配送先住所を変更したりする可能性があります。ハッカーが関連するすべての通知を受け取るため、サイトから異常を知らせる通知が届くことはありません。

CSRF攻撃について、順を追って見ていきましょう。

通常のログイン：被害者は、既知のユーザー名とパスワードを入力します。
標準的なセットアップ：サイトはセッションクッキーを作成し、被害者のブラウザに保存します。
アプローチ：被害者は、初めて攻撃者とやり取りします。彼らはフィッシングメールで出会うかもしれませんし、被害者が侵害されたウェブサイトを読み込むかもしれません。
Mistake: 被害者は攻撃者の罠に引っかかります。
Attack: ハッカーのコードは、ユーザーがログインしているサイトにリクエストを送信します。ブラウザが応答し、その中で、被害者の保存された認証情報が含まれています。
結果：サーバーはリクエストをチェックし、正当であると思われるため、コードを実行します。

CSRF攻撃は、これらのステップをすべて必要とし、順番に実行する必要があります。それらのうち1つでもスキップすると、攻撃は失敗します。

サイトはCSRF攻撃に対して脆弱でしょうか？

ハッカーは、特定の条件が揃わない限り、CSRF攻撃を実行できません。

特に3つの要素が必要です。

Cookie：ターゲットサイトは、ログインしているユーザーのセッションを検証するために、単純なワンタイムCookieを使用する場合があります。
シンプルなプログラミング：予測可能でシンプルなパラメーターセットでリクエストを定義します。ハッカーは次に何が起こるかを正確に把握しています。
標的となるアクション：ハッカーは、労力に見合う成果を得るために、送金などの重要なアクションを実行できる必要があります。

過去の被害事例を検証して、CSRF攻撃に伴うリスクを理解しましょう。大規模なウェブサイトが攻撃を受けました、以下を含みます：

INGダイレクト脆弱性により、ハッカーは新しいアカウントを作成し、ある場所から別の場所へ送金することができました。
YouTube。ハッカーは、ユーザーを友人またはお気に入りとして追加し、被害者のログイン名でメモを送信することができました。
ニューヨーク・タイムズハッカーはユーザーのメールアドレスを見つける可能性があります。

注：企業はこれらの脆弱性をすべて修正しました。

CSRF攻撃は個人にどのような影響を及ぼしますか？

個人もハッキングされる可能性があります。セキュリティ専門家は、メールの脆弱性をよく指摘します。ハッカーはあなたの認証情報を盗み、政府関係者に何千もの脅迫メールを送信する可能性があります。彼らはあなたの家にやって来て、あなたの逮捕を要求する可能性があります。ハッカーが関与していることを知らないからです。

CSRF攻撃はどのように作成され、実行されるのでしょうか。

CSRF攻撃は、一般的なブラウザ機能を利用します。リクエストを行うたびに、以下の盗難可能なデータでエンコードされます。

ユーザー名
セッションCookie
インターネットプロトコル（IP）アドレス
資格情報

ハッカーは、このデータを取得する能力を持っている必要があります。また、ハッカーは、目的の機能を実行するためにサーバーを欺くためにHTMLコーディングを使用する必要があります。残念ながら、そのような攻撃を行うためのソフトウェアはオンラインで簡単に入手できます。（また、ハッキング行為を助長したくないため、ここではリンクしません！）

ターゲットサイトを選択し、コードを構築したら、ハッカーはそれを提供する必要があります。それには、以下のようなことが含まれる場合があります。

Eメール。全ユーザーの約半数が送られてきたものを何でもクリックします。ユーザーがログインしているまさにその瞬間にハッカーから通知が送られてきた場合、攻撃はすでに進行中です。
偽造。ハッカーは、標的サイトにログインしている被害者が閲覧する可能性のあるページに、一見すると正常なフォームやスクリプトを作成します。そのサイトの多くの訪問者は標的サイトにログインしていないかもしれませんが、ハッカーにとってはたった1人の訪問者がいれば、労力に見合うだけの価値があります。
ソーシャルエンジニアリングハッカーは、ソーシャルメディアのメッセージングアプリ上の信頼できるソースからのように見えるメモを介して、偽造サイトにアクセスするように被害者を誘導する可能性があります。

攻撃者は認証情報を使って何ができるでしょうか？

被害者が標準ユーザーの場合、ハッカーはパスワードの変更、送金、配送先の住所の変更などの一般的なタスクを乗っ取ることができます。しかし、被害者がターゲットサイトの管理者である場合、ハッカーは完全に制御できるようになります。

CSRF対策チェックリスト

侵害されたサイトを運営していて、ハッカーが誰かを攻撃した場合、あなたは責任を共有することになります。安全で保護されたコミュニティを構築するために、できる限りのことを行うのが賢明です。

機能しないもの	すべきこと
シークレットCookie：他のCookieと同様に、セッション識別子として共有される場合があります。	REST：Representational State Transfer（REST）の設計原則に従い、さまざまなHypertext Transfer Protocol（HTTP）動詞にアクションを割り当てます。ハッカーは、GETリクエストが閲覧専用であるため、GETリクエストを使用してデータを取得することはできません。
POSTの制限：こうした攻撃では、ハッカーがPOST（データ送信）機能を標的にするのが一般的です。しかし、このフォームを制限しても、ハッカーは別の方法を見つけ出すでしょう。	偽造防止トークン：サーバーは後続のリクエストでこのコードを要求し、コードが存在しない場合はリクエストを破棄する必要があります。
ステップの追加：攻撃者が標準的なシーケンスを解明できる限り、保護にはなりません。	SameSite Cookie：Googleが作成したこのCSRF対策ツールは、サードパーティからのリクエストとともに送信されるCookieをブロックするのに役立ちます。
URLの書き換え：ユーザーのセッションIDは依然として公開されたままのため、この手順は役に立ちません。	検証：ユーザーは機密性の高いアクションを実行する前に、ログイン情報を確認します。

CSRF攻撃が疑われる場合、どのように対応すればよいですか？

従業員に、オンライン生活での矛盾に注意するように指導します。また、サイト訪問中にハッカーが顧客を標的にしたという苦情が寄せられた場合は、注意してください。脆弱性を追跡して停止するまで、コードをロックダウンする必要があるかもしれません。

お客様を保護するためのより多くの方法をお探しの場合は、私たちがお手伝いします。詳細については、お問い合わせください。OktaのIDソリューションについてご説明します。お客様のサイトでのログインを保護し、保存時および転送中のデータを保護するお手伝いをいたします。

よくある質問（FAQ）

クロスサイトリクエストフォージェリ（CSRF）攻撃が成功するには、どのような条件が必要ですか？

CSRF攻撃が成功するには、3つの条件が揃っている必要があります。1つ目は、標的のサイトがCookieを使用してログイン済みユーザーのセッションを検証していること、2つ目は、リクエストパラメーターが予測可能で、ハッカーが複製できるほど単純であること、そして3つ目は、送金やアカウント詳細の変更など、労力に見合う価値のある標的のアクションが存在することです。

ハッカーはどのようにしてクロスサイトリクエストフォージェリ（CSRF）攻撃を被害者に仕掛けるのでしょうか？

ハッカーは、いくつかの方法でCSRF攻撃を仕掛けます。たとえば、ユーザーが標的のサイトにログインしているタイミングで悪意のあるリンクをメールで送信する、被害者がアクセスする可能性のあるページに偽のフォームやスクリプトを埋め込む、ソーシャルメディアやメッセージングアプリで信頼できる送信元を装ったメッセージを送り、ソーシャルエンジニアリングによって被害者を偽のサイトに誘導する、といった手口があります。

クロスサイトリクエストフォージェリ（CSRF）攻撃の検知が困難な理由とは何ですか？

CSRF攻撃は、サーバーが悪意のあるリクエストを受信し、正規に認証されたユーザーからのリクエストのように見えるため、アラートを発することなくコードを実行してしまうことから、検知が困難です。関連するすべての通知は被害者ではなくハッカーに送信されるため、被害者は何かがおかしいことにすぐには気付きません。

クロスサイトリクエストフォージェリ（CSRF）対策として効果がないのはどの方法ですか？

The Open Web Application Security Project®（OWASP）Foundationによると、一般的に試みられる保護対策のいくつかは機能しません。具体的には、シークレットCookie（セッションIDとして共有される可能性がある）、POSTリクエストの制限（ハッカーが別の方法を見つけるだけであるため）、プロセスへのステップの追加（攻撃者が予測して再現できるため）、URLリライティング（ユーザーのセッションIDが依然として漏洩するため）が挙げられます。

クロスサイトリクエストフォージェリ（CSRF）攻撃に対する推奨される防御策をご確認ください。

CSRF攻撃に対しては、推奨される4つの防御策があります。具体的には、RESTの設計原則に従って特定のアクションを特定のHTTP動詞に割り当てること、サーバーが後続のすべてのリクエストで要求する偽造防止トークンを実装すること、SameSite Cookie設定を使用してサードパーティのリクエストで送信されるCookieをブロックすること、そして機密性の高いアクションを実行する前にユーザーにログイン情報の再認証を要求することです。

クロスサイトリクエストフォージェリ（CSRF）攻撃は、Webサイトだけでなく個々のユーザーにも影響を及ぼしますか？

はい、個々のユーザーもCSRF攻撃の標的になる可能性があります。例えば、ハッカーがユーザーの認証情報を盗み、それを使って政府関係者に脅迫的なeメールを何千通も送信する可能性があります。その結果、被害者はハッカーの仕業であるとは知らずに、深刻な事態に陥る危険にさらされます。

参考文献

クロスサイトリクエストフォージェリはなくなりました。（2017年2月）。スコット・ヘルム

シングルページアプリケーションでのCSRF攻撃の軽減。（2020年1月、Medium）

Popular Websites Vulnerable to Cross-Site Request Forgery Attacks.(2008年9月)自由への微調整

カウンターフィッシングトレーニングは役に立たない：半分の人が送られてきたものを何でもクリックする。(2016年8月).Ars Technica

Threat Watch: Cross Site Request Forgery (CSRF).(December 2007).CSO）

Cross-Site Request Forgery (CSRF).OWASP

Protecting Your Users Against CSRF.Hacksplaining

あなたのサイトはCSRF攻撃に対して脆弱ですか？

ハッカーは、特定の条件が揃わない限り、CSRF攻撃を実行できません。

特に3つの要素が必要です。

Cookies: ターゲットサイトは、ログインしているユーザーのセッションを検証するために、単純な使い捨てCookieを使用する場合があります。
Simple programming: 予測可能でシンプルなパラメータのセットがリクエストを定義します。ハッカーは次に何が起こるかを正確に知っています。
Target actions: ハッカーは、努力する価値があるように、（送金など）何か重要なことができる必要があります。

以前の被害者を調べることで、CSRF攻撃に伴うリスクを理解してください。大規模なウェブサイトが攻撃を受けています。

INGダイレクト脆弱性により、ハッカーは新しいアカウントを作成し、ある場所から別の場所へ送金することができました。
YouTube。ハッカーは、ユーザーを友人またはお気に入りとして追加し、被害者のログイン名でメモを送信することができました。
ニューヨーク・タイムズハッカーはユーザーのメールアドレスを見つける可能性があります。

注：企業はこれらの脆弱性をすべて修正しました。

CSRF攻撃の作成と配信について

CSRF攻撃は、一般的なブラウザ機能を利用します。リクエストを行うたびに、以下の盗難可能なデータでエンコードされます。

ユーザー名
セッションCookie
IPアドレス
資格情報

メール全人口の約半数が送られてきたものを何でもクリックしてしまいます。ハッカーが、ユーザーがすでにログインしているまさにその瞬間にメモを送信した場合、攻撃はすでに進行中です。
偽造。ハッカーは、被害者がターゲットサイトにログインしている間にも見る可能性のあるページに、通常に見えるフォームまたはスクリプトを作成します。そのサイトへの多くの訪問者はターゲットサイトにログインしていないかもしれませんが、ハッカーはたった一人の訪問者に作業を価値あるものにする必要があります。
ソーシャルエンジニアリングハッカーは、ソーシャルメディアのメッセージングアプリ上の信頼できるソースからのように見えるメモを介して、偽造サイトにアクセスするように被害者を誘導する可能性があります。

CSRF保護チェックリスト

OWASP® Foundationは、これらのCSRF保護手順は機能しないと警告しています。

シークレットCookie：他のCookieと同様に、セッション識別子として共有されることがあります。
POST restrictions: It's common for hackers to target the POST functionality in these attacks.But if you restrict this form, hackers will find another way.
ステップの追加：攻撃者が標準シーケンスを把握できる限り、これは保護を提供しません。
URLリライト：ユーザーのセッションIDはまだ公開されているため、この手順は役に立ちません。

講じるべき4つの保護ステップを以下に示します。

REST：これらの設計原則に従い、アクションを異なるHTTP動詞に割り当てます。ハッカーは、GETリクエストを使用してデータを取得することはできません。これは、表示に固有のものになるためです。
なりすまし防止トークン：サーバーは後続の要求に対してこのコードを要求する必要があり、存在しない場合は、それらの要求を破棄する必要があります。
SameSite Cookie: このGoogleが作成したアンチCSRFツールは、サードパーティからのリクエストとともに送信されるCookieをブロックするのに役立ちます。
確認：ユーザーは、機密性の高いアクションを実行する前にログイン詳細を確認します。