はじめに

日本のフロントエンドエンジニアの皆さん、こんにちは。今回は、皆さんが開発されているAngularアプリケーション、特にServer-Side Rendering (SSR) を利用している場合に影響を受ける可能性のある、深刻なセキュリティ脆弱性について解説します。

AngularのSSR機能において、Server-Side Request Forgery (SSRF) の脆弱性 (GHSA-45q2-gjvg-7973 / CVE-2026-41423) が発見されました。これは、攻撃者に細工されたURLを渡されることで、アプリケーションが意図せず外部の悪意あるサイトに接続し、内部情報が漏洩する恐れがあるというものです。この脆弱性は「高 (high)」と評価されており、迅速な対応が求められます。

脆弱性の概要：なぜ危険なのか？

この脆弱性は、AngularのSSR機能を提供するパッケージである`@angular/platform-server`に存在します。具体的には、外部からのリクエストURLの処理に不備があり、特定の不正なURLが渡された場合に、サーバーがそのURLを誤って解釈してしまうことに起因します。

その結果、本来アクセスすべき自社サーバーのリソースではなく、攻撃者が指定した外部サーバーに対してHTTPリクエストを発行してしまう可能性があります。これがSSRF（Server-Side Request Forgery）と呼ばれる攻撃です。サーバーサイドで実行されるリクエストが乗っ取られるため、認証情報や内部APIエンドポイントといった機密情報が攻撃者の手に渡る危険性が非常に高いのです。

脆弱性のメカニズムを深掘り

では、具体的にどのようにして脆弱性が悪用されるのでしょうか？

攻撃者は、例えば`GET /\evil.com/ HTTP/1.1`のような、バックスラッシュ（`\`）を含む不正な形式のURLをサーバーに送信します。通常、URLにバックスラッシュは使用されませんが、AngularのURLパーサーはこの不正なバックスラッシュをフォワードスラッシュ（`/`）に正規化してしまいます。

この正規化の結果、アプリケーションは`evil.com`という攻撃者のドメインを、まるで自社のサーバー（ローカルオリジン）であるかのように誤って認識してしまいます。この誤認が、後の危険な挙動へと繋がります。

もたらされる具体的なリスク

アプリケーションが攻撃者のドメインをローカルオリジンだと誤認することで、深刻なリスクが発生します。具体的には、以下のケースが想定されます。

- **機密情報の漏洩**: アプリケーション内部で相対パスを使って実行される`HttpClient`からのAPIリクエストや、`PlatformLocation.hostname`で生成されるURLが、本来アクセスすべき自社サーバーではなく、攻撃者が管理する外部サーバーへ送信されてしまう可能性があります。

- **認証情報の窃取**: 内部APIへの認証トークンやセッション情報などが、意図せず攻撃者のサーバーに送信され、悪用される恐れがあります。

- **サーバーのメタデータ漏洩**: サーバーの環境情報や内部ネットワークに関する情報が攻撃者に収集される可能性があります。

あなたのプロジェクトは影響を受けますか？（影響範囲の確認）

この脆弱性の影響を受けるのは、以下の条件をすべて満たすAngular SSRアプリケーションです。一つでも該当する場合は、早急な対応を検討してください。

1. **サーバーが外部ネットワークにアクセス可能であること。**

2. **Angular SSRを以下のいずれかのAPI経由で使用していること:** * `renderModule` * `renderApplication` * `@angular/ssr`の`CommonEngine`

3. **サーバーサイドのコードが、リクエストURL（例: `req.url`）をAngularのレンダリングメソッドに直接渡していること。**

4. **サーバーサイドのコードが、相対URLを使って`HttpClient`でHTTPリクエストを行うか、`PlatformLocation.hostname`でURLを構築していること。**

なお、`@angular/ssr`の`AngularAppEngine`や`AngularNodeAppEngine`を使用している場合は、この脆弱性の影響を受けませんのでご安心ください。

直ちに対応すべき対策

この脆弱性への対応は必須です。以下のいずれかの方法で、速やかに対応を実施してください。

最も安全で永続的な解決策は、脆弱性が修正されたAngularのバージョンにアップデートすることです。以下のバージョンに更新してください。

- **22.0.0-next.8** 以降 (Next版)

- **21.2.9** 以降

- **20.3.19** 以降

- **19.2.21** 以降

直ちにバージョンアップが難しい場合は、AngularにURLが渡される前に、不正なURLをサニタイズ（無害化）するミドルウェアを導入することで、一時的に脆弱性を回避できます。

以下のミドルウェアは、URLの先頭に複数のスラッシュやバックスラッシュがある場合に、それらを単一のフォワードスラッシュに正規化します。

```javascript app.use((req, res, next) => { // URLをサニタイズし、単一のフォワードスラッシュで始まるように保証 if (req.url.startsWith('//') || req.url.startsWith('/\\') || req.url.startsWith('\\')) { req.url = '/' + req.url.replace(/^[ /\\]+/, ''); } next(); }); ```

このコードを、Angular SSRのレンダリング処理が実行される前に配置してください。例えば、Express.jsを使用している場合、`app.use()`の呼び出しでこのミドルウェアを追加します。

まとめ

Angular SSRのSSRF脆弱性は、機密情報漏洩に直結する可能性のある深刻な問題です。対象となるAngularアプリケーションを開発・運用されているエンジニアの皆様は、ご自身のプロジェクトが影響を受ける条件に該当するかを確認し、速やかにバージョンアップ、または回避策の導入を検討してください。

セキュリティ対策は、常に最新の情報をキャッチアップし、継続的に取り組むことが重要です。今後もこのような重要な情報があれば、共有していきます。