@fastify/http-proxyに脆弱性、11.6.6で修正
Fastify用プロキシの@fastify/http-proxyの9.0.0〜11.6.5に、転送先パスの制限を外部から破られる脆弱性が公表されました。prefixとrewritePrefixで転送先を固定している構成なら、11.6.6以降へ更新してください。
急ぎ度: 早めに
CVSS v3は9.1で認証なしにネットワークから狙えますが、影響は特定の設定に限られ、修正版の11.6.6がすでに出ています。
関係があるか
Node.jsのFastifyで@fastify/http-proxyを使い、パラメーター付きのprefixとrewritePrefixで転送先パスを固定している組織が対象です。社内APIやマイクロサービスの前段にこのプラグインを置いている環境は、とくに確認が必要です。
| 製品 | 影響を受ける版 | 修正版 |
|---|---|---|
| @fastify/http-proxy | 9.0.0以上11.6.6未満（9.0.0〜11.6.5） | 11.6.6 |
確かめ方
- 1プロジェクトのルートで
npm ls @fastify/http-proxyを実行し、直接の依存だけでなく、ほかのパッケージ経由で入っている版も確認します。 - 2ソースコードでregisterしている箇所を探し、prefixに
/:tenant/のようなルートパラメーターを含み、同時にrewritePrefixを指定していれば、該当する構成です。 - 3prefixが固定の文字列だけなら、この脆弱性が成立する条件は満たしません。ただし版は更新しておくと安全です。
何が起きたか
@fastify/http-proxyに、プロキシが転送先として許したパスの範囲を、外部から抜けられる脆弱性が見つかりました。
このプラグインはFastifyアプリへのリクエストを、設定したprefixの下で上流サーバーへ中継します。prefixにルートパラメーターを使い、rewritePrefixで転送先を固定している場合、パラメーターの値はURLデコードされたあと、再エンコードされずにrewritePrefixへ埋め込まれていました。
そのため、パスの区切り文字とフラグメントやクエリの区切り文字を符号化した値を送られると、デコード後に本物の区切りとして働きます。上流のパスに余計な階層が加わり、rewritePrefixが付けるはずだった末尾の固定部分も切り落とされます。../ を使ったパストラバーサルとは別の経路なので、../ を弾くだけの対策では防げません。
結果として、想定したprefixの外にある上流のパスへ到達されます。上流の作りによっては、サーバーサイドリクエストフォージェリ（SSRF）や、上流サービスでの認可回避につながります。
攻撃の流れ
-
1
細工した要求
攻撃者がプロキシの公開URLに、区切り文字を符号化したパラメーター値を含むリクエストを送ります。
-
2
デコードされる
プラグインがパラメーターをURLデコードし、再エンコードせずにrewritePrefixへ埋め込みます。
-
3
パスが書き換わる
区切りとして働く文字が上流パスに余計な階層を作り、固定していた末尾の部分が消えます。
-
4
範囲外へ到達
リクエストが、想定したprefixの外にある上流の場所へ転送されます。
どう悪用されるか
認証は要りません。プロキシにHTTPで到達できるネットワーク上の攻撃者が、利用者の操作なしに1回のリクエストで試せます。成立するのは、パラメーター付きのprefixとrewritePrefixを組み合わせて、転送先を固定している構成の場合です。
CVSSの評価では、機密性と完全性への影響が高、可用性への影響はなしです。プロキシが守るつもりだったパスの制限が効かなくなり、上流が内部向けのAPIや管理用のパスを持っていれば、そこに外部から届きかねません。上流側が転送元を信用して認可を省いている構成ほど、被害は大きくなります。
今すぐやること
-
1
使用の有無と版を確認する
アプリごとに、@fastify/http-proxyが入っているか、版が9.0.0〜11.6.5に当たるかを調べます。lockfileにあるすべてのアプリが対象です。
npm ls @fastify/http-proxy -
2
該当する構成かを確認する
prefixにルートパラメーターを含み、rewritePrefixも指定している箇所を探します。該当するアプリから先に更新します。
grep -rn "rewritePrefix" src -
3
11.6.6以降へ更新して再デプロイする
package.jsonの指定を11.6.6以降にして、lockfileも更新します。回避策は案内されておらず、更新が唯一の対処です。更新後は本番へ反映するところまで確認します。
-
4
上流側のログを見直す
公開前から該当構成で動かしていたなら、上流のアクセスログで、想定したprefixの外のパスへ届いた要求がないかを調べます。上流が内部向けのパスを持つ場合は、とくに丁寧に見ます。
背景
@fastify/http-proxyは、Fastifyのアプリを簡易なリバースプロキシやAPIの窓口にするプラグインです。フロントエンド向けの中継役（BFF）や、複数の社内サービスの前段として使われます。prefixとrewritePrefixは、このクライアントはこの上流のこのパス以下だけに行かせる、という制限をアプリ側で作る設定にあたります。
今回の問題は、その制限の守り手が、上流の認可の代わりをしていることに関わります。プロキシの転送先制限が破れると、上流が転送元を信用して認可を省いている場合、制限の外の機能に外部から届きます。パスの文字列を組み立てる処理でデコードと再エンコードを取り違えると、管理者が意図した範囲が崩れる点が、この脆弱性の特徴です。
よくある質問
Q.9.xや10.xを使っていますが、11.6.6まで上げる必要がありますか。
Q.上流のサービスで認証をしていれば、影響はありませんか。
この記事は、取得元の公開情報をもとに、人が監修しながらAIを活用して執筆しています。執筆と監修は佐々木 航が担い、公開したあとも人が内容を確認しています。誤りに気づいたときは直し、記事の末尾に訂正の行を残します。対応を決める前に、下の原文と参照先も確認してください。
影響パッケージ
| 種類 | パッケージ | 影響を受ける版 | 修正版 |
|---|---|---|---|
| @fastify/http-proxy | @fastify/http-proxy |
9.0.0 以上 11.6.6 未満 |
11.6.6 |
原文の説明 取得元が公開している説明をそのまま載せています (多くは英語)。
@fastify/http-proxy is a Fastify plugin that proxies HTTP requests to an upstream server under a configured prefix. In versions 9.0.0 through 11.6.5, when an application uses parameterized prefix and rewritePrefix options to pin clients to a fixed upstream path, the plugin substitutes URL-decoded route parameters into rewritePrefix without re-encoding them. A parameter value that encodes a path separator together with a fragment or query delimiter therefore decodes into real separators and delimiters that inject extra upstream path segments and strip the mandatory suffix the rewritePrefix was meant to enforce, without using any dot-dot traversal. An unauthenticated remote attacker can use this to reach upstream locations outside the intended prefix, leading to path-restriction bypass and, depending on the upstream, server-side request forgery or authorization bypass in the proxied service. The issue is fixed in @fastify/http-proxy 11.6.6, and users should upgrade to 11.6.6 or later. There is no workaround other than upgrading.
出典: CVE.org (CVE Program・cvelistV5) NVD
参照URL
- web github.com
- web cna.openjsf.org