트러블슈팅DevOps
3

실무에서 만난 X-SIGNATURE 분석하기(HMAC)

HMAC에 대해서 정리해보았습니다.

실무에서 만난 X-SIGNATURE 분석하기(HMAC)

회사에서 웹 취약점 분석팀의 정기 진단을 받게 되었고, 그 과정에서 API 요청 검증 방식에 문제가 있다는 지적을 받았다.

이번 글은 어떤 문제가 발견되었고, 왜 그 문제가 발생했는지, 그리고 HMAC 기반 X-SIGNATURE로 어떻게 해결했는지를 정리한 기록이다.


진단에서 발견된 문제

취약점 분석팀은 아래와 같은 요청을 가로채서 값을 조작한 뒤 재전송하는 테스트를 진행했다.

원래 요청

{
    "amount": 10000,
    "userId": "minseok"
}

변조된 요청

{
    "amount": 999999,
    "userId": "minseok"
}
  • 문제점: 서버가 Payload의 무결성(변조 여부)을 검증하는 로직이 없어, 위 변조된 요청이 그대로 정상 처리
  • 위험도: 결제 금액·사용자 권한 등 민감한 값이 조작될 경우 금전적 피해로 직결
  • 분류: OWASP 기준 "데이터 무결성 검증 미흡(Broken Integrity Check)" 유형에 해당

진단 결과서에는 "요청 위변조를 방지할 수 있는 서명(Signature) 검증 메커니즘 도입 필요"라는 권고 사항이 포함되어 있었다.


원인 분석: 왜 이 문제가 생겼는가

항목기존 상태문제
요청 검증 방식Payload 값만 그대로 신뢰중간자가 값을 바꿔도 탐지 불가
인증 수단사용자 인증(로그인)만 존재인증된 사용자라도 요청 자체의 위변조는 별개 문제
전송 구간 보호HTTPS만 적용HTTPS는 도청은 막아도, 클라이언트단 조작이나 재전송 공격까지 막지는 못함

즉, "누가 보냈는가(인증)"는 확인했지만 "보낸 내용이 그대로 도착했는가(무결성)"는 확인하지 않은 것이 근본 원인이었다.


해결 방안: HMAC 기반 X-SIGNATURE 도입

처음에는 "X-SIGNATURE를 복호화해서 Payload와 비교하는 방식인가?"라고 생각했지만, 이는 잘못된 접근이었다.

HMAC은 암호화가 아니다.

  • 암호화 ❌ / 복호화 ❌
  • 같은 계산을 두 번 수행해서 결과가 같은지 비교하는 방식

동작 원리

Payload + Secret Key
        │
        ▼
   HMAC-SHA256
        │
        ▼
   X-SIGNATURE

클라이언트는 Payload와 Secret Key로 HMAC을 계산해 X-SIGNATURE를 만들고, Payload와 함께 서버로 전송한다.

Payload      { "amount": 10000 }
X-SIGNATURE  AAAA

서버 측 검증

서버도 동일한 Secret Key를 갖고 있으므로, 수신한 Payload로 같은 계산을 다시 수행한다.

서버 계산 결과 == 전달받은 X-SIGNATURE ?
상황서버 계산 결과비교처리
정상 요청AAAAAAAA == AAAA정상 처리
사용자가 값을 직접 수정 후 재계산해서 전송BBBBBBBB == BBBB정상 처리 (새 값 기준 재계산했으므로 문제 없음)
공격자가 값만 몰래 변조 (AAAA Signature 그대로 사용)BBBBBBBB != AAAA요청 거부

공격자가 새 Signature를 만들 수 없는 이유

공격자는 Payload와 X-SIGNATURE를 볼 수는 있지만, Secret Key를 모른다. 따라서 변조한 값에 맞는 새로운 Signature를 계산할 방법이 없다. 이것이 HMAC이 요청 위변조를 원천 차단하는 핵심 이유다.

구현

알고리즘을 직접 구현하는 것이 아니라, 표준 라이브러리를 사용한다.

// Java
Mac mac = Mac.getInstance("HmacSHA256");
// Node.js
crypto.createHmac("sha256", secret)

개발자가 결정할 부분은 **알고리즘 선택(HMAC-SHA256 등)**과 Secret Key 관리 방식 두 가지뿐이다.


적용 후 전체 흐름

[클라이언트]                          [서버]
Payload 생성                          
    │
    ▼
HMAC 계산 → X-SIGNATURE 생성
    │
    ▼
API 요청 전송  ────────────────────▶  Payload + X-SIGNATURE 수신
                                          │
                                          ▼
                                   동일 Secret Key로 HMAC 재계산
                                          │
                                          ▼
                                   계산값 == X-SIGNATURE ?
                                     ┌────┴────┐
                                   일치        불일치
                                     │            │
                                  정상 처리      요청 거부(변조 탐지)

재진단 결과 및 정리

X-SIGNATURE 적용 후 취약점 분석팀의 재검증에서 Payload 변조 테스트가 모두 차단 처리되어 해당 항목은 종료(Close) 처리되었다.

  • HMAC은 암호화가 아니라 동일 계산의 결과 비교다.
  • Secret Key를 모르면 변조된 값에 맞는 Signature를 만들 수 없어 위변조를 탐지할 수 있다.
  • 이번 진단을 계기로, 인증(누가 보냈는가)과 무결성 검증(내용이 그대로인가)은 별개의 문제라는 것을 명확히 이해하게 되었다.

댓글

(0)
실무에서 만난 X-SIGNATURE 분석하기(HMAC) | 강민석의 개발블로그