はじめに：今回の脆弱性概要

今回解説するのは、メタ検索エンジン「SearXNG」のサーバーサイドで報告されたDoS（Denial of Service）脆弱性「GHSA-xcqx-9jf5-w339」です。この脆弱性は、SearXNGサーバーが外部URLからコンテンツを読み込む際のサイズ制限を迂回され、大量のメモリやCPUを消費させられることで、サービス停止に追い込まれる可能性があるというものです。

フロントエンドエンジニアの皆さんが直接コードを修正するものではありませんが、Webアプリケーション全体のセキュリティ、特にHTTP通信におけるサーバーサイドのデータ処理の堅牢性を考える上で、非常に示唆に富む内容です。HTTPヘッダーの取り扱い方や、ストリーミング処理の重要性など、今後の設計に活かせる知見が得られるでしょう。

脆弱性の詳細：なぜDoS攻撃が可能になったのか？

この脆弱性は、SearXNGが外部URLからコンテンツを読み込むために利用する「web_url_read」というツールに存在します。このツールは通常、読み込むコンテンツのサイズを5MiBに制限しており、過度なリソース消費を防ぐ設計になっていました。しかし、このサイズ制限の実装方法に問題がありました。

問題の核心は、ツールがコンテンツサイズをチェックするロジックにあります。まず、対象URLにHEADリクエストを送り、レスポンスヘッダーに含まれる「Content-Length」の値を確認します。この値が存在すれば、それが5MiBを超えているかどうかで制限をかけます。しかし、HTTPの仕様上、ウェブサーバーが「Content-Length」ヘッダーを返さないことは一般的であり、この場合、サイズチェックのロジックは「値がない＝null」と判断してしまいます。結果として、制限が機能しなくなり、ツールは本来の制限を超えてHTTPレスポンスボディ全体をメモリに読み込んでしまうのです。

さらに、読み込まれた大量のHTMLコンテンツは、その後にMarkdown形式への変換処理に渡されます。この変換処理は、メモリだけでなくCPUも過剰に消費するため、サーバーのリソースが瞬く間に枯渇し、サービス停止に陥る可能性がありました。

技術的な仕組み：HTTPヘッダーとリクエストボディ処理の注意点

この脆弱性は、HTTP通信における「Content-Length」ヘッダーの扱いの難しさと、大量データ処理のベストプラクティスを教えてくれます。

「Content-Length」ヘッダーは、HTTPレスポンスボディのバイト数を示すものですが、これが常に存在するとは限りません。特にTransfer-EncodingがChunkedの場合や、サーバーが事前にコンテンツサイズを特定できない場合など、意図的に省略されることがあります。この「ヘッダーがない＝サイズ不明」という状態を適切にハンドリングできなかったことが、今回の脆弱性の根本原因です。

サーバーサイドで`response.text()`のようにレスポンスボディ全体を一度にメモリに読み込む処理は、便利である反面、今回のような脆弱性につながる可能性があります。特に外部からの未知のデータソースを扱う場合は、メモリの枯渇を防ぐために、ストリーミングでデータを読み込み、リアルタイムでサイズや内容を監視する処理が不可欠です。

攻撃条件と影響：認証なしで実行可能な深刻な問題

この脆弱性は、SearXNGがデフォルトで有効にしている「web_url_read」ツールに存在します。特にHTTP通信モードの場合、外部の攻撃者が悪意のあるURLをSearXNGに処理させるだけで、認証なしに攻撃が可能です。攻撃者は「Content-Length」ヘッダーを意図的に送信しない、巨大なサイズのコンテンツを返すウェブサーバーを用意し、そのURLをSearXNGに読み込ませることで、容易にサーバーのメモリやCPUを枯渇させ、サービス停止（DoS攻撃）を引き起こすことができます。

さらに、AIエージェントを使用している環境では、プロンプトインジェクションを通じて攻撃者制御のURLをツールに呼び出させることも可能です。これにより、AIが間接的に攻撃の媒介となるリスクも指摘されており、様々なWebアプリケーションの連携におけるセキュリティリスクの複雑さを示しています。

推奨される対応策：ストリーミング処理による堅牢化

この脆弱性に対処するためには、既存の`response.text()`でレスポンスボディ全体を読み込む処理を改修し、より堅牢なメカニズムを導入する必要があります。具体的には、ストリーミングでデータを読み込みながらバイト数をリアルタイムで監視する新しい関数（例: `readResponseTextWithLimit`）を導入することが推奨されています。

この新しい関数は、設定された最大サイズを超えた時点でデータの読み込みを中止し、エラーを返すように設計されます。これにより、「Content-Length」ヘッダーの有無にかかわらず、コンテンツのサイズ制限を強制できるようになり、DoS攻撃のリスクを大幅に低減できます。

フロントエンドエンジニアへの示唆

今回の脆弱性は直接フロントエンドのコードに関わるものではありませんが、Webアプリケーション全体の堅牢性を高める上で、フロントエンドエンジニアも学ぶべき点が多々あります。

<ul><li><b>HTTP通信の深い理解:</b> HTTPヘッダー一つがセキュリティリスクに繋がりうることを認識し、API設計やデータ取得処理において、サーバーサイドと連携する際の考慮事項を広げましょう。</li><li><b>データ処理におけるリソース消費意識:</b> 大量のデータを取り扱う際には、クライアントサイドでもメモリやCPUの消費を意識し、効率的な処理やストリーミングでの部分処理を検討する癖をつけましょう。例えば、大きなJSONレスポンスを一度に`JSON.parse()`するのではなく、必要に応じて`Response.body.getReader()`を使ったストリーミング処理を検討するなどです。</li><li><b>外部リソースの取り扱い:</b> ユーザーが入力したURLや、外部のAPIから取得するデータは、常に潜在的なリスクをはらんでいます。フロントエンドでも、URLのバリデーションや、受け取ったデータのサイズ・形式チェックを適切に行うことが重要です。</li><li><b>全体的なセキュリティ意識:</b> 自分の担当領域だけでなく、Webアプリケーション全体のアーキテクチャやサーバーサイドの処理フローを理解することで、より安全なシステム設計に貢献できます。</li></ul>

セキュリティは、フロントエンド、バックエンド関係なく、開発者全員が意識すべき領域です。今回の事例から学びを得て、より堅牢なWebアプリケーション開発を目指しましょう。