JWT 취약점: alg=none 및 키 혼동

JWT는 암호학적으로 서명되지만 많은 라이브러리에 심각한 취약점이 있었습니다. 가장 많이 악용된 취약점은 alg=none 공격, RS256→HS256 혼동 공격, 약한 비밀키에 대한 무차별 대입입니다. 이 모든 취약점은 공격자가 제어하는 헤더 필드를 신뢰하는 데서 비롯됩니다.

JWT 사양에서는 보안되지 않은 토큰에 alg:"none"을 사용할 수 있습니다. 버그가 있는 라이브러리는 이를 허용하고 서명 검증을 완전히 건너뛰었습니다. 공격자는 페이로드(예: "role":"admin")를 수정하고, alg:"none"으로 설정하고, 서명을 제거하면 서버가 이를 허용합니다.

원본: eyJhbGciOiJIUzI1NiJ9.eyJzdWIiOiJ1c2VyIn0.SIG 공격: eyJhbGciOiJub25lIn0.eyJzdWIiOiJhZG1pbiJ9. (서명이 비어 있고 끝에 점이 있습니다.) 취약한 서버는 검증에 성공한 것으로 처리하고 관리자 접근 권한을 부여합니다.

운영 환경에서는 alg:"none"을 절대 허용하지 마십시오. 허용되는 알고리즘을 명시적으로 허용 목록에 추가하십시오: jwt.decode(token, key, algorithms=["HS256"]). 최신 라이브러리 대부분(PyJWT 2+, jsonwebtoken 9+)은 기본적으로 alg=none을 거부합니다.

서버가 RS256을 사용하고 클라이언트가 alg를 HS256으로 변경하면, 서버가 RSA 공개 키를 HMAC 비밀키로 사용해 검증할 수 있습니다. 공개 키는 말 그대로 공개되어 있으므로 공격자는 이를 사용해 임의의 페이로드에 서명하고 서버가 이를 검증하도록 만들 수 있습니다.

단계: 1) JWKS 엔드포인트에서 공개 키를 가져옵니다. 2) 악성 페이로드를 구성합니다. 3) 원시 공개 키 PEM 바이트를 HMAC 비밀키로 사용해 HMAC-SHA256으로 서명합니다. 4) 헤더에서 alg:"HS256"으로 설정합니다. 5) 서버의 HS256 경로가 검증에 성공합니다.

검증 호출에서 예상 알고리즘을 항상 명시적으로 지정하십시오. 토큰 헤더에서 알고리즘을 가져오지 마십시오. 호출자가 전환할 수 없도록 RS256과 HS256에 별도의 코드 경로를 사용하십시오.

약한 비밀키(엔트로피가 256비트 미만)를 사용하는 HS256은 오프라인에서 무차별 대입될 수 있습니다. hashcat과 같은 도구는 JWT 해독을 지원합니다: hashcat -a 0 -m 16500 token.txt wordlist.txt. 최소 32바이트의 암호학적으로 무작위인 비밀키를 사용하십시오.

kid(키 ID) 헤더는 사용할 키를 선택합니다. 서버가 삭제 또는 검증 없이 kid를 SQL 쿼리 매개변수나 파일 시스템 경로로 사용하면 다음과 같은 문제가 발생할 수 있습니다: kid="../../dev/null" → 빈 키를 사용한 HMAC → 위조된 토큰이 허용됩니다. kid는 항상 정제하십시오.

jwk 헤더에는 검증에 사용할 공개 키가 포함됩니다. 취약한 서버는 포함된 키를 직접 사용할 수 있으므로, 공격자가 자신의 키 쌍을 제공하고 개인 키로 토큰에 서명한 다음 공개 키를 포함할 수 있습니다. 등록된 키에 대해서만 검증하십시오.

일부 구현에서는 exp 클레임을 확인하지 않거나 서버 시간을 일관되지 않게 사용했습니다. exp, nbf, iat를 항상 명시적으로 검증하십시오. 이러한 항목을 기본적으로 확인하는 라이브러리를 사용하고 운영 환경에서는 클레임 검증을 절대 비활성화하지 마십시오.

RS256→HS256 키 혼동 공격에서 공격자는 무엇을 HMAC 비밀키로 사용합니까?

JWT 취약점은 alg 헤더를 신뢰하고, alg=none을 허용하며, 약한 비밀키를 사용하는 데서 발생합니다. 해결 방법은 검증기에서 알고리즘을 고정하고, 강력한 비밀키를 사용하며, kid를 정제하는 것입니다. 다음 주제: 안전한 JWT 구현 방법입니다.