CSRF

現代のWeb環境において、セキュリティは単なる機能ではなく、基盤そのものです。アプリケーションの相互接続が進む中、異なるオリジンやサーバー間でのリクエストがどのように処理されるかのニュアンスを理解することは、あらゆる開発者にとって極めて重要です。 今日は、すべてのWeb開発者が習得すべき3つの重要な概念、SSRF、CSRF、そしてCORSについて深く掘り下げていきます。これらは一見複雑な略語に見えますが、Webアプリケーションセキュリティの最前線を象徴するものです。 1. SSRF (サーバー側リクエスト偽造) SSRFは、攻撃者がサーバー側のアプリケーションを操作して、攻撃者が指定した任意のドメインに対してHTTPリクエストを強制的に送信させる脆弱性です。 仕組み 入力としてURLを受け取り（例：プロフィール画像の取得やリンクのプレビューなど）、サーバーからそのURLに対してリクエストを行うWebアプリケーションを想像してください。アプリケーションがこのURLを適切に検証しない場合、攻撃者は内部IPアドレスやループバックアドレス（127.0.0.1）を指定する可能性があります。 サーバーがプロキシとして動作し、パブリックインターネットに公開されていない内部サービスから次のような機密データを取得してしまう恐れがあります： クラウドメタデータ： AWS/GCP上の 169.254.169.254 にアクセスしてIAM認証情報を取得する。 内部管理パネル： JenkinsやKubernetesダッシュボードなどの内部ツールへのアクセス。 ポートスキャン： 内部ネットワーク上で動作している他のサービスの探索。 防策 ホワイトリスト： 信頼できるドメインの定義済みリストへのリクエストのみを許可する。 入力の検証： URLが許可されたプロトコル（例：https:// のみ）を使用しており、内部IP範囲を指していないことを確認する。 ネットワークの分離： Webサーバーが内部リソースにアクセスできる範囲を制限する。 2. CSRF (クロスサイトリクエスト偽造) CSRFは、被害者が現在ログインしている別のWebサイト上で、被害者のブラウザを操作して意図しないアクションを実行させる攻撃です。 仕組み この攻撃は、ブラウザがドメインへのすべてのリクエストに対して、セッションCookieなどの認証情報を自動的に含めるという性質を悪用します。 ユーザーが bank.com にログインする。 ユーザーが別のタブで悪意のあるサイト evil.com にアクセスする。 evil.com には、bank.com/transfer?amount=1000&to=attacker に対して POST リクエストを送信する隠しフォームが含まれている。 ブラウザは、ユーザーの bank.com セッションCookieと共にリクエストを送信する。 bank.com は有効なセッションであると判断し、送金処理を実行する。 防策 アンチCSRFトークン： 状態を変更するすべてのリクエストに、一意で推測不可能な秘密のトークンを含める。サーバーは処理前にこのトークンを検証する。 SameSite Cookie： Cookieの SameSite 属性を Strict または Lax に設定し、クロスサイトリクエストで送信されないようにする。 カスタムヘッダー： AJAXリクエストの場合、標準のHTMLフォームでは設定できないカスタムヘッダー（例：X-Requested-With）を必須とする。 3. CORS (オリジン間リソース共有) SSRFやCSRFとは異なり、CORS自体は脆弱性ではなく、セキュリティメカニズムです。これはサーバーがブラウザに対して、「この特定の外部オリジンが私のリソースにアクセスすることを許可します」と伝えるための手段です。