ParamTrace 배너

ParamTrace

버그 바운티와 승인된 침투 테스트를 위한 빠른 HTTP 파라미터 탐색 도구입니다. ParamTrace는 워드리스트 항목을 파라미터로 전송하고, 기준선(baseline)과 비교하여 응답을 변화시키는 항목을 표시합니다.

법적 고지: ParamTrace는 본인이 소유하거나 테스트에 대한 명시적 서면 허가를 받은 시스템(예: 범위 내 버그 바운티 대상)에서만 사용하십시오. 사용 방식에 대한 책임은 사용자 본인에게 있습니다.

ParamTrace를 선택하는 이유

파라미터 탐색 도구는 이미 존재합니다(Arjun, x8, Burp용 Param Miner). ParamTrace는 작고 집중된 대안입니다:

단일 바이너리, 런타임 불필요. Rust로 작성되어 Python 환경이나 Burp가 필요 없습니다. Termux(Android)에서도 빌드 및 실행됩니다.
노이즈 인식 기준선. 먼저 3개의 무작위 파라미터 요청을 보내 정상 상태 코드와 크기 범위를 학습하며, --tolerance는 매 요청마다 변하는 페이지를 처리합니다.
리플렉션 탐지. 상태와 크기가 거의 변하지 않더라도 응답에 값이 나타나는 파라미터를 표시합니다.
워크플로에 적합. 사용자 정의 헤더, GET 및 POST, 프록시 지원(Caido 또는 Burp), 다른 도구로 파이프할 수 있는 JSON 출력을 제공합니다.
작고 읽기 쉬움. 전체 도구가 하나의 소스 파일이므로 감사와 확장이 쉽습니다.

다른 도구를 사용해야 할 때: 이미 Burp 환경에 익숙하다면 Param Miner가 더 적합합니다. 요청당 많은 파라미터를 배치 처리하려면 Arjun이나 x8 같은 성숙한 도구가 현재 더 빠릅니다. 배치 처리는 ParamTrace 로드맵에 포함되어 있습니다.

작동 방식

무작위 가짜 파라미터로 3개의 요청을 보내 "정상" 응답 (상태 코드와 크기 범위)을 학습합니다.
제한된 동시성으로 각 워드리스트 항목을 테스트합니다.
상태가 변경되거나, 본문 크기가 기준선 범위를 벗어나거나, 값이 응답에 리플렉션될 때 해당 파라미터를 표시합니다.

설치

사전 빌드된 바이너리(Linux x86_64 및 aarch64, macOS Apple Silicon, Windows)는 Releases 페이지에서 제공되며, 각각 .sha256 체크섬 파일이 함께 있습니다. 예를 들어 Linux에서는(휴대폰의 Kali NetHunter의 경우 aarch64 파일 사용):

tar -xzf paramtrace-*-linux-x86_64.tar.gz
sudo cp paramtrace-*-linux-x86_64/paramtrace /usr/local/bin/

Termux는 Android의 C 라이브러리를 사용하므로 Linux 바이너리는 그곳에서 실행되지 않습니다. 대신 소스에서 설치하세요: cargo install --git https://github.com/CurioTrace/paramtrace

테스트 상태: Linux aarch64 바이너리(Kali NetHunter)와 Termux 소스 빌드는 작성자가 테스트했습니다. Linux x86_64, macOS 및 Windows 바이너리는 매 릴리스마다 자동으로 빌드되지만 작성자가 아직 실행해 보지 않았으므로, 작동하지 않는 경우 이슈를 열어 주세요. 바이너리는 서명되지 않았으므로 Windows 또는 macOS에서 처음 실행할 때 경고가 표시될 수 있습니다. 다운로드는 .sha256 파일로 검증할 수 있습니다.

또는 소스에서 빌드하세요:

git clone https://github.com/CurioTrace/paramtrace
cd paramtrace
cargo build --release
# binary: target/release/paramtrace

# optional: install it so you can just type `paramtrace`
cargo install --path .

Termux(Android)와 Kali NetHunter에서 테스트되었습니다. Rust가 빌드되는 곳이라면 어디서든 빌드되어야 합니다(rustls를 사용하므로 OpenSSL이 필요 없습니다).

사용법

ParamTrace 데모

아래 예제들은 paramtrace가 PATH에 있다고 가정합니다(위의 cargo install --path . 참조). cargo build --release만 실행했다면 대신 ./target/release/paramtrace를 사용하세요. 설치 후 명령을 찾을 수 없다면 Cargo의 bin 폴더를 PATH에 추가하세요: export PATH="$HOME/.cargo/bin:$PATH"

paramtrace -u https://example.com/search -w wordlists/common.txt
paramtrace -u https://example.com/api -w words.txt -m post -t 20
paramtrace -u https://example.com/ -w words.txt -H "Cookie: session=abc" --proxy http://127.0.0.1:8080
paramtrace -u https://example.com/ -w words.txt -o out.json -f json

