Arjun은 URL 엔드포인트에 숨겨진 HTTP 쿼리 파라미터를 사전(dictionary) 기반 탐색으로 찾아내는 도구다. 기본 사전에는 25,890개 파라미터 이름이 들어 있고, 이 전체를 10초 이내에 훑으면서 대상 서버에는 50~60회 수준의 요청만 발생시킨다. 웹 서비스 개발 문서에 남아 있지 않은 파라미터를 보안 실무자가 구조적으로 탐색하고, 그 후보 결과를 후속 분석 파이프라인에 연결할 때 Arjun이 제공하는 정보가 어디까지인지 정리한다.
Arjun이란: HTTP 파라미터 발견 도구의 위치와 최신 버전
Arjun은 특정 URL 엔드포인트에서 응답에 변화를 일으키는 숨겨진 HTTP 쿼리 파라미터를 사전 기반으로 탐색하는 도구다. Python으로 작성됐고, 현재 최신 릴리스는 2.2.7(2024-11-03)이며 AGPL-3.0 라이선스 아래 배포된다. Kali Linux 공식 도구 목록에도 등재돼 있고, Security Desk의 실무 가이드에서는 PyPI(arjun)와 meetcyber.net의 “Finding Hidden Parameters with Arjun”을 참고자료로 인용하고 있다.
실무 관점에서 Arjun이 생성하는 출력은 “탐색된 파라미터 후보 목록”이지 취약점 판정이 아니다. Arjun이 ?param1을 유효하다고 보고해도, 그 파라미터가 SQLi나 IDOR에 노출되는지는 별도 검증 단계를 거쳐야 한다. 이 경계를 명확히 하지 않으면 후속 분석에서 불필요한 리소스가 소진되거나, 반대로 실제 위협을 놓칠 수 있다.
기본 사전 25,890개의 구성: CommonCrawl·SecLists·param-miner 병합
Arjun이 “숨은” 파라미터를 찾을 수 있는 전제 조건은 사전에 해당 파라미터 이름이 존재한다는 것이다. 기본 사전의 규모는 25,890개 파라미터 이름이며, 이 목록은 다음 세 가지 출처를 병합해 구성된다.
- CommonCrawl 데이터셋에서 상위 파라미터 이름을 추출
- SecLists 워드리스트 중 우수 단어를 병합
- param-miner 워드리스트 중 우수 단어를 병합
이렇게 구성된 사전은 특정 프레임워크나 개발 패턴에 국한된 목록이 아니라, 실제 웹 트래픽에서 관측된 파라미터 명칭의 통계적 집합에 보안 커뮤니티의 노하우를 합친 형태다. 다만 해당 근거 자료에는 Arjun 사전에 없는 파라미터 명칭을 포괄하는 대안 수단이나 커스텀 사전 구성 방법이 명시돼 있지 않다.
참고로 공식 위키 “How Arjun works?” 페이지(마지막 수정 2021-05-17)에는 “25,980”이라는 수치가 남아 있다. 현행 README와 Kali 공식 문서가 모두 25,890으로 일치하므로 이 글에서는 25,890을 기준으로 사용한다.
작동 원리 3단계: 기준 응답 확보 → 25개 분할 요청 → 이분 탐색 수렴
Arjun이 25,890개 이름을 하나씩 요청하지 않고 50~60회로 압축하는 핵심은 분할-정복 알고리즘이다. 공식 위키에 따르면 절차는 다음 3단계로 이루어진다.
- 기준 응답 확보. 서로 다른 쿼리로 대상 엔드포인트에 사전 요청을 보내 기준(response baseline)을 확보한다.
- 25개 조각 분할 요청. 사전 전체를 25개 조각으로 나눈 뒤, 각 조각의 파라미터 이름을 랜덤 값과 함께 단일 요청에 담는다. 총 25회 요청을 발생시킨다. 각 응답을 기준과 비교해 반응 변화가 없던 조각은 즉시 기각한다.
- 이분 재귀 수렴. 반응 변화(편차)를 유발한 조각을 두 조각으로 반분하고 각각 재요청을 반복한다. 이 과정을 단일 파라미터로 수렴할 때까지 재귀적으로 수행한다.
이 구조 덕분에 25,890개 이름을 25,890회 요청하는 대신, 첫 단계 25회 + 수렴 단계의 소수 추가 요청으로 총 50~60회 수준에 그친다.
10초 이내 처리와 50~60회 요청의 조건과 의미
“10초 이내, 50~60회 요청”이라는 수치는 Arjun 개발자(GitHub 저장소)와 Kali 공식 문서가 동일한 표현으로 제시하는 대표 성능 지표다. 이 수치 자체는 검증됐지만 독립 벤치마크는 존재하지 않는다. 네트워크 조건과 대상 서버 상태에 따라 실제 소요 시간과 요청 횟수가 달라질 수 있다. 조건부 성격의 수치다.
| 항목 | 수치 | 출처 |
|---|---|---|
| 기본 사전 파라미터 수 | 25,890개 | GitHub README, Kali 도구 문서 |
| 기본 사전 전체 처리 시간 | 10초 이내 | GitHub README, Kali 도구 문서 |
| 대상 서버 요청 횟수 | 50~60회 | GitHub README, Kali 도구 문서 |
| 기본 청크 크기(요청당) | 500개 파라미터 | Arjun Wiki (Usage) |
| 기본 요청 타임아웃 | 15초 | Kali 패키지 도움말 |
실무적으로 이 수치는 “Arjun 실행 자체가 대상에 큰 부하를 주지 않는다”는 의미로 해석할 수 있지만, 대상이 로우레벨 WAF나 IDS를 운영하는 경우라면 50~60회 연속 요청이 이상행위로 분류될 가능성이 있는지 미리 확인해야 한다. Arjun은 대상의 속도 제한(rate limit)과 타임아웃을 자동으로 처리한다.
지원 메서드와 실무 옵션: GET/POST/JSON/XML, 청크 크기, 워드리스트 선택
Arjun은 GET/POST/POST-JSON/POST-XML 네 가지 HTTP 요청 방식을 지원한다. 기본적으로 GET 메서드 파라미터를 탐색하며, 필요하면 -m 플래그로 POST/JSON/XML 메서드로 전환한다.
기본 동작 옵션을 정리하면 다음과 같다.
- 청크 크기: 요청당 500개 파라미터를 묶어 전송
- 워드리스트:
small/medium/large3종을 기본 제공. 기본값은{arjundir}/db/large.txt - 스레드: 기본 스레드 수는 실행 환경의
arjun -h도움말을 기준으로 확인할 것 (위키와 Kali 도움말 간 기본값이 상이하여 단일 수치 단정을 피함) - 타임아웃: 기본 15초
탐색 결과는 Burp Suite 세션이나 JSON 파일로 내보낼 수 있어서, 매뉴얼 리뷰, 자동화 스캔, 티켓 등록 같은 후속 분석에 바로 연결해 쓸 수 있다.
사전 기반 탐색의 한계와 보완 전략: 패시브 수집과 커스텀 사전
사전 기반 탐색의 구조적 한계는 명백하다. 사전에 없는 파라미터 이름은 Arjun이 탐지하지 못한다. 특정 프로젝트가 자체적으로 정의한 ?session_token_v2 형태의 파라미터는 25,890개 목록에 없으면 원칙적으로 놓친다.
Arjun은 이 한계를 부분적으로 완화하려고 패시브 수집 채널을 제공한다. CommonCrawl, Open Threat Exchange(OTX), WaybackMachine 세 가지 외부 소스에서 도메인(서브도메인 아님) 단위로 파라미터 이름을 수집하고, JS 파일에서도 파라미터명을 패시브 추출한다. 이렇게 패시브로 수집한 후보를 --passive 옵션으로 주입하면 사전 탐색과 병행해 대상에서 존재 여부를 검증한다.
다만 해당 근거 자료 범위에서는 커스텀 사전 파일을 직접 작성·구성하는 절차가 명시돼 있지 않다. 실무에서 프로젝트 고유 파라미터명을 추가하려면 Arjun의 워드리스트 파일 형식을 확인해 직접 편집하거나, 패시브 소스에 해당 파라미터가 노출돼 있는지 미리 확인하는 경로가 현실적 선택지다. Arjun이 출력하는 모든 파라미터 후보는 “존재 가능성이 확인된 입력 표면”이지 “위험이 확인된 취약점”이 아니다. 팀 내 보고와 티켓 분류에서 이 구분을 일관되게 명시해 두면 좋다.