안녕하세요, 여행자 K입니다.
지난번 API01:2023 Broken Object Level Authorization(BOLA)에 이어, 이번에는 OWASP API Security Top 10 2023의 두 번째 항목, 'API02:2023 Broken Authentication(부적절한 인증)'에 대해 자세히 알아보겠습니다. 이는 시스템의 출입 통제와 사용자 신원 확인 절차가 얼마나 중요한지 보여주는 취약점입니다.
API02:2023 Broken Authentication(부적절한 인증)이란?
API2:2023 Broken Authentication은 시스템에 접근하는 사용자의 신원 확인 절차(인증)나 시스템 자체의 보안 잠금장치에 결함이 있을 때 발생하는 취약점을 의미합니다. API는 외부와 직접 연결되는 인터페이스이므로, 인증 메커니즘 자체가 공격자에게 주요한 표적이 될 수 있습니다.
계정 탈취와 같은 심각한 보안 사고로 이어질 수 있는 이 취약점은 단순히 로그인 기능뿐만 아니라 토큰 관리, 세션 처리 등 인증과 관련된 전반적인 과정에서 발생할 수 있습니다. OWASP는 이 취약점에 대해 "인증 경계에 대한 잘못된 이해와 구현의 복잡성으로 인해 이 문제가 빈번하게 발생한다"고 설명합니다.
API 인증 관련 취약 상태
그렇다면, 어떤 경우에 API가 '부적절한 인증' 상태에 놓이게 되는지 몇 가지 구체적인 상황을 통해 알아보겠습니다.
1. 비밀번호가 쉽게 유추되거나 무력화될 수 있는 경우
- 반복적인 비밀번호 시도 방치: 공격자가 수많은 비밀번호를 계속해서 시도하는데도 계정 잠금, 재인증 요구, CAPTCHA와 같은 어떠한 제지(무차별 대입 방어)도 없는 경우
- 취약한 비밀번호 허용: "1234"나 "password"처럼 누구나 쉽게 짐작할 수 있는 약한 비밀번호 사용을 허용하는 경우
2. 민감한 인증 정보가 노출될 경우
- 인증 정보의 부적절한 노출: 비밀번호나 인증 토큰 등 민감한 인증 정보가 암호화되지 않은 채 URL에 포함되어 전송되거나, 다른 사용자에게 노출될 수 있는 방식으로 저장되는 경우
3. 중요 작업 수행 시 미흡한 본인 확인 절차
- 추가 확인 없는 정보 변경: 이메일 주소 변경, 비밀번호 재설정 등 중요한 계정 정보를 변경할 때 현재 비밀번호 재확인과 같은 추가적인 본인 확인 절차를 거치지 않아 공격자가 쉽게 계정을 탈취할 수 있는 경우.
4. 인증 토큰의 부실한 유효성 검증
- 토큰 무결성/유효성 검증 실패: 시스템이 사용자의 신원을 증명하는 인증 토큰(예: JWT)의 위조 여부나 유효 기간을 제대로 확인하지 않아 공격자가 조작된 토큰으로 시스템에 접근하는 경우
5. 비밀번호가 안전하게 관리되지 않는 경우
- 안전하지 않은 비밀번호 저장: 비밀번호를 암호화하지 않고 평문으로 저장하거나, 매우 약하게 해싱하여 공격자가 쉽게 해독할 수 있는 경우
- 약한 암호화 키 사용: 인증 메커니즘에 약한 암호화 키를 사용하여 공격자가 쉽게 무력화시킬 수 있는 경우
6. 마이크로서비스 간 인증 누락
- 마이크로서비스 간 인증 부재: 다른 마이크로서비스가 인증 없이 접근 가능하거나, 약하거나 예측 가능한 토큰을 사용하여 인증을 강제하는 경우
공격 시나리오 예시
실제 어떤 방식으로 '취약한 인증'을 악용하는지 두 가지 시나리오를 통해 알아보겠습니다.
시나리오 #1
여러 시도를 한 번에 보내는 무차별 대입 공격 만약 시스템이 비밀번호 시도 횟수를 제한하여 일정 횟수 이상 틀리면 계정이 잠기도록 설정되어 있다고 해봅시다. 하지만 공격자는 이 제한을 우회하는 방법을 사용합니다. 그는 한 번의 요청에 여러 개의 비밀번호를 동시에 시도하는 기술(예: GraphQL 배치 쿼리)을 이용합니다. 이렇게 하면 시스템은 여러 번의 시도를 한 번으로 인식하게 되고, 공격자는 제한 없이 수많은 비밀번호를 동시에 대입하며 계정 정보를 탈취하려 할 수 있습니다.
시나리오 #2
본인 확인 없는 이메일 주소 변경을 통한 계정 탈취 사용자 계정과 연결된 이메일 주소를 변경할 때, 현재 사용 중인 비밀번호를 다시 입력하여 본인임을 확인하는 절차가 없다고 가정해 보세요. 공격자가 어떤 방식으로든 사용자의 인증 토큰을 획득하면, 해당 토큰을 이용하여 피해자의 이메일 주소를 자신의 것으로 변경할 수 있습니다. 이메일 주소 변경 후, 공격자는 '비밀번호 재설정' 기능을 이용하여 자신의 이메일로 재설정 링크를 받아 계정 전체를 탈취할 수 있게 됩니다.
대응 방안
이러한 위협으로부터 API를 보호하기 위해서는 다음과 같은 예방 조치를 취해야 합니다.
1. 모든 인증 흐름 파악: 모바일, 웹, 원클릭 인증 링크 등 API로 인증할 수 있는 모든 가능한 흐름을 명확히 파악하고 이해해야 합니다.
2. 인증 메커니즘 이해: 사용 중인 인증 메커니즘(예: OAuth, API 키)이 어떻게 작동하는지 정확히 이해해야 합니다. 예를 들어, OAuth는 사용자 인증을 위한 프로토콜이 아니며, API 키는 사용자 인증이 아닌 API 클라이언트 인증에만 사용되어야 합니다.
3. 표준화된 인증 방식 채택: 인증, 토큰 생성, 비밀번호 저장 시에는 검증된 보안 표준 기술을 사용하고, 독자적인 방식을 개발하는 것을 피해야 합니다.
4. 비밀번호 재설정/복구 엔드포인트 보호: 비밀번호 재설정이나 계정 복구 엔드포인트도 로그인 엔드포인트와 동일하게 무차별 대입 공격 방지, 속도 제한 및 계정 잠금 보호 기능을 적용해야 합니다.
5. 민감한 작업 시 재인증 요구: 이메일 주소나 2단계 인증(2FA) 전화번호 변경과 같은 민감한 작업에 대해서는 재인증을 요구해야 합니다.
6. OWASP 인증 치트시트 활용: OWASP Authentication Cheatsheet를 참고하여 강력한 인증을 구현합니다.
7. 다단계 인증(MFA) 도입: 가능한 모든 곳에 다단계 인증을 구현하여 보안을 강화합니다.
8. 강력한 무차별 대입 방지 메커니즘 구현: 크리덴셜 스터핑, 사전 공격, 인증 엔드포인트에 대한 무차별 대입 공격을 완화하기 위한 강력한 메커니즘을 구현하며, 이는 일반적인 API 속도 제한보다 더 엄격해야 합니다.
9. 계정 잠금/CAPTCHA 및 약한 비밀번호 검사: 특정 사용자에 대한 무차별 대입 공격을 방지하기 위해 계정 잠금 또는 CAPTCHA 메커니즘을 구현하고, 약한 비밀번호를 체크하는 기능을 도입합니다.
API02:2023 Broken Authentication은 시스템의 신뢰성을 지키는 데 있어 가장 근본적인 '인증' 단계에서 발생하는 취약점입니다. 단순히 로그인 기능만을 생각하는 것이 아니라, 사용자와 시스템이 안전하게 상호작용할 수 있도록 모든 인증 관련 과정을 꼼꼼하게 설계하고 보호하는 것이 중요합니다.
읽어주셔서 감사합니다.