Coders Conquer Security:シェア＆ラーンシリーズ - クロスサイト・リクエスト・フォージェリ
Webサイトやアプリケーションの運営者を狙った攻撃とは異なり、多くのクロスサイトリクエストフォージェリ（CSRF）攻撃の目的は、ユーザーから直接、金品や認証情報を盗むことにあります。これは、サイト運営者がCSRFコードの脆弱性を無視すべきだということを意味するものではありません。純粋に金銭的な攻撃の場合、最終的に盗まれた資金の補充は、安全でないコードを持つホスティングサイトの責任となる可能性があるからです。また、標的となったユーザーが認証情報を紛失したり、知らないうちにパスワードを変更されたりした場合、特に被害者が特権的なアクセス権を持っている場合には、犯罪者は盗んだIDを使って大暴れすることができるかもしれません。
CSRF攻撃はかなり複雑で、成功させるためには複数のレイヤーに依存します。言い換えれば、この攻撃を成功させるためには、多くの要素が攻撃者に有利に働く必要があります。しかし、CSRF攻撃は、成功すればハッカーに直接お金を渡したり、サイト内を自由に動き回れるようにしたりできるため、非常に人気の高い攻撃手段です。すべてがハッカーの思惑通りに進めば、標的となったユーザーは攻撃の被害に遭ったことにさえ気づかないかもしれません。
しかし、CSRF攻撃を成功させるためには多くの要素が必要であるため、攻撃を阻止するための優れた防御技術がいくつかあります。
そのために、CSRF攻撃の3つのポイントについて説明します。
- 仕組み
- なぜ彼らは危険なのか
- 彼らを冷遇するための防御策を講じることができます。
CSRF攻撃の仕組みは？
CSRF攻撃が成功すると、標的となるユーザーから金品や認証情報を直接盗むことができるため、その作成には多大な労力を要するにもかかわらず、人気があります。また、さまざまなプラットフォームで試行されることが多いため、長年にわたってさまざまな名前や称号が付けられてきました。CSRF攻撃は、XSRF、Sea Surf、Session Riding、Cross-Site Reference Forgery、Hostile Linkingなどと呼ばれることもあります。マイクロソフトは、ほとんどのドキュメントでこれらをワンクリック攻撃と呼んでいます。しかし、これらはすべてCSRF攻撃であり、その対策方法も同じです。
CSRF攻撃は、ユーザーがサイトにログインしてビジネスや仕事をしているときに起こります。重要なのは、ユーザーがウェブサイトやアプリケーションにログインし、積極的に認証されていることです。この攻撃は通常、二次的なウェブサイトや電子メールから行われます。多くの場合、攻撃者はソーシャルエンジニアリング技術を使用してユーザーを騙し、攻撃スクリプトが置かれた危険なWebサイトに誘導する電子メール内のリンクをクリックさせます。
侵害されたウェブサイトには、アクティブなブラウザにコマンドを実行するよう指示するスクリプトが含まれています。通常は、ユーザーのパスワードを変更したり、攻撃者が管理する口座に送金したりするような悪質なものです。ユーザーが認証されている限り、サイトはそのコマンドが認証されたユーザーによって発行されたものであると考えます。なぜそうしないのでしょうか？ユーザーはすでに自分自身を認証し、サイトにアクセスするために必要なパスワードを提供しています。また、ジオフェンス内にいて、オフィスの端末に座っているかもしれません。パスワードの変更や送金をしたいと思ったとき、それを要求したのが本人であると信じない理由はないだろう。
この攻撃の要素を分解してみると、なぜこの攻撃が攻撃者にとって非常に難しいものであるかがわかります。まず、攻撃が行われるサイトでは、ユーザーが積極的に認証を受ける必要があります。ユーザーがブラウザのセッションを終了したり、ログオフしたりした後に、攻撃スクリプトを含むメールが届いた場合、攻撃は失敗します。
また、攻撃者は、そのサイトがどのようなスクリプトを受け入れるかを知るために、標的となるサイトで多くのリコンを行う必要があります。攻撃者は被害者の画面を見ることができず、ウェブサイトからのフィードバックは攻撃者ではなく被害者に送られます。攻撃者は、被害者の口座に突然お金が入ってくるなど、攻撃が成功した証拠を見ることができなければ、攻撃が成功したかどうかもすぐにはわかりません。
CSRF攻撃を実行するためのコードは、攻撃時にユーザーがログインしていること、標的となるサイトがどのようなスクリプトを受け入れるかを知っていることという、難しいようでいて不可能ではない条件の中で、サイト自体によって異なりますが、非常にシンプルなものになります。
例えば、銀行や金融機関のアプリケーションが、以下のようにGETリクエストを使って送金するとします。
GET http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1
このコードは、NancySmith12というユーザーに100ドルを送金するリクエストを送信します。
しかし、ターゲットとなったユーザーが、同僚を装ったメールを受け取った場合、クリック操作にCSRF攻撃スクリプトが埋め込まれる可能性があります。
<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Can you quickly read over this quarterly report?<a></a></a>
ターゲットとなったユーザーがソーシャルエンジニアリングリンクに引っかかり、ファイナンスアプリケーションのブラウザセッションがまだ開いている間にリンクをクリックすると、ブラウザはアプリケーションにShadyLady15の口座に10万ドルを送金するように要求します。
このスクリプトは、ユーザーには見えないが、ブラウザがリクエストを行うきっかけとなるような不可視の画像の中に隠すこともできます。
<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">
結果は同じです。ShadyLady15は、誰にも攻撃を検知されずに10万ドルを手に入れます。
なぜCSRFは危険なのか？
CSRF攻撃は、ランサムウェアが流行し続けているのと同じ理由で、現在人気があります。CSRF攻撃は、攻撃者と被害者の資金の間のホップが非常に少ないのです。ランサムウェア攻撃では、システムが暗号化され、ユーザーはそのデータを解読するために金銭を要求されます。CSRF攻撃では、さらに少ないステップで攻撃を行うことができます。CSRF攻撃が成功すると、被害者は知らないうちに攻撃者にお金を送ってしまいます。
CSRF攻撃が成功すると、被害者の金銭や企業の財務に対する直接的な攻撃だけでなく、有効なユーザーを使ってネットワークを侵害することができます。もし攻撃者がCSRF攻撃を利用して管理者のパスワードを変更したとしたらどうでしょう。攻撃者はすぐにそのパスワードを使用して、データの盗み出し、ネットワーク防御の穴を開け、バックドアをインストールすることができます。
CSRF攻撃を成功させるには、多大な労力とある程度の運が必要ですが、ハッカーにとっては、最終的な目的にかかわらず、宝くじに当たるようなものです。ネットワークを攻撃する場合、他のほとんどの種類の攻撃では、SIEMやサイバーセキュリティ担当者のレーダーに映らないようにしながら、何ヶ月もかけてじっくりと偵察する必要があります。これに対して、CSRF攻撃は、サイバーキルチェーンのいくつかのステップをスキップして、最終的な目標に非常に近いところからスタートさせることができます。
CSRF攻撃を防ぐにはどうすればいいですか？
一般的な脆弱性とは異なり、CSRF攻撃では、コードではなく、攻撃者が作成したエクスプロイトを利用して、ユーザーが望まない、あるいは知らないリクエストをブラウザにさせることができます。しかし、これらの攻撃は防ぐことができます。
最良の方法の1つは、新しいセッションが生成されるたびに、開発者がユーザーのIDにCSRFトークンを追加することです。このトークンは、ユニークでランダムな文字列で構成され、ユーザーからは見えないようにする必要があります。次に、新しいリクエストが送信されるたびにサーバがチェックするフォームに、CSRFトークンのリクエストを隠しフィールドとして追加します。ユーザーのブラウザを介してリクエストを送信する攻撃者は、隠されたトークン・フィールドについて知ることもできず、ましてやそれが何であるかを知ることもできないので、リクエストはすべて失敗します。
さらに簡単な方法で、プログラミングをあまり必要としないものは、パスワード変更要求や送金注文のような機密性の高いものにCaptchaチャレンジを追加することである。これは、リクエスト者がロボットでないこと、あるいはこの場合はCSRFスクリプトでないことを確認するボタンを1つクリックしてもらうだけの簡単なものである。攻撃者はこのチャレンジに対するレスポンスをスクリプト化することができないので、送金リクエストのようなことを最初に行わずに突然CAPTCHAチャレンジを受けたユーザーは、何かが起きていることに気づくだろう。あるいは、組織がセキュリティの名の下にどれだけ作業を遅らせたいかにもよるが、スマートフォンのようなサードパーティトークンを使ったワンタイムパスワード生成も利用できる。
最後に、鉄壁ではありませんが、Microsoft EdgeやGoogle Chromeなどの多くのブラウザには、ローカルユーザ以外からのリクエストをブロックする同一オリジンポリシーの制限が設けられています。ユーザーにこれらのブラウザの最新バージョンを使ってサイトにアクセスしてもらうことで、開発チームに負担をかけることなく、CSRFのセキュリティをさらに強化することができます。
CSRFの扉を閉める
しかし、なぜこのような攻撃が行われるのか、また、どのようにしてネットワークから遮断すればよいのかをご理解いただけたのではないでしょうか。
さらに詳しい情報は、OWASP Cross-Site Request Forgery Prevention Cheat Sheetをご覧ください。また、セキュリティに関する知識を深めたい方は、以下のブログをご覧になり、この脅威に対抗する方法を学んでください。 Secure Code Warriorブログをご覧ください。
新しいディフェンスの知識を試す準備ができたと思いますか？Secure Code Warrior プラットフォームの無料デモで遊んでみてください。
CSRF攻撃はかなり複雑で、成功させるためには複数のレイヤーに依存します。言い換えれば、この攻撃を成功させるためには、多くのものが攻撃者に有利に働く必要があります。にもかかわらず、CSRF攻撃は非常に人気があり、収益性の高い攻撃手段です。
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
デモを予約する
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
Webサイトやアプリケーションの運営者を狙った攻撃とは異なり、多くのクロスサイトリクエストフォージェリ（CSRF）攻撃の目的は、ユーザーから直接、金品や認証情報を盗むことにあります。これは、サイト運営者がCSRFコードの脆弱性を無視すべきだということを意味するものではありません。純粋に金銭的な攻撃の場合、最終的に盗まれた資金の補充は、安全でないコードを持つホスティングサイトの責任となる可能性があるからです。また、標的となったユーザーが認証情報を紛失したり、知らないうちにパスワードを変更されたりした場合、特に被害者が特権的なアクセス権を持っている場合には、犯罪者は盗んだIDを使って大暴れすることができるかもしれません。
CSRF攻撃はかなり複雑で、成功させるためには複数のレイヤーに依存します。言い換えれば、この攻撃を成功させるためには、多くの要素が攻撃者に有利に働く必要があります。しかし、CSRF攻撃は、成功すればハッカーに直接お金を渡したり、サイト内を自由に動き回れるようにしたりできるため、非常に人気の高い攻撃手段です。すべてがハッカーの思惑通りに進めば、標的となったユーザーは攻撃の被害に遭ったことにさえ気づかないかもしれません。
しかし、CSRF攻撃を成功させるためには多くの要素が必要であるため、攻撃を阻止するための優れた防御技術がいくつかあります。
そのために、CSRF攻撃の3つのポイントについて説明します。
- 仕組み
- なぜ彼らは危険なのか
- 彼らを冷遇するための防御策を講じることができます。
CSRF攻撃の仕組みは？
CSRF攻撃が成功すると、標的となるユーザーから金品や認証情報を直接盗むことができるため、その作成には多大な労力を要するにもかかわらず、人気があります。また、さまざまなプラットフォームで試行されることが多いため、長年にわたってさまざまな名前や称号が付けられてきました。CSRF攻撃は、XSRF、Sea Surf、Session Riding、Cross-Site Reference Forgery、Hostile Linkingなどと呼ばれることもあります。マイクロソフトは、ほとんどのドキュメントでこれらをワンクリック攻撃と呼んでいます。しかし、これらはすべてCSRF攻撃であり、その対策方法も同じです。
CSRF攻撃は、ユーザーがサイトにログインしてビジネスや仕事をしているときに起こります。重要なのは、ユーザーがウェブサイトやアプリケーションにログインし、積極的に認証されていることです。この攻撃は通常、二次的なウェブサイトや電子メールから行われます。多くの場合、攻撃者はソーシャルエンジニアリング技術を使用してユーザーを騙し、攻撃スクリプトが置かれた危険なWebサイトに誘導する電子メール内のリンクをクリックさせます。
侵害されたウェブサイトには、アクティブなブラウザにコマンドを実行するよう指示するスクリプトが含まれています。通常は、ユーザーのパスワードを変更したり、攻撃者が管理する口座に送金したりするような悪質なものです。ユーザーが認証されている限り、サイトはそのコマンドが認証されたユーザーによって発行されたものであると考えます。なぜそうしないのでしょうか？ユーザーはすでに自分自身を認証し、サイトにアクセスするために必要なパスワードを提供しています。また、ジオフェンス内にいて、オフィスの端末に座っているかもしれません。パスワードの変更や送金をしたいと思ったとき、それを要求したのが本人であると信じない理由はないだろう。
この攻撃の要素を分解してみると、なぜこの攻撃が攻撃者にとって非常に難しいものであるかがわかります。まず、攻撃が行われるサイトでは、ユーザーが積極的に認証を受ける必要があります。ユーザーがブラウザのセッションを終了したり、ログオフしたりした後に、攻撃スクリプトを含むメールが届いた場合、攻撃は失敗します。
また、攻撃者は、そのサイトがどのようなスクリプトを受け入れるかを知るために、標的となるサイトで多くのリコンを行う必要があります。攻撃者は被害者の画面を見ることができず、ウェブサイトからのフィードバックは攻撃者ではなく被害者に送られます。攻撃者は、被害者の口座に突然お金が入ってくるなど、攻撃が成功した証拠を見ることができなければ、攻撃が成功したかどうかもすぐにはわかりません。
CSRF攻撃を実行するためのコードは、攻撃時にユーザーがログインしていること、標的となるサイトがどのようなスクリプトを受け入れるかを知っていることという、難しいようでいて不可能ではない条件の中で、サイト自体によって異なりますが、非常にシンプルなものになります。
例えば、銀行や金融機関のアプリケーションが、以下のようにGETリクエストを使って送金するとします。
GET http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1
このコードは、NancySmith12というユーザーに100ドルを送金するリクエストを送信します。
しかし、ターゲットとなったユーザーが、同僚を装ったメールを受け取った場合、クリック操作にCSRF攻撃スクリプトが埋め込まれる可能性があります。
<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Can you quickly read over this quarterly report?<a></a></a>
ターゲットとなったユーザーがソーシャルエンジニアリングリンクに引っかかり、ファイナンスアプリケーションのブラウザセッションがまだ開いている間にリンクをクリックすると、ブラウザはアプリケーションにShadyLady15の口座に10万ドルを送金するように要求します。
このスクリプトは、ユーザーには見えないが、ブラウザがリクエストを行うきっかけとなるような不可視の画像の中に隠すこともできます。
<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">
結果は同じです。ShadyLady15は、誰にも攻撃を検知されずに10万ドルを手に入れます。
なぜCSRFは危険なのか？
CSRF攻撃は、ランサムウェアが流行し続けているのと同じ理由で、現在人気があります。CSRF攻撃は、攻撃者と被害者の資金の間のホップが非常に少ないのです。ランサムウェア攻撃では、システムが暗号化され、ユーザーはそのデータを解読するために金銭を要求されます。CSRF攻撃では、さらに少ないステップで攻撃を行うことができます。CSRF攻撃が成功すると、被害者は知らないうちに攻撃者にお金を送ってしまいます。
CSRF攻撃が成功すると、被害者の金銭や企業の財務に対する直接的な攻撃だけでなく、有効なユーザーを使ってネットワークを侵害することができます。もし攻撃者がCSRF攻撃を利用して管理者のパスワードを変更したとしたらどうでしょう。攻撃者はすぐにそのパスワードを使用して、データの盗み出し、ネットワーク防御の穴を開け、バックドアをインストールすることができます。
CSRF攻撃を成功させるには、多大な労力とある程度の運が必要ですが、ハッカーにとっては、最終的な目的にかかわらず、宝くじに当たるようなものです。ネットワークを攻撃する場合、他のほとんどの種類の攻撃では、SIEMやサイバーセキュリティ担当者のレーダーに映らないようにしながら、何ヶ月もかけてじっくりと偵察する必要があります。これに対して、CSRF攻撃は、サイバーキルチェーンのいくつかのステップをスキップして、最終的な目標に非常に近いところからスタートさせることができます。
CSRF攻撃を防ぐにはどうすればいいですか？
一般的な脆弱性とは異なり、CSRF攻撃では、コードではなく、攻撃者が作成したエクスプロイトを利用して、ユーザーが望まない、あるいは知らないリクエストをブラウザにさせることができます。しかし、これらの攻撃は防ぐことができます。
最良の方法の1つは、新しいセッションが生成されるたびに、開発者がユーザーのIDにCSRFトークンを追加することです。このトークンは、ユニークでランダムな文字列で構成され、ユーザーからは見えないようにする必要があります。次に、新しいリクエストが送信されるたびにサーバがチェックするフォームに、CSRFトークンのリクエストを隠しフィールドとして追加します。ユーザーのブラウザを介してリクエストを送信する攻撃者は、隠されたトークン・フィールドについて知ることもできず、ましてやそれが何であるかを知ることもできないので、リクエストはすべて失敗します。
さらに簡単な方法で、プログラミングをあまり必要としないものは、パスワード変更要求や送金注文のような機密性の高いものにCaptchaチャレンジを追加することである。これは、リクエスト者がロボットでないこと、あるいはこの場合はCSRFスクリプトでないことを確認するボタンを1つクリックしてもらうだけの簡単なものである。攻撃者はこのチャレンジに対するレスポンスをスクリプト化することができないので、送金リクエストのようなことを最初に行わずに突然CAPTCHAチャレンジを受けたユーザーは、何かが起きていることに気づくだろう。あるいは、組織がセキュリティの名の下にどれだけ作業を遅らせたいかにもよるが、スマートフォンのようなサードパーティトークンを使ったワンタイムパスワード生成も利用できる。
最後に、鉄壁ではありませんが、Microsoft EdgeやGoogle Chromeなどの多くのブラウザには、ローカルユーザ以外からのリクエストをブロックする同一オリジンポリシーの制限が設けられています。ユーザーにこれらのブラウザの最新バージョンを使ってサイトにアクセスしてもらうことで、開発チームに負担をかけることなく、CSRFのセキュリティをさらに強化することができます。
CSRFの扉を閉める
しかし、なぜこのような攻撃が行われるのか、また、どのようにしてネットワークから遮断すればよいのかをご理解いただけたのではないでしょうか。
さらに詳しい情報は、OWASP Cross-Site Request Forgery Prevention Cheat Sheetをご覧ください。また、セキュリティに関する知識を深めたい方は、以下のブログをご覧になり、この脅威に対抗する方法を学んでください。 Secure Code Warriorブログをご覧ください。
新しいディフェンスの知識を試す準備ができたと思いますか？Secure Code Warrior プラットフォームの無料デモで遊んでみてください。
Webサイトやアプリケーションの運営者を狙った攻撃とは異なり、多くのクロスサイトリクエストフォージェリ（CSRF）攻撃の目的は、ユーザーから直接、金品や認証情報を盗むことにあります。これは、サイト運営者がCSRFコードの脆弱性を無視すべきだということを意味するものではありません。純粋に金銭的な攻撃の場合、最終的に盗まれた資金の補充は、安全でないコードを持つホスティングサイトの責任となる可能性があるからです。また、標的となったユーザーが認証情報を紛失したり、知らないうちにパスワードを変更されたりした場合、特に被害者が特権的なアクセス権を持っている場合には、犯罪者は盗んだIDを使って大暴れすることができるかもしれません。
CSRF攻撃はかなり複雑で、成功させるためには複数のレイヤーに依存します。言い換えれば、この攻撃を成功させるためには、多くの要素が攻撃者に有利に働く必要があります。しかし、CSRF攻撃は、成功すればハッカーに直接お金を渡したり、サイト内を自由に動き回れるようにしたりできるため、非常に人気の高い攻撃手段です。すべてがハッカーの思惑通りに進めば、標的となったユーザーは攻撃の被害に遭ったことにさえ気づかないかもしれません。
しかし、CSRF攻撃を成功させるためには多くの要素が必要であるため、攻撃を阻止するための優れた防御技術がいくつかあります。
そのために、CSRF攻撃の3つのポイントについて説明します。
- 仕組み
- なぜ彼らは危険なのか
- 彼らを冷遇するための防御策を講じることができます。
CSRF攻撃の仕組みは？
CSRF攻撃が成功すると、標的となるユーザーから金品や認証情報を直接盗むことができるため、その作成には多大な労力を要するにもかかわらず、人気があります。また、さまざまなプラットフォームで試行されることが多いため、長年にわたってさまざまな名前や称号が付けられてきました。CSRF攻撃は、XSRF、Sea Surf、Session Riding、Cross-Site Reference Forgery、Hostile Linkingなどと呼ばれることもあります。マイクロソフトは、ほとんどのドキュメントでこれらをワンクリック攻撃と呼んでいます。しかし、これらはすべてCSRF攻撃であり、その対策方法も同じです。
CSRF攻撃は、ユーザーがサイトにログインしてビジネスや仕事をしているときに起こります。重要なのは、ユーザーがウェブサイトやアプリケーションにログインし、積極的に認証されていることです。この攻撃は通常、二次的なウェブサイトや電子メールから行われます。多くの場合、攻撃者はソーシャルエンジニアリング技術を使用してユーザーを騙し、攻撃スクリプトが置かれた危険なWebサイトに誘導する電子メール内のリンクをクリックさせます。
侵害されたウェブサイトには、アクティブなブラウザにコマンドを実行するよう指示するスクリプトが含まれています。通常は、ユーザーのパスワードを変更したり、攻撃者が管理する口座に送金したりするような悪質なものです。ユーザーが認証されている限り、サイトはそのコマンドが認証されたユーザーによって発行されたものであると考えます。なぜそうしないのでしょうか？ユーザーはすでに自分自身を認証し、サイトにアクセスするために必要なパスワードを提供しています。また、ジオフェンス内にいて、オフィスの端末に座っているかもしれません。パスワードの変更や送金をしたいと思ったとき、それを要求したのが本人であると信じない理由はないだろう。
この攻撃の要素を分解してみると、なぜこの攻撃が攻撃者にとって非常に難しいものであるかがわかります。まず、攻撃が行われるサイトでは、ユーザーが積極的に認証を受ける必要があります。ユーザーがブラウザのセッションを終了したり、ログオフしたりした後に、攻撃スクリプトを含むメールが届いた場合、攻撃は失敗します。
また、攻撃者は、そのサイトがどのようなスクリプトを受け入れるかを知るために、標的となるサイトで多くのリコンを行う必要があります。攻撃者は被害者の画面を見ることができず、ウェブサイトからのフィードバックは攻撃者ではなく被害者に送られます。攻撃者は、被害者の口座に突然お金が入ってくるなど、攻撃が成功した証拠を見ることができなければ、攻撃が成功したかどうかもすぐにはわかりません。
CSRF攻撃を実行するためのコードは、攻撃時にユーザーがログインしていること、標的となるサイトがどのようなスクリプトを受け入れるかを知っていることという、難しいようでいて不可能ではない条件の中で、サイト自体によって異なりますが、非常にシンプルなものになります。
例えば、銀行や金融機関のアプリケーションが、以下のようにGETリクエストを使って送金するとします。
GET http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1
このコードは、NancySmith12というユーザーに100ドルを送金するリクエストを送信します。
しかし、ターゲットとなったユーザーが、同僚を装ったメールを受け取った場合、クリック操作にCSRF攻撃スクリプトが埋め込まれる可能性があります。
<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Can you quickly read over this quarterly report?<a></a></a>
ターゲットとなったユーザーがソーシャルエンジニアリングリンクに引っかかり、ファイナンスアプリケーションのブラウザセッションがまだ開いている間にリンクをクリックすると、ブラウザはアプリケーションにShadyLady15の口座に10万ドルを送金するように要求します。
このスクリプトは、ユーザーには見えないが、ブラウザがリクエストを行うきっかけとなるような不可視の画像の中に隠すこともできます。
<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">
結果は同じです。ShadyLady15は、誰にも攻撃を検知されずに10万ドルを手に入れます。
なぜCSRFは危険なのか？
CSRF攻撃は、ランサムウェアが流行し続けているのと同じ理由で、現在人気があります。CSRF攻撃は、攻撃者と被害者の資金の間のホップが非常に少ないのです。ランサムウェア攻撃では、システムが暗号化され、ユーザーはそのデータを解読するために金銭を要求されます。CSRF攻撃では、さらに少ないステップで攻撃を行うことができます。CSRF攻撃が成功すると、被害者は知らないうちに攻撃者にお金を送ってしまいます。
CSRF攻撃が成功すると、被害者の金銭や企業の財務に対する直接的な攻撃だけでなく、有効なユーザーを使ってネットワークを侵害することができます。もし攻撃者がCSRF攻撃を利用して管理者のパスワードを変更したとしたらどうでしょう。攻撃者はすぐにそのパスワードを使用して、データの盗み出し、ネットワーク防御の穴を開け、バックドアをインストールすることができます。
CSRF攻撃を成功させるには、多大な労力とある程度の運が必要ですが、ハッカーにとっては、最終的な目的にかかわらず、宝くじに当たるようなものです。ネットワークを攻撃する場合、他のほとんどの種類の攻撃では、SIEMやサイバーセキュリティ担当者のレーダーに映らないようにしながら、何ヶ月もかけてじっくりと偵察する必要があります。これに対して、CSRF攻撃は、サイバーキルチェーンのいくつかのステップをスキップして、最終的な目標に非常に近いところからスタートさせることができます。
CSRF攻撃を防ぐにはどうすればいいですか？
一般的な脆弱性とは異なり、CSRF攻撃では、コードではなく、攻撃者が作成したエクスプロイトを利用して、ユーザーが望まない、あるいは知らないリクエストをブラウザにさせることができます。しかし、これらの攻撃は防ぐことができます。
最良の方法の1つは、新しいセッションが生成されるたびに、開発者がユーザーのIDにCSRFトークンを追加することです。このトークンは、ユニークでランダムな文字列で構成され、ユーザーからは見えないようにする必要があります。次に、新しいリクエストが送信されるたびにサーバがチェックするフォームに、CSRFトークンのリクエストを隠しフィールドとして追加します。ユーザーのブラウザを介してリクエストを送信する攻撃者は、隠されたトークン・フィールドについて知ることもできず、ましてやそれが何であるかを知ることもできないので、リクエストはすべて失敗します。
さらに簡単な方法で、プログラミングをあまり必要としないものは、パスワード変更要求や送金注文のような機密性の高いものにCaptchaチャレンジを追加することである。これは、リクエスト者がロボットでないこと、あるいはこの場合はCSRFスクリプトでないことを確認するボタンを1つクリックしてもらうだけの簡単なものである。攻撃者はこのチャレンジに対するレスポンスをスクリプト化することができないので、送金リクエストのようなことを最初に行わずに突然CAPTCHAチャレンジを受けたユーザーは、何かが起きていることに気づくだろう。あるいは、組織がセキュリティの名の下にどれだけ作業を遅らせたいかにもよるが、スマートフォンのようなサードパーティトークンを使ったワンタイムパスワード生成も利用できる。
最後に、鉄壁ではありませんが、Microsoft EdgeやGoogle Chromeなどの多くのブラウザには、ローカルユーザ以外からのリクエストをブロックする同一オリジンポリシーの制限が設けられています。ユーザーにこれらのブラウザの最新バージョンを使ってサイトにアクセスしてもらうことで、開発チームに負担をかけることなく、CSRFのセキュリティをさらに強化することができます。
CSRFの扉を閉める
しかし、なぜこのような攻撃が行われるのか、また、どのようにしてネットワークから遮断すればよいのかをご理解いただけたのではないでしょうか。
さらに詳しい情報は、OWASP Cross-Site Request Forgery Prevention Cheat Sheetをご覧ください。また、セキュリティに関する知識を深めたい方は、以下のブログをご覧になり、この脅威に対抗する方法を学んでください。 Secure Code Warriorブログをご覧ください。
新しいディフェンスの知識を試す準備ができたと思いますか？Secure Code Warrior プラットフォームの無料デモで遊んでみてください。
以下のリンクをクリックし、この資料のPDFをダウンロードしてください。
Secure Code Warrior は、ソフトウェア開発ライフサイクル全体にわたってコードを保護し、サイバーセキュリティを最優先とする企業文化を創造するために、お客様の組織を支援します。AppSec マネージャー、開発者、CISO、またはセキュリティに関わるすべての人が、安全でないコードに関連するリスクを減らすことができるよう、支援します。
レポートを見るデモを予約する
Jaap Karan Singhは、Secure Coding Evangelistであり、Chief Singhであり、Secure Code Warrior の共同設立者です。
Webサイトやアプリケーションの運営者を狙った攻撃とは異なり、多くのクロスサイトリクエストフォージェリ（CSRF）攻撃の目的は、ユーザーから直接、金品や認証情報を盗むことにあります。これは、サイト運営者がCSRFコードの脆弱性を無視すべきだということを意味するものではありません。純粋に金銭的な攻撃の場合、最終的に盗まれた資金の補充は、安全でないコードを持つホスティングサイトの責任となる可能性があるからです。また、標的となったユーザーが認証情報を紛失したり、知らないうちにパスワードを変更されたりした場合、特に被害者が特権的なアクセス権を持っている場合には、犯罪者は盗んだIDを使って大暴れすることができるかもしれません。
CSRF攻撃はかなり複雑で、成功させるためには複数のレイヤーに依存します。言い換えれば、この攻撃を成功させるためには、多くの要素が攻撃者に有利に働く必要があります。しかし、CSRF攻撃は、成功すればハッカーに直接お金を渡したり、サイト内を自由に動き回れるようにしたりできるため、非常に人気の高い攻撃手段です。すべてがハッカーの思惑通りに進めば、標的となったユーザーは攻撃の被害に遭ったことにさえ気づかないかもしれません。
しかし、CSRF攻撃を成功させるためには多くの要素が必要であるため、攻撃を阻止するための優れた防御技術がいくつかあります。
そのために、CSRF攻撃の3つのポイントについて説明します。
- 仕組み
- なぜ彼らは危険なのか
- 彼らを冷遇するための防御策を講じることができます。
CSRF攻撃の仕組みは？
CSRF攻撃が成功すると、標的となるユーザーから金品や認証情報を直接盗むことができるため、その作成には多大な労力を要するにもかかわらず、人気があります。また、さまざまなプラットフォームで試行されることが多いため、長年にわたってさまざまな名前や称号が付けられてきました。CSRF攻撃は、XSRF、Sea Surf、Session Riding、Cross-Site Reference Forgery、Hostile Linkingなどと呼ばれることもあります。マイクロソフトは、ほとんどのドキュメントでこれらをワンクリック攻撃と呼んでいます。しかし、これらはすべてCSRF攻撃であり、その対策方法も同じです。
CSRF攻撃は、ユーザーがサイトにログインしてビジネスや仕事をしているときに起こります。重要なのは、ユーザーがウェブサイトやアプリケーションにログインし、積極的に認証されていることです。この攻撃は通常、二次的なウェブサイトや電子メールから行われます。多くの場合、攻撃者はソーシャルエンジニアリング技術を使用してユーザーを騙し、攻撃スクリプトが置かれた危険なWebサイトに誘導する電子メール内のリンクをクリックさせます。
侵害されたウェブサイトには、アクティブなブラウザにコマンドを実行するよう指示するスクリプトが含まれています。通常は、ユーザーのパスワードを変更したり、攻撃者が管理する口座に送金したりするような悪質なものです。ユーザーが認証されている限り、サイトはそのコマンドが認証されたユーザーによって発行されたものであると考えます。なぜそうしないのでしょうか？ユーザーはすでに自分自身を認証し、サイトにアクセスするために必要なパスワードを提供しています。また、ジオフェンス内にいて、オフィスの端末に座っているかもしれません。パスワードの変更や送金をしたいと思ったとき、それを要求したのが本人であると信じない理由はないだろう。
この攻撃の要素を分解してみると、なぜこの攻撃が攻撃者にとって非常に難しいものであるかがわかります。まず、攻撃が行われるサイトでは、ユーザーが積極的に認証を受ける必要があります。ユーザーがブラウザのセッションを終了したり、ログオフしたりした後に、攻撃スクリプトを含むメールが届いた場合、攻撃は失敗します。
また、攻撃者は、そのサイトがどのようなスクリプトを受け入れるかを知るために、標的となるサイトで多くのリコンを行う必要があります。攻撃者は被害者の画面を見ることができず、ウェブサイトからのフィードバックは攻撃者ではなく被害者に送られます。攻撃者は、被害者の口座に突然お金が入ってくるなど、攻撃が成功した証拠を見ることができなければ、攻撃が成功したかどうかもすぐにはわかりません。
CSRF攻撃を実行するためのコードは、攻撃時にユーザーがログインしていること、標的となるサイトがどのようなスクリプトを受け入れるかを知っていることという、難しいようでいて不可能ではない条件の中で、サイト自体によって異なりますが、非常にシンプルなものになります。
例えば、銀行や金融機関のアプリケーションが、以下のようにGETリクエストを使って送金するとします。
GET http://bank.com/transferdo?acct=NancySmith12&amount=100 HTTP/1.1
このコードは、NancySmith12というユーザーに100ドルを送金するリクエストを送信します。
しかし、ターゲットとなったユーザーが、同僚を装ったメールを受け取った場合、クリック操作にCSRF攻撃スクリプトが埋め込まれる可能性があります。
<a href="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000">Can you quickly read over this quarterly report?<a></a></a>
ターゲットとなったユーザーがソーシャルエンジニアリングリンクに引っかかり、ファイナンスアプリケーションのブラウザセッションがまだ開いている間にリンクをクリックすると、ブラウザはアプリケーションにShadyLady15の口座に10万ドルを送金するように要求します。
このスクリプトは、ユーザーには見えないが、ブラウザがリクエストを行うきっかけとなるような不可視の画像の中に隠すこともできます。
<img src="http://bank.com/transfer.do?acct=ShadyLady15&amount=100000" width="0" height="0" border="0">
結果は同じです。ShadyLady15は、誰にも攻撃を検知されずに10万ドルを手に入れます。
なぜCSRFは危険なのか？
CSRF攻撃は、ランサムウェアが流行し続けているのと同じ理由で、現在人気があります。CSRF攻撃は、攻撃者と被害者の資金の間のホップが非常に少ないのです。ランサムウェア攻撃では、システムが暗号化され、ユーザーはそのデータを解読するために金銭を要求されます。CSRF攻撃では、さらに少ないステップで攻撃を行うことができます。CSRF攻撃が成功すると、被害者は知らないうちに攻撃者にお金を送ってしまいます。
CSRF攻撃が成功すると、被害者の金銭や企業の財務に対する直接的な攻撃だけでなく、有効なユーザーを使ってネットワークを侵害することができます。もし攻撃者がCSRF攻撃を利用して管理者のパスワードを変更したとしたらどうでしょう。攻撃者はすぐにそのパスワードを使用して、データの盗み出し、ネットワーク防御の穴を開け、バックドアをインストールすることができます。
CSRF攻撃を成功させるには、多大な労力とある程度の運が必要ですが、ハッカーにとっては、最終的な目的にかかわらず、宝くじに当たるようなものです。ネットワークを攻撃する場合、他のほとんどの種類の攻撃では、SIEMやサイバーセキュリティ担当者のレーダーに映らないようにしながら、何ヶ月もかけてじっくりと偵察する必要があります。これに対して、CSRF攻撃は、サイバーキルチェーンのいくつかのステップをスキップして、最終的な目標に非常に近いところからスタートさせることができます。
CSRF攻撃を防ぐにはどうすればいいですか？
一般的な脆弱性とは異なり、CSRF攻撃では、コードではなく、攻撃者が作成したエクスプロイトを利用して、ユーザーが望まない、あるいは知らないリクエストをブラウザにさせることができます。しかし、これらの攻撃は防ぐことができます。
最良の方法の1つは、新しいセッションが生成されるたびに、開発者がユーザーのIDにCSRFトークンを追加することです。このトークンは、ユニークでランダムな文字列で構成され、ユーザーからは見えないようにする必要があります。次に、新しいリクエストが送信されるたびにサーバがチェックするフォームに、CSRFトークンのリクエストを隠しフィールドとして追加します。ユーザーのブラウザを介してリクエストを送信する攻撃者は、隠されたトークン・フィールドについて知ることもできず、ましてやそれが何であるかを知ることもできないので、リクエストはすべて失敗します。
さらに簡単な方法で、プログラミングをあまり必要としないものは、パスワード変更要求や送金注文のような機密性の高いものにCaptchaチャレンジを追加することである。これは、リクエスト者がロボットでないこと、あるいはこの場合はCSRFスクリプトでないことを確認するボタンを1つクリックしてもらうだけの簡単なものである。攻撃者はこのチャレンジに対するレスポンスをスクリプト化することができないので、送金リクエストのようなことを最初に行わずに突然CAPTCHAチャレンジを受けたユーザーは、何かが起きていることに気づくだろう。あるいは、組織がセキュリティの名の下にどれだけ作業を遅らせたいかにもよるが、スマートフォンのようなサードパーティトークンを使ったワンタイムパスワード生成も利用できる。
最後に、鉄壁ではありませんが、Microsoft EdgeやGoogle Chromeなどの多くのブラウザには、ローカルユーザ以外からのリクエストをブロックする同一オリジンポリシーの制限が設けられています。ユーザーにこれらのブラウザの最新バージョンを使ってサイトにアクセスしてもらうことで、開発チームに負担をかけることなく、CSRFのセキュリティをさらに強化することができます。
CSRFの扉を閉める
しかし、なぜこのような攻撃が行われるのか、また、どのようにしてネットワークから遮断すればよいのかをご理解いただけたのではないでしょうか。
さらに詳しい情報は、OWASP Cross-Site Request Forgery Prevention Cheat Sheetをご覧ください。また、セキュリティに関する知識を深めたい方は、以下のブログをご覧になり、この脅威に対抗する方法を学んでください。 Secure Code Warriorブログをご覧ください。
新しいディフェンスの知識を試す準備ができたと思いますか？Secure Code Warrior プラットフォームの無料デモで遊んでみてください。
始めるためのリソース
Trust Agent:AI - Secure and scale AI-Drive development
AI is writing code. Who’s governing it? With up to 50% of AI-generated code containing security weaknesses, managing AI risk is critical. Discover how SCW's Trust Agent: AI provides the real-time visibility, proactive governance, and targeted upskilling needed to scale AI-driven development securely.
OpenText アプリケーションセキュリティのパワー + Secure Code Warrior
OpenText Application Security and Secure Code Warrior combine vulnerability detection with AI Software Governance and developer capability. Together, they help organizations reduce risk, strengthen secure coding practices, and confidently adopt AI-driven development.
Secure Code Warrior corporate overview
Secure Code Warrior is an AI Software Governance platform designed to enable organizations to safely adopt AI-driven development by bridging the gap between development velocity and enterprise security. The platform addresses the "Visibility Gap," where security teams often lack insights into shadow AI coding tools and the origins of production code.
セキュアコード・トレーニングのトピックと内容
Our industry-leading content is always evolving to fit the ever changing software development landscape with your role in mind. Topics covering everything from AI to XQuery Injection, offered for a variety of roles from Architects and Engineers to Product Managers and QA. Get a sneak peek of what our content catalog has to offer by topic and role.
始めるためのリソース
.png)
Observe and Secure the ADLC: A Four-Point Framework for CISOs and Development Teams Using AI
While development teams look to make the most of GenAI’s undeniable benefits, we’d like to propose a four-point foundational framework that will allow security leaders to deploy AI coding tools and agents with a higher, more relevant standard of security best practices. It details exactly what enterprises can do to ensure safe, secure code development right now, and as agentic AI becomes an even bigger factor in the future.
