FirecrawlコミュニティがDNSリバインディングの欠陥を報告、Playwrightスクレイピングプロキシが内部ネットワークに接続する可能性

FirecrawlのGitHubコミュニティは10月20日、Playwrightスクレイピングサービスに関するセキュリティ問題を公開した。サーバーサイドリクエストフォージェリ（SSRF）を防ぐプロキシで、DNSの名前解決結果が2回の処理で異なると、検査を通過した外部URLからデプロイ環境の内部ネットワークに接続できる可能性がある。報告者は確認済みのmainブランチのコミットを示したが、影響を受けるバージョンの完全な一覧は提示していない。公開されている再現手順については、別途請求が必要と記されている。問題報告

問題は、アドレスの検査と使用の間に生じる時間差にある。報告によると、isInternalHost() は最初にホスト名を名前解決し、接続先が内部アドレスかどうかを判定する。検査を通過すると、下層の proxy-chain が同じホスト名で接続を確立し、再度名前解決を行う。攻撃者が対象ドメインのDNSを制御している場合、1回目にはパブリックIPアドレスを、2回目にはプライベートIPアドレスを返すことができる。報告者によると、別経路の safeFetch ではTCP接続時に実際のリモートアドレスを検証するため、同じ欠陥はない。技術説明

同日提出されたドラフトPR #5261は、カスタムの dnsLookup を使って、接続時に検査済みのDNS結果を再利用し、未承認のアドレスを再取得しないようにする提案だ。プロキシ層の回帰テストも追加されており、提案者はDNSリバインディングのケースや内部アドレスの拒否を含む6件のテストが通過したとしている。ただし、これは提案者による検証結果であり、正式にリリースされた修正とはみなせない。修正提案

ウェブスクレイピングをRAGやエージェントのワークフローに組み込むチームにとって、この問題が示すのは、ツールが受け付けるURLによって、サービスがアクセスできるネットワークリソースも決まるということだ。Firecrawlの公式セルフホストドキュメントでは、デフォルトのスタックにPlaywright処理が含まれることを確認できる。また、公開環境にデプロイする前に、認証、ネットワークアクセス制御、TLSを追加するよう求めている。これはデプロイ環境に関する情報であり、今回の欠陥について公式に確認したものではない。セルフホストドキュメント

今後は、メンテナーによるレビュー、正式な修正版、実際のエンジン構成を確認する必要がある。ドラフトには制限事項も明記されている。PROXY_SERVER を設定している場合、接続先の名前解決は上流プロキシが担うため、出口ポリシーも上流側で実施する必要がある。確認時点でPRはまだドラフトであり、提案者もホステッドサービスが当該エンジンを使用しているかを確認していない。そのため、この報告からFirecrawlのクラウド利用者全員が影響を受けると結論づけることはできない。修正の範囲と制限