JSON 웹 서명 디코딩: 중요한 검증 취약점으로 가는 관문

초보자를 위해 JSON 웹 서명 디코딩 작업은 토큰 내부의 클레임을 확인하기 위한 간단한 Base64URL 디코딩 작업처럼 사소해 보입니다. 하지만 보안 엔지니어, 모의 침투 테스터, AI 보안 연구원에게 '디코딩'은 훨씬 더 복잡한 전장의 정찰 단계에 불과합니다.

개발자는 디코딩을 사용하여 인증 흐름을 디버깅하는 반면, 공격자는 서명 로직을 리버스 엔지니어링하는 데 사용합니다. 개발자와 공격자 사이의 격차는 디코딩 토큰과 확인 무결성은 현대 API 역사상 가장 위험한 인증 우회 취약점이 존재했던 곳입니다.

이 문서에서는 JWS의 구조를 해부하고, 영향력이 큰 CVE를 비롯한 중요한 검증 실패를 분석하며, AI 기반 보안이 어떻게 작동하는지 살펴봅니다. 펜리전트-는 이러한 암호화 메커니즘을 감사하는 방식을 바꾸고 있습니다.

JWS의 해부학: Base64 그 이상

익스플로잇을 분석하기 전에 먼저 RFC 7515. JWS(JSON 웹 서명)는 디지털 서명 또는 MAC(메시지 인증 코드)로 보호된 콘텐츠를 나타냅니다.

컴팩트한 JWS 문자열은 점으로 구분된 세 부분으로 구성됩니다(.):

Header.Payload.Signature

디코딩 로직

수행 시 JSON 웹 서명 디코딩를 사용하면 기본적으로 처음 두 세그먼트를 Base64URL 형식에서 JSON으로 다시 변환하는 것입니다.

다음은 민감한 토큰을 기록할 수 있는 웹 기반 도구보다 CLI를 선호하는 보안 연구자를 위한 Python 원시 구현입니다:

Python

`import sys import json import base64

def padding_fix(data): missing_padding = len(data) % 4 if missing_padding: data += '=' * (4 - missing_padding) return data

def decode_jws(token): try: header_b64, payload_b64, signature_b64 = token.split('.')

    header = json.loads(base64.urlsafe_b64decode(padding_fix(header_b64)))
    payload = json.loads(base64.urlsafe_b64decode(padding_fix(payload_b64)))
    
    헤더, 페이로드를 반환합니다.
를 반환합니다:
    print("[-] 잘못된 토큰 형식")
    sys.exit(1)

사용 컨텍스트

헤더, 페이로드 = decode_jws(sys.argv[1])

print(json.dumps(header, indent=2))`

디코딩 작업의 출력에는 일반적으로 검증 방법을 나타내는 메타데이터가 표시됩니다. should 가 발생합니다. 이 메타데이터는 공격자의 주요 표적입니다.

"디코딩-검증" 격차: 취약점이 존재하는 위치

핵심 문제는 많은 라이브러리와 사용자 정의 구현에서 디코딩 단계에서 확인 단계로 이동합니다. 애플리케이션은 헤더를 디코딩하여 alg 필드에 입력한 다음 해당 사용자 제어 입력을 사용하여 서명을 확인하는 방법을 결정합니다.

1. "없음" 알고리즘 바이패스

이것은 JWS 익스플로잇의 '헬로 월드'이지만 레거시 시스템에서 지속됩니다. 백엔드 구현이 alg 헤더를 디코딩하여 인증 로직을 결정하면 공격자는 토큰을 수정할 수 있습니다:

1. 디코딩 헤더를 입력합니다.
2. 변경 alg 에 없음 (또는 없음, 없음).
3. 서명을 제거합니다.

라이브러리가 다음을 지원하는 경우 없음 (디버깅용) 알고리즘을 화이트리스트에 추가하지 않으면 서명 확인이 완전히 건너뛰게 됩니다.

2. 알고리즘 혼동(키 혼동)

이는 보다 정교한 공격입니다. 서버가 대칭(HMAC) 및 비대칭(RSA/ECDSA) 서명을 모두 지원하지만 특정 키에 어떤 서명이 사용되고 있는지 검증하지 못할 때 발생합니다.

• 시나리오: 서버는 RS256 토큰(개인 키로 서명하고 공개 키로 확인됨)을 기대합니다.
• 공격: 공격자는 JSON 웹 서명 디코딩변경 사항 alg 에 HS256 (HMAC)를 사용하여 토큰에 서명하고 서버의 공개 키 를 HMAC의 비밀로 사용합니다.
• 결과: 공개 키는 클라이언트가 사용할 수 있거나 쉽게 액세스할 수 있는 경우가 많기 때문에 공격자는 서버가 자체 공개 키를 사용하여 검증하는 유효한 서명을 위조할 수 있습니다(HMAC 비밀로 취급).

사례 연구: CVE-2022-21449("사이킥 페이퍼")

알고리즘 혼동은 논리적인 결함이지만, 일부 취약점은 암호화 구현 자체에 깊이 존재합니다.

CVE-2022-21449 (CVSS 7.5)는 "심령지"라고 불리는 Java의 ECDSA 서명 구현에 영향을 미쳤습니다. 이는 단순히 "서명이 존재한다"는 것만으로는 충분하지 않은 이유를 보여주는 대표적인 예입니다.

메커니즘

ECDSA에서 검증에는 수학 방정식이 사용됩니다: $v = R'$(단순화). 취약점은 Java의 ECDSA 구현에서 시그니처 파트 $r$와 $s$가 모두 0를 반환하면 확인 로직이 잘못 반환됩니다. true 에 대한 any 페이로드.

