노출 보호 보안 스캐닝을 위한 콘텐츠 블라인드 리버스 프록시
콘텐츠 블라인드 보안 스캐닝을 위한 로컬 리버스 프록시.
Go · 로컬 HTTPS · HTTP & WebSocket · Tor / SOCKS5
배경 / 작동 방식 / 빠른 시작 / 인증서 / Tor / CAPTCHA / 증거 자료 / 개발
보안 테스트는 행위에 대한 규율입니다. 애플리케이션이 무엇을 하는지 -- 입력을 어떻게 처리하고, 어떤 통제를 적용하며, 무엇을 반사하고, 어떻게 실패하는지 -- 가 중요합니다. 정체성은 그러한 분석과 무관해야 합니다.
AI 지원 보안 도구는 그렇게 작동하지 않습니다. 이들은 대상 -- 도메인, 브랜드, 조직 -- 을 보고 의견을 형성합니다. 잘 알려진 서비스에 대해서는 발견 사항을 완화합니다. 대상이 누구인지에 따라 탐사를 거부합니다. 특정 벤더와 연관된 경로를 테스트하지 않습니다. AI가 운영자의 권한에 속하는 결정을 내리고 있으며, 행위가 아닌 맥락에 기반해 결정하고 있습니다.
이것은 잘못된 축입니다. 운영자가 범위를 승인합니다. 도구는 행위를 평가합니다. 이는 서로 다른 책임이며 하나로 합쳐져서는 안 됩니다. 그러나 오늘날 모든 AI 지원 도구는 대상의 완전한 정체성을 모든 결정에 연결하고 있습니다 -- 무엇을 테스트할지, 얼마나 강하게 밀어붙일지, 보고할지 여부까지.
Blinder는 하나의 출발점입니다: 실용적인 도구이면서, 동시에 테스트가 맥락으로부터 분리되어야 한다는 입장이기도 합니다. 이 아이디어를 세상에 알리기 위한 초기 시도입니다. 이 접근 방식이 공감을 얻는다면, 더 나은 구현, 기여, 또는 이 선이 어디에 있어야 하는지에 대한 논의를 환영합니다.
정체성을 제거한다고 해서 콘텐츠를 제거하는 것은 아닙니다. 대부분의 순진한 접근 방식이 여기서 무너집니다. 취약점은 응답 콘텐츠의 변화로 관찰됩니다 -- 오류 메시지, 반사된 입력, 세션이 도달해서는 안 되는 데이터, 서버 측 평가를 드러내는 계산 결과. 프록시가 이 콘텐츠를 제거한다면, 테스터가 찾고 있는 증거를 숨기게 됩니다.
요구 사항은 외과적입니다: 행위 신호는 보존하면서 정체성을 제거하는 것. 아무에게도 속하지 않지만 원본과 정확히 동일하게 작동하는 페이지 -- 나쁘게 작동할 때조차도.
Blinder는 AI 스캐너(또는 브라우저)와 대상 사이에 위치하는 로컬 HTTPS 리버스 프록시입니다. 도메인, 브랜드, 조직 이름, 이메일, IP 주소 등 정체성을 재작성하면서 애플리케이션의 기능적 행위 -- 오류, 반사, 보안 통제, 상태 코드, 콘텐츠 구조 -- 를 보존합니다.
다운스트림 AI에게 대상은 https://127.0.0.1:8099에 있는 익명의 로컬 호스팅 애플리케이션입니다. 인식할 브랜드도 없고, 의견을 형성할 도메인도 없습니다. AI는 애플리케이션이 누구인지가 아니라 무엇을 하는지를 테스트합니다.
이것이 콘텐츠 블라인드 스캐닝입니다: 운영자가 대상이 누구인지 통제하고, AI는 그것이 무엇을 하는지에 집중합니다.
대체 콘텐츠는 정확성의 일부입니다: 표시용 중립적 채움말, 애플리케이션 데이터용 가역 값, 그리고 보존된 진단 및 통제 동작. 생성된 제거 알림은 페이지에 속하지 않습니다.
| 콘텐츠 정리 | 표시 텍스트는 중립적 산문 채움말로 대체되고, 대화형 요소(버튼, 레이블, 폼 컨트롤)와 진단 콘텐츠(오류 메시지, 스택 트레이스, 반사된 마크업)는 보존됩니다. 정체성 토큰, 도메인 참조, 쿠키 값이 HTTP 본문, 헤더, WebSocket 텍스트 전반에 걸쳐 재작성됩니다. --preserve-content는 정체성만 정리하고 원본 표시 텍스트를 유지합니다. |
| 리소스 무결성 | 원본 SRI를 참조별로 검증하고 재작성된 리소스에 대해 재계산하며, 대응하는 CSP 해시도 변환됩니다. 버전이 지정된 참조는 제공되는 바이트를 바인딩하며, 외부 리소스 무결성은 보존됩니다. |
| 응답 캐시 | 업스트림/다운스트림 캐시 검증기를 분리합니다. 304 재검증은 보안 정책 헤더를 병합합니다. Vary 인식 제거. |
| 세션 처리 | 값별 정리를 통한 가역 쿠키 이름. 결정적 별칭 호스트명, Host 헤더 라우팅, CORS 오리진 변환을 통한 --extra-origin 다중 오리진 라우팅. |
| CAPTCHA 릴레이 | 운영자 대면 챌린지 큐와 별도의 제공자 오리진. Tor 라우팅 리소스는 제공자 쿠키, CSP, CORS를 대상 및 운영자와 분리하여 유지합니다. |
| 프라이빗 라우팅 | 원격 호스트명 해석을 통한 Tor SOCKS5 경유 업스트림 HTTP 및 WebSocket. Tor 실패는 조용한 폴백 없이 하드 오류입니다. |
| 로컬 HTTPS | 90일 수명과 자동 갱신이 있는 로컬 CA; 세션 리프 인증서는 즉석에서 서명됩니다. CA를 한 번 신뢰하면 -- 오리진을 추가하거나 별칭을 변경해도 재신뢰가 필요하지 않습니다. 임시 모드 사용 가능. |
| 증거 자료 | 저널 기반 지속성을 갖춘 정리 전 HAR, 요청별 정리/유출 카운트가 있는 요청 매니페스트, 도메인 매핑 및 정리 보고서. 쌍별 응답 비교는 바이트 크기 충실도와 콘텐츠/상태 변경이 마스킹 후에도 유지되는지 확인합니다. 신호 보존 검사는 검증된 행위와 남은 결함을 기록합니다. |
구현 상태와 알려진 제한 사항은 지원되는 행위 및 전달 게이트를 참조하세요.
**Go 1.26+**로 빌드합니다. 바이너리는 외부 런타임 의존성이 없습니다.
git clone https://github.com/Splinters-io/blinder.git
cd blinder
make build
./blinder --preflight
OS별 인증서 안내를 따른 다음, 세션을 시작합니다:
capture_dir=$(mktemp -d)
./blinder --target https://your-authorized-target.example \
--identity YourOrganisation \
--har "$capture_dir/session.har" \
--output "$capture_dir/output"
브라우저나 스캐너를 **https://127.0.0.1:8099**로 지정하세요. --identity 플래그를 반복하여 여러 정체성 토큰을 추가할 수 있습니다. Ctrl-C로 중지하면 세션 증거가 저장됩니다.
--config (-c)를 사용하여 YAML 파일에서 기본값을 로드합니다. CLI 플래그가 파일을 재정의합니다.
# blinder.yaml
listen: "127.0.0.1:9443"
target: "https://example.com"
alias: "target-001.local"
identity:
- "ExampleCorp"
- "example.com"
output: "/tmp/blinder-output"
captcha_config: "captcha.yaml"
no_verify_tls: true
tor:
enabled: false
addr: "127.0.0.1:9050"
har:
path: "/tmp/session.har"
max_body: 10485760
./blinder -c blinder.yaml
# override the listen port from the file:
./blinder -c blinder.yaml --listen 127.0.0.1:7777
Blinder는 첫 실행 시 로컬 CA(Certificate Authority)를 생성하고 이를 사용하여 세션별 리프 인증서에 서명합니다. CA를 한 번 신뢰하면 -- 나중에 추가된 추가 오리진을 포함한 모든 현재 및 미래 엔드포인트가 -- 설정을 다시 실행하지 않고도 자동으로 신뢰됩니다.
| 플랫폼 | 설정 |
|---|---|
| macOS | 출력된 --trust-cert 명령을 실행하고, CA 지문을 검토한 후 사용자 Keychain 신뢰를 승인합니다. 일회성 설정. |
| Ubuntu / Linux | 출력된 curl --cacert 명령을 사용하거나 브라우저/스캐너의 신뢰 저장소에 CA 인증서를 설치합니다. |
선택한 CA 저장소에는 --cert-dir DIR을 사용합니다. CA는 자동 갱신과 함께 90일 동안 지속됩니다; --ephemeral-cert는 CA 없이 임시 자체 서명 리프를 생성합니다. Preflight 종료 코드 2는 플랫폼 신뢰 설정이 필요함을 의미합니다; 자체 CA 파일을 사용하는 클라이언트는 여전히 성공적으로 연결할 수 있습니다.
추가 오리진을 추가하거나, 별칭을 변경하거나, CAPTCHA 제공자를 재구성하면 동일한 CA로 서명된 새 리프 인증서가 생성됩니다 -- 재신뢰가 필요하지 않습니다. Preflight는 리슨 호스트, 기본 별칭, 구성된 추가 오리진 별칭, 그리고 CAPTCHA가 구성된 경우 운영자 및 구체적인 챌린지 호스트명에 대한 신뢰를 보고합니다. --tor 사용 시 preflight는 구성된 제공자 별칭도 포함합니다.
CA 저장소는 또한 인증서 갱신과 독립적인 리소스 참조 소유권을 위한 개인 version-signing.key를 보관합니다. 만료된 참조가 계속 인식되도록 재시작 간에 이를 유지하세요. --ephemeral-cert는 TLS를 임시로 유지합니다; 리소스 참조 소유권은 여전히 기본 저장소에 지속됩니다.
Tor 서비스를 시작하고 부트스트랩을 기다린 다음, SOCKS 엔드포인트를 선택합니다:
./blinder --target http://your-service.onion \
--tor --tor-addr 127.0.0.1:9050 \
--identity YourOrganisation
클리어넷 대상도 동일한 경로를 사용할 수 있습니다. 대상 TLS 검증은 계속 활성화됩니다. Tor 실패는 대상에 대한 직접 연결로 폴백하지 않고 오류를 반환합니다.
대상이 CAPTCHA 챌린지를 반환하면 Blinder는 이를 운영자를 위해 큐에 넣습니다. --captcha-config를 통해 제공자를 구성합니다:
version: 1
captcha:
providers:
- hcaptcha
시작 시 출력되는 브라우저 로그인 URL을 엽니다: https://blinder-operator.localhost:<port>/__blinder/captcha/login?token=…. 이 별도의 로컬 전용 오리진이 운영자 세션을 보관합니다. 원시 챌린지 콘텐츠는 만료되는 뷰 기능을 통해 자체 <challenge-id>.blinder-challenge.localhost 오리진에서 실행됩니다; 운영자 쿠키는 운영자 오리진에 남습니다. API 클라이언트를 위한 Bearer 인증도 계속 사용할 수 있습니다. 인증서 계획에는 챌린지 와일드카드가 포함됩니다; 운영자, 챌린지, 제공자 호스트명에 대한 선택한 브라우저의 신뢰를 확인하세요. 운영자 및 인증서 가이드를 참조하세요.
--tor 사용 시, 구성된 각 route-with-target 제공자 오리진은 자체 https://captcha-<hash>.localhost:<port> 주소를 가지며 대상의 SOCKS 전송을 사용합니다. 정적 HTML 참조, 기본 URL, 새로고침 탐색이 이 경로를 사용합니다. 바운드된 헬퍼는 CSP가 없는 제공자 문서에서 동적 fetch, XHR, URL setter도 라우팅합니다; 제공자 스크립트 바이트와 무결성 메타데이터는 변경하지 않습니다. 강제 또는 보고 전용 정책이 있는 문서는 헬퍼를 받지 않습니다. 제공자 오류와 실제 CORS 결정은 계속 표시되며, 쿠키는 브라우저 통제 하에 남습니다. 이전 /__blinder/captcha/res 엔드포인트는 대상 및 운영자 오리진에서 404를 반환합니다.
내장 프로필은 hCaptcha, reCAPTCHA, Turnstile을 지원합니다. 사용자 정의 제공자는 명시적 resource_origins, 선택적 resource_url_regex, opaque_fields, submissions를 사용합니다; 릴레이되는 모든 요청은 해당 범위에 대해 검사됩니다. 직접 모드는 제공자 참조를 그대로 두며, tor_policy: direct는 명시적 Tor 예외로 남습니다.
Chrome은 합성 운영자 흐름을 완료했습니다: 13개의 제공자 요청 모두 릴레이를 사용했고, 원본 POST는 정확한 솔루션 토큰, 세션, 갱신된 CSRF와 함께 재개되었습니다. 별도의 교차 사이트 Lax 쿠키 사례는 직접 제공자의 HTTP 400 거부를 보존했습니다. 이는 바운드된 로컬 승인입니다: CSP 제한 챌린지, 기타 동적 로딩 API, 실제 별칭 신뢰, 실제 제공자 사람 완료, 라이브 Tor/onion 승인은 여전히 미해결입니다. 반복 가능한 브라우저 검사는 이러한 게이트를 별도로 기록합니다.
hcaptcha와 reCAPTCHA는 localhost와 127.0.0.1을 호스트명으로 거부합니다. 이러한 제공자로 로컬에서 테스트하려면 hosts 항목을 추가하고 해당 호스트명을 --target으로 사용하세요: