私はWebアプリケーション診断を専門としていますが、レガシーなシステムにおいて「クロスサイトリクエストフォージェリ（CSRF）」が頻繁に検出されるので今回は本脆弱性について書いていきます。

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

CSRFとも呼ばれるクロスサイトリクエストフォージェリは、OWASPトップ10Webアプリケーションセキュリティリスクの1つとして特定されているWebセキュリティの脆弱性の一種です。
CSRF攻撃によって、認証されたユーザーがWebアプリケーションまたはサイトに不要な要求を送信することになります。これにより、攻撃者は悪意のあるコンテンツを作成して、正当なWebサイトにすでにログインして認証されているユーザーをだまして、意図せず、気付かない可能性のあるアクションを実行させることができます。

関連ブログ：OWASP Top 10ってなに？
　　　　　　届出件数1位。「クロスサイトスクリプティング」とは？

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

CSRF攻撃は、Webアプリケーションが認証と資格情報のチェックを処理する方法の欠陥を悪用します。ユーザーがWebアプリケーションを利用する際、何らかの形式の永続的なCookieまたは資格情報を使用してターゲットサイトに対して認証される必要があります。これは、Webブラウザからターゲットサイトに送信されるすべてのリクエストに、それらのCookieまたはクレデンシャルが含まれることを意味し、ユーザーがログインする必要があるほとんどのサイトの機能の重要な部分です。結局のところ、人々はソーシャルメディアやメンバーシップサイトをすぐに離れ、別のページにアクセスしたり新しいブラウザを開いたりするたびに再度ログインする必要があります。

ログインしていない人からCSRFリクエストが送信されても何も起こりません。リクエストはターゲットサイトによって単に破棄されます。サイトまたはアプリケーションでCSRFの欠陥が見つかった場合、ログインしたユーザーのブラウザーからのこれらの同じ要求が、一連の状態変更要求を実行する可能性があります。

WebアプリケーションをCSRFの欠陥から保護することで、アプリケーションまたはターゲットサイトは、そのような不当な要求と正当な要求とを区別できます。この保護は、ユーザーエクスペリエンスを損なうことなく実現できます。

多くの場合、CSRF攻撃は、不要な電子メールや疑わしいWebサイトから発生するため、フィッシングリンクをクリックしないようにユーザーに教えることで保護に寄与します。ただし、このタイプの攻撃に対する最も強力な保護形式は、送信する前に情報を確認するためにユーザーが以前にセッションで要求した形式から要求が送信されるようにすることです。

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

攻撃を実行する前に、攻撃者は通常、偽造されたリクエストを可能な限り正当に見せるためにアプリケーションを調査します。

たとえば、10,000円の銀行振込に対する一般的なGETリクエストは次のようになります。

　　GET http://testbank.com/transfer.do?acct=PersonA&amount=10000 HTTP / 1.1

攻撃者はそれが自分のアカウントへ10,000円移転につながるように、このスクリプトを変更することができます。

悪意のあるリクエストは次のようになります。

　　GET http://testbank.com/transfer.do?acct=AttackerA&amount=10000 HTTP / 1.1

悪意のある攻撃者は、リクエストを正当に見せかけハイパーリンクに埋め込むことができます。

　　<ahref ="GET http://testbank.com/transfer.do?acct=AttackerA&amount=10000">続きを読む </a>

次に、攻撃者は電子メールを介して多数の銀行の顧客にハイパーリンクを配布できます。銀行口座にログインしているときにリンクをクリックすると、意図せずに10,000円の送金が開始されます。

クロスサイトリクエストフォージェリ（CSRF）の発見と修正

CSRFの脆弱性を確認するには、ユーザーがリクエストを送信できるフォームを探し、反CSRFトークンが適切に生成されているかどうかを確認します。最新のWebフレームワークのほとんどは、すべてのフォームページにアンチCSRFトークンを含め、検証を透過的に処理するようにグローバルに構成できます。ユーザーが送金、購入、管理ユーザーの追加、パスワードの変更などの状態変更リクエストを送信できる場合は常に、このリクエストをCSRFトークンで保護する必要があります。フォームがユーザーにこのタイプの変更を許可していない場合は、攻撃者による利用を防ぐために、そのスコープを制限する必要があります。

CSRFトークンは、セッションCookieがSameSite cookie属性で設定されていることを確認するなど、他のタイプの保護コーディングと組み合わせることもできます。この属性を使用すると、開発者は、サードパーティのドメインからのリクエストとともにCookieを送信するかどうかを管理するようにブラウザに指示できます。たとえば、オンラインバンキングサイトでは、最も厳しいレベルのCookie保護を使用する場合があります。HttpOnly属性を追加して、クロスサイトスクリプティングの欠陥のいくつかの形式から保護することもできます。また、クロスサイトスクリプティングの脆弱性により、一部の種類のCSRF攻撃が可能になるため、CSRF攻撃の実行がより困難になります。

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

CSRFトークンを使用することで、ほとんどのCSRF攻撃を簡単に防ぐことができます。これらの一意のトークンは、各機密リクエストに追加できます。資金の送金からWebサイトのバックエンドでの管理者アカウントの作成まで、すべての状態変更リクエストにチャレンジトークンを追加し、リクエストを処理するときにそのトークンを適切にチェックすることで、開発者はこれらのリクエストが認証されたユーザーによって合法的に送信されていることを確認できます。

サーバーが機密性の高いアクションを含むページをレンダリングするたびに、一意のCSRFトークンがユーザーに渡されます。このシステムが正しく機能するためには、サーバーは、トークンが完全に検証されたときにのみ、要求された機密アクションを実行する必要があり、トークンが無効または欠落しているすべての要求を拒否します。CSRFの欠陥チェックを実装する際の一般的なエラーの1つは、無効なトークンを含むリクエストを拒否し、トークンが欠落しているリクエストの続行を許可して、トークンプロセスを無効にすることです。

まとめ

クロスサイトリクエストフォージェリ（CSRF）の意味とその対策などについてご説明しました。

CSRF攻撃は、現在サイトに対して認証されているユーザーに対してのみ機能しますが、これらのエクスプロイトは、成功すると壊滅的な影響を与える可能性があります。

ユーザーになりすました攻撃者は、知らないうちに同意なしにさまざまなアクションを実行し、金銭を盗んだり、詐欺を働いたりする可能性があります。その結果、企業の評判が著しく損なわれ、顧客の信頼が失われ、場合によっては規制上の罰金が科せられることもあります。

包括的なセキュリティプログラムを積極的に実装することで、攻撃の可能性を減らすことができます。 また、CSRF攻撃に関連する脆弱性など、Webアプリケーションに潜む脆弱性を継続的に診断及び改善しシステムの安全性を維持することを推奨します。
　サービス紹介：セキュリティ脆弱性診断サービス