공격자가 할 수 있습니다:

1. 디코딩 합법적인 JWS입니다.
2. 페이로드 수정(예, {"admin": true}).
3. $r=0$ 및 $s=0$인 서명을 구성합니다.
4. Java 기반 백엔드(Java 15, 16, 17 또는 18 실행)로 전송합니다.

서버는 서명이 유효한지 확인하여 완전한 인증 우회를 허용합니다. 이는 널리 사용되는 표준 라이브러리도 치명적인 장애로부터 자유로울 수 없음을 강조합니다.

AI 기반 JWS 감사: 성실한 접근 방식

JWS 토큰의 수동 분석은 개별 익스플로잇에 효과적이지만 최신 마이크로서비스 아키텍처는 수백 개의 서로 다른 키, 순환 정책 및 알고리즘 구성을 사용하는 경우가 많습니다. 인간 엔지니어가 수동으로 JSON 웹 서명 디코딩 를 사용하여 전체 공격 표면에서 헤더 삽입, 키 혼동, 라이브러리별 우회 등의 모든 퍼퓰레이션을 테스트합니다.

바로 이 지점에서 AI 기반의 자동화된 모의 침투 테스트가 필수적입니다.

펜리전트 는 고급 대규모 언어 모델(LLM)과 강화 학습을 활용하여 이러한 심층적인 테스트를 자동화합니다. 정적 정규식을 사용하여 알려진 불량 문자열을 찾는 기존 스캐너와 달리, Penligent의 엔진은 다음과 같이 작동합니다:

1. 컨텍스트 디코딩: 트래픽을 가로채고 JWS 토큰을 디코딩하며 컨텍스트를 이해합니다(예: "이 토큰은 로그인뿐만 아니라 결제 게이트웨이에 사용됩니다").
2. 적응형 페이로드 생성: 시도만 하는 것이 아닙니다. 알고리즘: 없음. 서버의 오류 응답을 분석하여 백엔드 라이브러리를 유추합니다. Java 환경을 감지하면 CVE-2022-21449의 변형을 시도할 수 있습니다. 다음이 발견되면 kid 매개 변수를 통해 SQL 주입 또는 키 ID를 통한 명령어 주입을 검사합니다.
3. 논리 흐름 분석: 펜리전트는 하나의 엔드포인트에서 토큰이 올바르게 확인되었는지 간단히 확인할 수 있습니다. 디코딩 일반적인 아키텍처 결함인 보조 마이크로서비스에서 검증 없이 신뢰할 수 있습니다.

지능형 JWS 분석을 통합함으로써 Penligent는 단순한 취약성 스캔을 넘어 다음과 같은 영역으로 나아갑니다. 자율적인 레드팀 구성를 통해 암호화 구현이 알려진 CVE와 제로데이 로직 결함 모두에 대해 견고하도록 보장합니다.

엔지니어를 위한 강화 가이드라인

JWS 공격으로부터 애플리케이션을 보호하려면 "암묵적 신뢰"에서 "명시적 검증"으로 전환해야 합니다.

1. 알고리즘 화이트리스트 적용

절대로 alg 헤더를 사용하여 디코딩된 토큰에서 인증 방법을 결정합니다. 인증자에 예상 알고리즘을 하드코딩합니다.

자바스크립트

// 보안 접근 방식(Node.js jose 라이브러리) const verified = await jose.jwtVerify(token, secretKey, { 알고리즘: ['RS256'], // 명시적으로 RS256만 화이트리스트 지정 });

2. 2. kid (키 ID) 엄격하게

설정에서 여러 개의 키(JWKS)를 사용하는 경우, 다음 사항을 확인하세요. kid 헤더가 화이트리스트의 키와 일치하는지 확인하세요. 헤더를 전달하지 마십시오. kid 값을 데이터베이스 쿼리 또는 파일 시스템 호출에 직접 전달합니다.

3. 최신 라이브러리 사용

직접 암호화 래퍼를 작성하지 마세요. 다음과 같이 이미 검증된 라이브러리를 사용하세요. jose (Node.js), PyJWT (파이썬) 또는 jjwt (Java). 그러나 이러한 라이브러리에 대한 보안 게시판을 구독하고 있는지 확인하세요.

4. 디코딩과 확인 분리(논리적으로)

이해 JSON 웹 서명 디코딩 는 다음을 위한 것입니다. 디스플레이 목적(UI, 로깅). 확인 는 다음을 위한 것입니다. 권한 부여. 검증 단계가 반환되기 전에 디코딩된 데이터를 비즈니스 로직에 사용하지 마십시오. true.

결론

다음과 같은 기능 JSON 웹 서명 디코딩 은 기본적인 기술이지만, 이는 표면적인 것일 뿐입니다. 보안 엔지니어에게 원시 JSON은 잠재적인 잘못된 구성의 지도입니다. 고전적인 "없음" 알고리즘부터 CVE-2022-21449와 같은 수학적 우회에 이르기까지, 웹의 무결성은 성공적인 디코딩뿐만 아니라 엄격한 검증에 의존합니다.

애플리케이션의 복잡성이 증가함에 따라 다음과 같은 AI 기반 도구를 활용하는 것이 중요합니다. 펜리전트 이러한 미묘한 암호화 결함의 탐지를 자동화하는 것은 강력한 기업 보안 태세를 위한 필수 요소가 되고 있습니다.

참조:

• RFC 7515 - JSON 웹 서명(JWS)
• NIST 특별 간행물 800-63B - 디지털 신원 가이드라인
• CVE-2022-21449 상세 정보 - NVD
• OWASP JSON 웹 토큰 치트 시트