JWT의 점 세 개와 서명
제공된 viewer 계정으로 Vector Deploy Gate를 블랙박스 점검하세요. 브라우저 개발자 도구나 로컬 프록시에서 이 서비스가 자신의 세션에 사용하는 접근 증표를 관찰할 수 있습니다. 계정의 정식 역할을 변경하지 않고 admin 전용 승인 화면에 도달할 수 있는지 확인하고, 실제 배포 작업은 실행하지 마세요.
의뢰 배경
벡터클라우드는 고객사 앱의 배포 승인을 Deploy Gate에서 처리합니다. 토큰 처리 모듈을 교체한 뒤 관리자 역할이 없는 릴리스 담당자가 admin 승인 화면을 열었다는 감사 기록이 발견됐습니다. 계정 역할 변경이나 서명 키 유출 흔적은 없으며, 배포 실행 직전에 정책 엔진이 요청을 차단했습니다. 신규 모듈 배포를 중단한 상태에서 권한 검증 우회 여부를 긴급 확인해야 합니다.
이번 목표
viewer 계정으로 admin 전용 배포 승인 화면에 접근할 수 있음을 재현하고 계정 역할·최종 응답 증거를 확보하세요.
- JWT의 header, payload, signature 각 부분의 역할을 설명한다.
- Base64URL 인코딩이 기밀성과 무결성을 제공하지 않음을 확인한다.
- 허용 algorithm 고정, 서명 검증, exp·aud·iss 검증을 방어 항목으로 연결한다.
학습 노트 · JWT payload는 숨겨진 정보가 아니며, 서버가 신뢰할 수 있는 이유는 올바른 서명을 검증했기 때문입니다.
JWT는 보통 점으로 구분된 header, payload, signature로 구성됩니다. 앞의 두 부분은 Base64URL JSON이므로 토큰을 가진 누구나 읽을 수 있고 새 값으로 다시 인코딩할 수도 있습니다.
서버는 자신이 허용한 algorithm과 키로 signature를 검증한 뒤에만 claim을 신뢰해야 합니다. 토큰 header가 선택한 임의 algorithm을 그대로 받아들이거나 none을 허용하면 공격자가 role 같은 claim을 바꿀 수 있습니다.
점검 대상 서비스의 업무 토큰과 사이트 로그인 토큰은 목적과 audience가 다릅니다. 다른 서비스의 토큰이나 서명 키를 가져오지 말고, 승인된 대상이 자신의 세션에 발급한 증표만 관찰해야 합니다.
| 부분 | 내용 | 보안 성질 |
|---|---|---|
| Header | alg, typ | 검증 방식을 설명하지만 스스로 신뢰할 수 없음 |
| Payload | sub, role, aud, exp | 읽고 수정할 수 있는 claim |
| Signature | header와 payload에 대한 검증값 | 키와 algorithm을 올바르게 검증할 때 무결성 제공 |
| 서버 정책 | 허용 alg, aud, iss, exp | 토큰의 사용 범위를 최종 결정 |
Header
{"alg":"none","typ":"JWT"}
Payload
{"sub":"release-viewer","role":"viewer","aud":"vector-deploy","scope":"deploy-approvals"}
서버는 header가 제안한 방식과 무관하게 허용 알고리즘·서명·claim을 모두 검증해야 합니다.막혔을 때만 열기
다음 단서가 필요할 때만 한 단계씩 확인하세요.
힌트 1 · 점으로 나누기
토큰을 점 기준으로 나누고 첫 번째와 두 번째 부분을 Base64URL 디코딩하세요.
힌트 2 · 신뢰되는 claim
배포 승인 화면이 어떤 role, audience, scope를 기대하는지 원본 증표와 정상 요청을 비교하세요. 권한과 무관한 대상·범위 값은 원래 세션과 일치해야 합니다.
힌트 3 · 무서명 토큰 형태
header의 alg를 none으로, payload role을 admin으로 바꾸고 두 부분을 Base64URL로 인코딩한 뒤 마지막 점까지 포함하세요.
선행 의뢰가 잠겨 있습니다
이전 단계를 완료하면 자동으로 의뢰 메일과 실습 환경이 열립니다.