Webセキュリティの基礎：SSRF、CSRF、CORSの解説

現代の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などの認証情報を自動的に含めるという性質を悪用します。

1. ユーザーが bank.com にログインする。
2. ユーザーが別のタブで悪意のあるサイト evil.com にアクセスする。
3. evil.com には、bank.com/transfer?amount=1000&to=attacker に対して POST リクエストを送信する隠しフォームが含まれている。
4. ブラウザは、ユーザーの bank.com セッションCookieと共にリクエストを送信する。
5. bank.com は有効なセッションであると判断し、送金処理を実行する。

防策

• アンチCSRFトークン： 状態を変更するすべてのリクエストに、一意で推測不可能な秘密のトークンを含める。サーバーは処理前にこのトークンを検証する。
• SameSite Cookie： Cookieの SameSite 属性を Strict または Lax に設定し、クロスサイトリクエストで送信されないようにする。
• カスタムヘッダー： AJAXリクエストの場合、標準のHTMLフォームでは設定できないカスタムヘッダー（例：X-Requested-With）を必須とする。

3. CORS (オリジン間リソース共有)

SSRFやCSRFとは異なり、CORS自体は脆弱性ではなく、セキュリティメカニズムです。これはサーバーがブラウザに対して、「この特定の外部オリジンが私のリソースにアクセスすることを許可します」と伝えるための手段です。

なぜ存在するのか

デフォルトでは、ブラウザは 同一オリジンポリシー (SOP) を適用しており、あるサイトのスクリプトが別のサイトのデータを読み取ることを禁止しています。これにより、evil.com が gmail.com 上のあなたのメールを読み取ることを防いでいます。

CORSは、サーバーがこのポリシーを安全に緩和することを可能にします。Webアプリがクロスオリジンリクエストを行う際、ブラウザは Origin ヘッダーを送信します。サーバーは Access-Control-Allow-Origin で応答します。

よくある誤設定

• ワイルドカードオリジン (*)： すべてのオリジンを許可する。公開APIには適していますが、Access-Control-Allow-Credentials: true と組み合わせると非常に危険です。
• オリジンの反映： 検証なしに Origin ヘッダーに基づいて許可されたオリジンを動的に設定する。これは事実上、SOPを完全にバイパスすることになります。

ベストプラクティス

• 具体的に指定する： アクセスが必要な特定のドメインのみを許可する。
• 可能な限り認証情報を避ける： APIがCookieやAuthorizationヘッダーを必要としない場合は、許可しない。
• セキュリティミドルウェアを使用する： ヘッダーを手動で管理するのではなく、十分にテストされたライブラリを使用してCORS設定を処理する。

比較まとめ

これらWebセキュリティの3つの柱を理解することは、堅牢で現代的なアプリケーションを構築するために不可欠です。多層防御戦略を導入することで、サーバーの内部インフラとユーザーのプライベートデータの両方を保護することができます。

安全を保ち、ハッピーコーディング！