JSON 웹 토큰(JWT)은 많은 조직에서 선호하는 인증 방법이 되었습니다. 구현하기 쉬워 API 및 웹 애플리케이션을 보호하는 데 널리 사용되고 있습니다. 하지만 JWT를 제대로 관리하지 않으면 보안 취약점이 발생하여 시스템이 위험에 처할 수 있습니다. 여러분도 직접 사용해 보셨을 것입니다.
하지만 이를 안전하게 구현하고 처리하셨나요?
Akamai의 블로그 게시물은 JWT와 관련된 몇 가지 일반적인 보안 취약점을 강조했습니다. 이는 부적절한 JWT 관리의 잠재적 위험에 대한 경각심을 일깨워주었습니다. 이 블로그 게시물에서는 이를 기반으로 종종 간과되는 또 다른 취약점인 만료되지 않는 JWT에 초점을 맞춰 설명하고자 합니다. 이 문제가 어떻게 발생하는지 관련 보안 취약점과 함께 살펴보겠습니다. 그런 다음 이러한 보안 취약성으로부터 자신을 보호하는 방법을 알 수 있도록 몇 가지 지침을 제공하겠습니다.
일반적인 JWT 취약점 개요
자세히 알아보기 전에 위에서 언급한 블로그 게시물에서 강조한 JWT 취약점을 간략히 살펴보겠습니다. 필자가 언급한 JWT에 대한 6가지 위협은 다음과 같습니다:
- 서버가 유효성 검사 없이 토큰을 사용하도록 허용합니다: 서버가 토큰의 무결성을 확인하지 않아 공격자가 토큰을 조작하고 악용하기 쉬워질 때 발생할 수 있습니다. 또한 공격자는 확인 알고리즘(알고리즘)을 없음으로 설정하여 서버가 토큰의 유효성을 전혀 확인하지 않도록 조작할 수도 있습니다.
- 여러 애플리케이션에 동일한 개인 키를 사용합니다: 이 방법은 키가 노출되면 여러 애플리케이션이 손상될 수 있습니다.
- 약한 서명 알고리즘 사용: 약한 서명 알고리즘은 더 쉽게 해독되어 무단 액세스로 이어질 수 있습니다.
- 짧거나 엔트로피가 낮은 개인 키 선택: 키가 너무 짧거나 무작위성이 부족한 키는 무차별 암호 대입 공격에 더 취약합니다.
- JWT의 페이로드에 민감한 데이터 보관: 토큰을 가로채면 페이로드에 저장된 민감한 정보가 노출될 수 있습니다.
- 키 혼동: 키를 잘못 관리하면 잘못된 유효성 검사로 이어져 무단 액세스가 허용될 수 있습니다.
이러한 취약점에 대한 자세한 내용은 블로그 게시물에서 확인하세요. 이제 또 다른 취약점인 만료되지 않는 JWT에 대해 살펴보겠습니다.
추가 취약점: 만료되지 않는 JWT
얼마 전에 접한 실제 사례를 기반으로 한 다음 JWT를 살펴보겠습니다:
API에 대한 사용자의 액세스를 인증하고 권한을 부여하는 데 사용되는 JWT입니다. 스푸핑을 방지하기 위해 보안 비밀로 서명되어 있습니다. 언뜻 보기에는 괜찮아 보입니다. 하지만 페이로드를 좀 더 자세히 살펴봅시다:
{ |
TTL 클레임을 볼 때 일반적으로 TTL이 의미하는 바가 바로 유효 기간이기 때문에 유효 기간을 떠올릴 수 있습니다. 따라서 이것은 아마도 JWT의 유효 기간과 관련이 있을 것입니다. 이것이 만료 시간일 것입니다.
여기서 간단한 계산을 해볼 수 있습니다. 86,400,000은 초를 의미할 수 있으며, 이 경우 발행자는 이 JWT를 1000일 동안 유효하게 만들려고 합니다. 또는 밀리초를 의미할 수도 있는데, 이 경우 발행자는 이 JWT를 1일 동안 유효하게 만들려고 합니다. 그것도 말이 될 수 있습니다.
하지만 여기 문제가 있습니다. JWT 사양에 따르면 만료 시간은 ttl이 아닌 exp로 지정되어 있습니다:
| "exp"(만료 시간) 클레임은 JWT 처리를 위해 허용되어서는 안 되는 만료 시간 또는 그 이후를 식별합니다. "exp" 클레임을 처리하려면 현재 날짜/시간이 "exp" 클레임에 나열된 만료 날짜/시간 이전이어야 합니다. 구현자는 시계 왜곡을 고려하여 일반적으로 몇 분 이하의 약간의 여유를 제공할 수 있습니다. 이 값은 반드시 NumericDate 값을 포함하는 숫자여야 합니다. 이 클레임의 사용은 선택 사항입니다. |
그런데 여기에는 몇 가지 문제가 있습니다.
첫째, 이 JWT 발급자는 ttl을 사용하여 만료를 지정하고 있지만 ttl은 표준 JWT 클레임이 아닙니다. JWT를 처리하도록 설계된 대부분의 라이브러리는 ttl을 토큰 만료와 관련된 명령으로 인식하지 않습니다. 이로 인해 호환성 문제가 발생하고 토큰이 만료되지 않은 것으로 취급될 가능성이 높습니다.
둘째, exp 클레임에는 발급 시간으로부터 밀리초(또는 초) 단위가 아닌 실제 만료 타임스탬프가 필요합니다. 이러한 혼동은 exp가 아닌 ttl을 사용하기 때문에 발생하는 것일 수 있습니다. 그럼에도 불구하고 발행자는 적절한 토큰 만료를 보장하기 위해 exp 클레임의 예상 형식을 이해해야 합니다.
JWT의 만료 시간을 설정하지 않거나 잘못 설정하면(예시에서와 같이) JWT가 만료되지 않은 것으로 처리됩니다. 이는 심각한 보안 결함을 초래합니다.
| 적절한 만료가 이루어지지 않으면 공격자가 JWT를 재사용하거나재사용하거나 의도된 수명을 초과하여 유출될 수 있습니다,무단 액세스의 위험이 높아집니다. |
JWT 보안 취약점 완화하기
잠재적인 보안 취약점에 대해 살펴봤으니 이제 다음 질문은 어떻게 해야 할까요? 다행히도 이 취약점을 완화하는 방법은 간단하고 간단합니다!
항상 경험치 청구를 사용하세요 . 생성하는 모든 토큰에 만료 시간을 설정하세요. 이때 예상값 형식의 표준 만료 클레임을 사용하여 JWT 사양을 준수하고 의도한 대로 만료되는지 확인하세요.
애플리케이션 및 라이브러리 업데이트. 애플리케이션과 사용하는 모든 라이브러리가 업데이트되어 최신 JWT 표준을 준수하는지 확인하세요. 정기적인 업데이트는 보안 취약점을 수정하고 호환성을 개선하는 데 도움이 됩니다.
여기까지입니다. 이 간단한 가이드라인을 따르면 만료되지 않는 JWT를 통한 무단 액세스의 위험을 크게 줄일 수 있습니다. 이렇게 하면 JWT 구현의 전반적인 보안이 향상됩니다.
결론
애플리케이션의 보안을 유지하려면 JWT 취약점을 이해하고 해결하는 것이 중요합니다. 이 글에서는 만료되지 않는 토큰의 위험성을 강조했습니다. 만료 클레임을 올바르게 사용하고 라이브러리를 최신 상태로 유지하면 이러한 위험을 효과적으로 완화할 수 있습니다.
더 많은 보안 솔루션과 모범 사례를 알아보려면 Linode 문서에서 제공되는 리소스를 살펴보세요. Linode는 애플리케이션에서 보안 취약점을 제거하는 데 도움이 되는 포괄적인 가이드를 제공합니다.
내용