Burp로 JWT 취약점 점검하기

소개

JWT(JSON Web Token)는 인증·인가에 널리 사용된다. 토큰이 클라이언트에 저장되면서 서버는 서명을 통해 무결성을 검증한다. 그러나 잘못된 구현은 토큰 위조, 알고리즘 혼동, 만료 회피 같은 취약점을 낳는다. 이 글은 Burp Suite 환경에서 JWT 취약점을 단계별로 점검하는 절차를 정리한다. 초보자도 이해하기 쉬운 설명과 실제 테스트 흐름을 제공한다.

준비물 및 전제

• Burp Suite (Community 또는 Pro)
• JWT 디코더 확장(또는 온라인 디코더)
• 테스트 대상 애플리케이션과 적절한 권한
• 리피터와 인트루더 사용 경험

JWT 구조 이해

세 부분 개념

JWT는 header.payload.signature 형태다. header와 payload는 base64url로 인코딩된다. 서명은 header와 payload의 무결성을 보장한다. 아래 예시는 토큰 구성 예시다.

Header: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
Payload: eyJ1c2VyIjoiYWRtaW4iLCJleHAiOjE2MjAwMDAwMDB9
Signature: SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
JWT: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VyIjoiYWRtaW4iLCJleHAiOjE2MjAwMDAwMDB9.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c

Burp로 토큰 위조 검사

1) none 알고리즘 취약성

서버가 "alg":"none"을 신뢰하면 서명이 없어도 토큰을 받아들인다. 검사 절차는 간단하다.

• 토큰을 디코딩해 header를 {"alg":"none","typ":"JWT"}로 변경
• 서명을 제거한 토큰을 생성해 Authorization 헤더에 적용
• Burp Repeater로 요청을 전송해 응답을 확인

변경된 Header (base64url 인코딩 후)
예시 토큰: <new_header>.<original_payload>.
HTTP 요청: Authorization: Bearer <forged_token>

2) alg 변경 및 키 혼동

RS256(비대칭)과 HS256(대칭)을 혼동하면 공격자가 공개키를 비밀키처럼 사용해 서명을 만들 수 있다. 시나리오:

• header의 alg를 RS256에서 HS256으로 변경
• 서버의 공개키(public key)를 알고 있다면 이를 HMAC 키로 사용해 서명 생성
• Burp로 요청을 전송해 권한 상승이나 관리자 접근을 확인

3) 페이로드 변조 및 재서명

payload에서 권한 관련 클레임(e.g. role, isAdmin)을 수정한 뒤 적절한 비밀키로 재서명한다. 비밀키를 모르는 경우 취약한 키 관리 또는 노출 지점을 찾아야 한다.

예시 변경 전 payload: eyJ1c2VyIjoiam9obiIsInJvbGUiOiJ1c2VyIn0
변경 후 payload: eyJ1c2VyIjoiam9obiIsInJvbGUiOiJhZG1pbiJ9
재서명 후 토큰을 요청에 사용

만료(exp) 테스트

만료 우회 확인

서버가 exp 클레임을 신뢰해야 한다. 일부 구현은 만료를 제대로 검사하지 않거나 시간을 클라이언트 신뢰로 처리한다. 점검 방법은 다음과 같다.

• payload의 exp 값을 과거로 설정해 요청 전송 — 거부 확인
• exp 값을 충분히 미래로 연장해 승인되는지 확인
• 서버가 토큰 발급 시 서버 시계와의 불일치(tolerance)를 과다 허용하는지 확인

payload 예시: eyJ1c2VyIjoiamFuZSIsImV4cCI6MTY5MDAwMDAwMH0
HTTP: Authorization: Bearer <modified_token>

Burp 설정과 절차

• Burp Repeater에 요청 보내기. Authorization 헤더를 편집하며 테스트
• JWT 디코더(확장)를 설치하면 Repeater에서 바로 디코드·인코드 가능
• 여러 토큰을 자동화하려면 Intruder로 페이로드 목록을 주입해 대량 테스트
• 로그와 응답 코드를 면밀히 비교해 권한 우회 성공 여부 판단

발견 시 권고 조치

• 항상 서명 알고리즘을 고정하고 허용 목록을 사용한다
• RS256 사용 시 공개키와 비밀키의 역할을 엄격히 분리한다
• exp, iat 같은 시간 관련 클레임을 서버 측에서 검증한다
• 비밀키는 안전하게 보관하고 주기적으로 교체한다
• 불필요한 클레임(예: isAdmin)을 신뢰하지 않고 서버 권한 테이블로 검증

결론

Burp로 JWT 취약점 점검은 구조 이해와 반복적인 요청 조작으로 충분히 수행할 수 있다. none 알고리즘, alg 혼동, exp 우회는 흔한 취약점이다. 점검 절차를 체계화하면 위험을 줄이고 안전한 토큰 검증을 구현할 수 있다. 문서의 절차는 테스트 환경에서만 적용하고, 실제 서비스에는 안전한 운영 정책을 적용한다.