API2:2023 Broken Authentication
위협 요소/공격 경로 | 보안 취약점 | 영향 |
API 명세: 악용 용이함 | 확산성: 탐지 용이함 | 기술적 심각도: 특정 비지니스 |
인증 메커니즘은 모든 사람에게 노출되기 때문에 공격자의 쉬운 표적이 됩니다. 일부 인증 문제를 악용하려면 더 높은 수준의 기술이 필요할 수 있지만 일반적으로 악용 도구를 사용할 수 있습니다. | 인증 경계 및 고유한 구현 복잡성에 대한 소프트웨어 및 보안 엔지니어의 오해로 인해 인증 문제가 널리 퍼집니다. 손상된 인증을 감지하는 방법론을 사용할 수 있으며 쉽게 만들 수 있습니다. | 공격자는 시스템 내 다른 사용자의 계정을 완전히 제어할 수 있고, 개인 데이터를 읽고, 그들을 대신하여 민감한 작업을 수행할 수 있습니다. 시스템은 공격자의 행동과 합법적인 사용자의 행동을 구별할 수 없습니다. |
취약한 API
인증 end-points와 흐름은 보호해야 하는 자산입니다. 또한 "비밀번호 찾기/비밀번호 재설정"은 인증 메커니즘과 동일한 방식으로 처리되어야 합니다.
API는 다음과 같은 경우 취약합니다.
•
공격자가 유효한 사용자 이름 및 비밀번호 목록과 함께 무차별 대입을 사용하는 크리덴셜 스터핑(Credential stuffing: 여러 가지의 경로로 수집한 사용자들의 로그인 인증 정보를 다른 사이트의 계정 정보에 마구 대입하여 공격하는 방식)을 허용합니다.
•
보안 문자/계정 잠금 메커니즘을 제시하지 않고 공격자가 동일한 사용자 계정에 대해 무차별 대입 공격을 수행할 수 있도록 허용합니다.
•
취약한 비밀번호를 허용합니다.
•
인증 토큰 및 비밀번호와 같은 민감한 인증 세부정보를 URL로 보냅니다.
•
사용자가 비밀번호 확인을 요청하지 않고 이메일 주소, 현재 비밀번호를 변경하거나 기타 민감한 작업을 수행할 수 있도록 허용합니다.
•
토큰의 진위 여부를 확인하지 않습니다.
•
서명되지 않은/약하게 서명된 JWT 토큰 허용({"alg":"none "})
•
JWT 만료 날짜를 확인하지 않습니다.
•
일반 텍스트, 암호화되지 않았거나 약하게 해시된 비밀번호를 사용합니다.
•
취약한 암호화 키를 사용합니다.
또한 다음과 같은 경우 마이크로서비스가 취약합니다.
•
다른 마이크로서비스는 인증 없이 액세스할 수 있습니다.
•
인증을 시행하기 위해 약하거나 예측 가능한 토큰을 사용합니다
공격 시나리오
Scenario #1
사용자 인증을 수행하려면 클라이언트는 사용자 자격 증명을 사용하여 아래와 같은 API 요청을 발행해야 합니다:
POST /graphql
{
"query":"mutation {
login (username:\"<username>\",password:\"<password>\") {
token
}
}"
}
JavaScript
복사
자격 증명이 유효하면 사용자를 식별하기 위해 후속 요청에 제공되어야 하는 인증 토큰이 반환됩니다. 로그인 시도에는 속도 제한이 적용됩니다. 즉, 분당 3번의 요청만 허용됩니다.
피해자의 계정으로 무차별 로그인을 하기 위해 악의적인 행위자는 GraphQL 쿼리 일괄 처리를 활용하여 요청 속도 제한을 우회하여 공격 속도를 높입니다:
POST /graphql
[
{"query":"mutation{login(username:\"victim\",password:\"password\"){token}}"},
{"query":"mutation{login(username:\"victim\",password:\"123456\"){token}}"},
{"query":"mutation{login(username:\"victim\",password:\"qwerty\"){token}}"},
...
{"query":"mutation{login(username:\"victim\",password:\"123\"){token}}"},
]
JavaScript
복사
Scenario #2
사용자 계정과 연결된 이메일 주소를 업데이트하려면 클라이언트는 아래와 같은 API 요청을 발행해야 합니다:
PUT /account
Authorization: Bearer <token>
{
"email": "<new_email_address>"
}
JavaScript
복사
API는 사용자에게 현재 비밀번호를 제공하여 신원을 확인할 것을 요구하지 않기 때문에 인증 토큰을 훔칠 수 있는 공격자가 이메일을 업데이트한 후 비밀번호 재설정 워크플로를 시작하여 피해자의 계정을 탈취할 수 있습니다.
예방 방법
•
API에 인증하기 위해 가능한 모든 흐름(모바일/웹/원클릭 인증을 구현하는 딥 링크 등)을 알고 있는지 확인하세요. 엔지니어에게 어떤 흐름을 놓쳤는지 물어보세요.
•
인증 메커니즘에 대해 읽어보세요. 무엇을 어떻게 사용하는지 이해했는지 확인하세요. OAuth는 인증이 아니며 API 키도 아닙니다.
•
인증, 토큰 생성 또는 비밀번호 저장 과정을 다시 발명하지 마세요. 표준을 사용하십시오.
•
자격 증명 복구/비밀번호 분실 end-points는 무차별 대입, 속도 제한 및 잠금 보호 측면에서 로그인 end-points로 처리되어야 합니다.
•
민감한 작업(예: 계정 소유자 이메일 주소/2FA 전화번호 변경)에는 재인증이 필요합니다.
•
가능하다면 multi-factor 인증을 사용하세요.
•
인증 end-points에 대한 credential stuffing, dictionary attacks, brute force attacks을 완화하기 위해 anti-brute force메커니즘을 구현합니다. 이 메커니즘은 API의 일반적인 속도 제한 메커니즘보다 더 엄격해야 합니다.
•
•