Node.jsのセキュリティ：脆弱性のトリアージにおけるNode.js Security Working Groupの教訓

以前のブログ記事では、HackerOneでNode.js Security Working Groupに報告されたFastify Node.jsフレームワークの脆弱性開示について紹介しました。報告されたのは、サーバーサイドJavaScriptのコードインジェクション脆弱性です。最終的に、この報告はFastify Node.jsウェブアプリケーションフレームワークにも、そのJSONスキーマ検証コンポーネントfast-json-stringifyにも、セキュリティ上の影響はないと結論づけられました。

なぜセキュリティレポートとして認定されなかったのでしょうか？

その答えを探るため、レポートの調査結果を簡単に振り返り、Node.js Security Working Groupのインシデント対応チームが直面した課題を見ていきましょう。

このレポートでは、攻撃者がリクエスト検証ロジックのスキーマとして使われるJSONファイルを改ざんすることで発生するコードインジェクション攻撃について詳述されており、概念実証（PoC）ではリバースシェルの起動によってセキュリティ上の問題が確認されました。

しかし、Fastifyのメンテナーが早い段階で指摘したように、これ自体はFastifyのセキュリティ問題ではありませんでした。この脆弱性は動的に発生するものでも、フレームワークのコード自体にあるセキュリティバグによるものでもありません。問題が発生するのは、信頼できないコードをJSON検証スキーマとして使用した場合に限られます。通常、こうしたスキーマは開発者自身が記述するものであり、ユーザー入力をソースとして使うものではありません。

この脆弱性レポートから、セキュリティインシデントへの対応を担うアナリストとして、Node.js Security Working Groupが直面するいくつかの課題が浮き彫りになります。

1. 報告が対象に該当し、セキュリティバグとみなされるかどうかのトリアージ

2. 脆弱性の原因となったコンポーネントのトリアージ

判断が難しいNode.jsのセキュリティ問題

レポートにざっと目を通すと、開示された問題は正当なセキュリティバグのように見えます。実際、概念実証が提示され、前述のコンポーネントを使った攻撃シナリオが再現することも確認されています。

とはいえ、攻撃経路や脆弱性の詳細だけでなく、脆弱とされるコンポーネントの想定された使い方も慎重に確認する必要があります。Fastifyの場合、実行時のコードインジェクション攻撃を防ぐため、リクエスト検証用に渡されるスキーマの動的なJSON解析を意図的に許可していません。

しかし、開発者が概念実証で示されたような悪意のあるコードを含むJSON解析スキーマを使うことは可能です。これは本当にセキュリティ脆弱性なのでしょうか？

ここから判断が難しくなります。Fastifyチームはプロジェクトのドキュメントで、JSONスキーマの設定値を信頼できるソースとして扱うべきことを明確に示しています。信頼できる入力を確保する責任は、このライブラリを使う開発者とチームに委ねられています。

Node.jsの脆弱性はどこにあるのか？

見落とされがちなもう一つの課題は、脆弱性の原因となるコンポーネントを特定することです。たとえばこのレポートでは、Node.jsのfastifyウェブフレームワークと、JSON解析ライブラリfast-json-stingifyの2つが問題の対象として挙げられました。この脆弱性について、どちらをトリアージし、脆弱なコンポーネントとして扱うべきでしょうか？

一方で、fastifyはJSONスキーマの解析を別のコンポーネントに任せているにすぎません。他方、fast-json-stringifyは、あらゆる入力に対する安全性を保証する設計意図を明示しておらず、この問題への対処をユーザーに委ねています。

以前受け取ったセキュリティレポートの事例を見ると、この課題がより分かりやすくなります。その事例では、ExcelスプレッドシートファイルをHTMLとして出力するアプリケーションでクロスサイトスクリプティング（XSS）の脆弱性が見つかりました。このアプリケーションは、スプレッドシートデータの解析にサードパーティ製コンポーネントを使用していました。XSS脆弱性の原因は、出力データをHTMLページ向けにサニタイズできていなかったアプリケーション自体にあります。サードパーティ製コンポーネントに脆弱性があるわけではありません。そのコンポーネントは、入力データがHTML出力のコンテキストで使われるのか、それとも通常のCSVファイルで使われるのかを事前に知ることができないためです。したがって、Excelスプレッドシート解析ライブラリの責任範囲において、この種の脆弱性は関係ありません。

まとめ

セキュリティ脆弱性のトリアージには、多くの背景知識と経験が必要です。悪用が可能となる状況を把握するうえで、セキュリティ研究者と脆弱なコンポーネントのメンテナーとの対話が欠かせません。

もう一つの課題は、共通脆弱性評価システム（CVSS）とも呼ばれる脆弱性スコアを適切に割り当てることです。Node.jsのセキュリティ脆弱性のトリアージに役立つ情報をお探しなら、以前の記事CVSSの課題と、適切に評価するためのヒントをご覧ください。