인증 깨짐

인증 깨짐 (API2: Broken Authentication)

인증 메커니즘은 모든 사용자에게 노출돼 있어서 공격자에게 가장 매력적인 표적이에요. 그런데 의외로 많은 API가 인증 토큰을 제대로 검증하지 않거나, 비밀번호 확인 없이 민감한 계정 작업을 허용하거나, 비밀번호를 평문으로 저장하는 식으로 인증을 잘못 구현하고 있어요. 이런 취약점이 터지면 공격자는 다른 사용자의 계정을 통째로 장악하고, 개인 데이터를 읽고, 그 사용자 대신 민감한 동작을 수행할 수 있게 돼요. 인증 관련 엔드포인트와 흐름은 물론 "비밀번호 찾기/재설정" 흐름까지도 인증 메커니즘과 똑같은 수준으로 보호해야 해요.

출처: OWASP API Security Top 10 — API2:2023 Broken Authentication

어떤 API가 취약한가요?

  • 유효한 사용자명·비밀번호 목록으로 무차별 대입(credential stuffing)을 허용하는 경우
  • 캡차나 계정 잠금(lockout) 없이 같은 계정에 대고 무차별 대입(brute force)을 허용하는 경우
  • 약한 비밀번호를 허용하는 경우
  • 인증 토큰이나 비밀번호 같은 민감한 인증 정보를 URL에 담아 보내는 경우
  • 이메일 주소 변경, 비밀번호 변경 등 민감한 작업을 할 때 기존 비밀번호 확인을 요구하지 않는 경우
  • 수신 토큰의 진위를 검증하지 않는 경우
  • 서명되지 않았거나 약하게 서명된 JWT({"alg":"none"})를 허용하는 경우
  • JWT 만료 날짜를 검증하지 않는 경우
  • 비밀번호를 평문이나 비암호화·약한 해시로 저장하는 경우
  • 약한 암호화 키를 사용하는 경우

마이크로서비스 환경에서는 한 가지가 더 추가돼요. 다른 마이크로서비스가 인증 없이 접근할 수 있거나, 인증에 약하거나 예측 가능한 토큰을 사용하는 경우도 취약한 것으로 봐요.

공격 시나리오

시나리오 #1

클라이언트가 사용자 인증을 위해 아래처럼 자격 증명을 담은 API 요청을 보낸다고 해볼게요.

POST /graphql
{
  "query":"mutation {
    login (username:"<username>",password:"<password>") {
      token
    }
   }"
}

자격 증명이 유효하면 인증 토큰이 돌아오고, 이후 요청에서 그 토큰으로 사용자를 식별해요. 로그인 시도에는 분당 3회라는 제한적인 rate limiting이 걸려 있다고 가정해볼게요. 그런데 GraphQL은 쿼리 배칭(query batching) 을 쓸 수 있어요. 공격자는 요청 하나에 로그인 mutation을 여러 개 실어 보내 rate limiting을 우회하고, 피해자 계정에 대한 무차별 대입 공격을 훨씬 빠르게 진행해요.

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}}"},
  ...
]

시나리오 #2

사용자가 계정과 연결된 이메일 주소를 바꾸기 위해 아래와 같은 요청을 보낼 때, API가 현재 비밀번호 확인을 요구하지 않는다면 문제예요.

PUT /account
Authorization: Bearer <token>

{ "email": "<new_email_address>" }

공격자가 인증 토큰을 훔칠 수 있는 위치에 서게 되면, 피해자 계정의 이메일을 자기 것으로 바꾼 뒤 비밀번호 재설정 워크플로를 시작해 계정을 통째로 탈취할 수 있어요.

예방 방법

  • 특정 사용자를 겨냥한 무차별 대입 공격을 막도록 계정 잠금(account lockout)이나 캡차 메커니즘을 구현하고, 약한 비밀번호 검사를 도입해요.
  • API 키는 사용자 인증에 쓰면 안 돼요. API 키는 API 클라이언트 인증용으로만 사용해야 해요.

공격을 먼저 막는 것도 중요하지만, 취약점이 있어도 대응할 수 있도록 표준 비밀번호 강도 정책, 토큰 만료·폐기, 민감 작업 시 재인증 요구 같은 보호 조치를 함께 갖추는 게 좋아요.

더 알아보기