플래그	설명
`-u, --url`	대상 URL
`-w, --wordlist`	파라미터 워드리스트
`-m, --method`	`get`(기본값) 또는 `post`
`-t, --threads`	동시 요청 수(기본값 10)
`-H, --header`	추가 헤더, 반복 가능
`--timeout`	요청 타임아웃(초, 기본값 10)
`--delay`	요청당 지연(ms)
`--tolerance`	최대 N바이트의 크기 차이 무시(동적 페이지에서 유용)
`--value`	각 파라미터에 전송할 값(4자 미만의 값은 반사 검사를 비활성화)
`--proxy`	프록시 URL(Caido, Burp)
`-k, --insecure`	TLS 검증 건너뛰기
`-q, --quiet`	시작 배너 숨기기
`-o, --output` / `-f, --format`	결과를 `text` 또는 `json`으로 저장

예시 결과

PortSwigger Web Security Academy 랩의 자체 인스턴스를 대상으로 테스트했습니다. 6,454개 항목의 워드리스트(6,453개의 잘못된 이름과 실제 파라미터 productId)를 사용했을 때, ParamTrace는 10개 스레드로 약 3분 만에 오탐 없이 productId만을 탐지했습니다. 서버는 파라미터가 있든 없든 400을 응답했기 때문에 상태 코드만 확인하는 검사로는 놓쳤을 것입니다. ParamTrace는 응답 크기를 비교하여 이를 잡아냈습니다.

속도는 네트워크에 크게 좌우되며, 파라미터 이름은 대소문자를 구분하므로 워드리스트에는 서버가 기대하는 정확한 이름이 포함되어야 합니다.

제한 사항

요청당 하나의 파라미터만 테스트합니다(배치 처리는 계획 중).
매 요청마다 크기가 변하는 페이지에서는 자동 허용 오차가 노이즈보다 작은 실제 변화를 숨길 수 있습니다(상태 변경, 더 큰 크기 변화, 반사는 여전히 탐지됨). 정확히 비교하려면 --tolerance 0을 사용하세요.
리다이렉트를 따르지 않으므로 리다이렉트 차이도 발견 사항으로 간주됩니다.

워드리스트

작은 시작 목록은 wordlists/common.txt에 있습니다. 더 큰 목록은 SecLists를 참고하세요.

실제 대상을 위해서는 더 큰 목록(약 6,000개 이름)을 다운로드하고 신중하게 스캔하세요:

curl -L -o wordlists/burp-params.txt https://raw.githubusercontent.com/danielmiessler/SecLists/master/Discovery/Web-Content/burp-parameter-names.txt
paramtrace -u https://example.com/page -w wordlists/burp-params.txt -t 5 --delay 100

매개변수 이름은 대소문자를 구분합니다. productId를 기대하는 서버는 productid에 반응하지 않으므로, ParamTrace는 대상이 사용하는 정확한 철자로 워드리스트에 있는 이름만 찾을 수 있습니다. 많은 목록이 전부 소문자이므로, 먼저 자신의 목록을 확인하세요. 예를 들어: grep -c -x productId yourlist.txt.

FAQ

속도 제한은 어떻게 처리하나요?

-t, --threads는 동시에 진행 중인 요청 수를 제한합니다(기본값 10).
--delay N은 각 요청 전에 N밀리초를 기다립니다. 이는 모든 동시 요청에 적용되므로, 스레드가 많을수록 전체적으로 초당 요청 수가 여전히 많아집니다.
--timeout은 느린 요청이 스캔을 멈추지 않도록 합니다.
대상이 429 Too Many Requests로 응답하면, ParamTrace는 해당 응답을 발견 사항으로 보고하지 않습니다. 결과가 불완전할 수 있으므로 이를 집계하고 마지막에 경고를 출력합니다. --threads를 낮추고, --delay를 추가하고, 요청 속도에 대한 대상의 규칙을 확인하세요.

아직 자동으로 백오프하거나 재시도하지 않습니다. 제 자체 랩 테스트 중 하나에서 -t 3 --delay 150은 초당 약 6회 요청으로, -t 10 --delay 0은 약 30회로 실행되었으므로, 속도는 대상과 연결 상태에 크게 좌우됩니다.

매개변수 배칭이 지원될 예정인가요?

네, 주요 계획 기능입니다: 한 요청에 많은 이름을 보내고 응답이 변경될 때 범위를 좁히는 방식으로, 훨씬 적은 요청이 필요할 것입니다. ParamTrace는 취미 프로젝트이므로 일정은 없습니다.

지원

ParamTrace가 평가나 버그 바운티에서 도움이 되었다면, 다른 사람들이 발견할 수 있도록 ⭐(저장소 페이지 상단의 Star 버튼)을 남겨 주시기 바랍니다.

버그 보고와 아이디어는 Issues에서 환영합니다.

라이선스

MIT

paramtrace

인기