Firecrawl、DNSリバインディング対策をマージ　Playwrightのプロキシ接続を検証済みIPアドレスに固定

Firecrawlは10月21日、PR #5261をメインブランチにマージし、Playwrightクローリングサービスのサーバーサイドリクエストフォージェリ（SSRF）対策の不備を修正した。ブラウザーでウェブページを取得し、プロキシやRAGに利用する環境では、この変更によりクローリングサービスが内部ネットワークへのアクセスに誘導されるリスクが変わる。マージ記録

問題は、検査時と接続時にドメイン名がそれぞれ解決されていた点にある。保護機構が接続先アドレスを確認した後、基盤となるプロキシが接続を確立する際に再度名前解決していたため、DNS応答が変わると接続先が内部ネットワークに向けられる可能性があった。新しい実装では、同じ名前解決で検査を通過したアドレスに接続を固定し、検証結果と実際の接続先とのずれを小さくする。修正には、プロキシ層でこの問題を再現するテストも追加された。修正内容

保護の範囲には、引き続き設定上の制約がある。PROXY_SERVERを設定すると、接続先ドメインの名前解決は上流プロキシが行うため、今回の変更ではその経路の接続先アドレスを固定できない。エグレスポリシーは引き続き上流側で管理する必要がある。また、ALLOW_LOCAL_WEBHOOKS=trueによって検査を無効にする動作も変更されていない。現時点で確認できるのはコードがマージされたことまでであり、すべてのリリースパッケージやクラウドサービスに更新が適用されたとは判断できない。設定上の制約

セルフホスト環境のチームは、実際に稼働しているイメージとソースのバージョンを特に確認する必要がある。Firecrawlの公式ドキュメントによると、セルフホスト環境ではアップグレード、セキュリティ、監視を運用者自身が担い、クローリングでは外部へのリクエストも発生する。また、クイックスタートの構成は信頼できるネットワーク向けであり、そのまま本番環境の構成として扱うことはできない。セルフホスト向けドキュメント

次に確認すべきなのは、ブラウザーのワーカープロセスが実際にどのプロキシを経由するのか、接続先ドメインをどの層が名前解決するのか、そして利用中のバージョンに修正が含まれているかだ。任意のURLを受け付けるAIデータパイプラインでは、アプリケーションによる検証とネットワークのエグレス制限を組み合わせる必要がある。OWASPのSSRF対策ガイドも、両者を防御層として挙げている。OWASPガイド