← 메인으로

🚫 전자금융 보안 모의해킹 · 불필요한 웹 메서드 차단

Target: 웹 서버 HTTP 메서드 허용 설정
평가기준: 위험도 4 WEB-SER 불필요 웹 메서드(038)
💡 쉽게 말하면
건물에 모든 출입문을 다 열어두면, 짐 넣는 문으로 폭탄을 들여오거나 살림을 통째로 들어낼 수 있습니다. 꼭 필요한 정문(GET/POST)만 열고 나머지 문은 잠가야 합니다.
🔓 공격 시뮬레이션 (Red Team)
🛡️ 대응 방안 (Blue Team)
HTTP 메서드 점검🔒 Secured Channel
서버가 PUT/DELETE/TRACE 등 불필요한 HTTP 메서드를 허용하면, 공격자가 PUT으로 웹셸을 업로드하거나 DELETE로 파일을 삭제하고, TRACE를 악용한 XST(Cross-Site Tracing)로 쿠키를 탈취할 수 있습니다.
⚡ 위험 메서드 악용(PUT/TRACE)
PUT로 웹셸 업로드 · TRACE로 XST
OFF
🖥️ 금융 시스템 처리 로그
[SYSTEM] Core Banking Channel ready.
[INFO] 거래 요청 대기 중...
⚖️ 컴플라이언스 위반 분석
공격 실행 후 분석 결과가 표시됩니다.
[심각] 전자금융 보안 기준 위반 감지
  • 평가기준 [전자금융] 불필요한 웹 메서드 차단(위험도 4)
  • 부적절한 HTTP 메서드 허용 / XST 노출(IN)
  • 전자금융감독규정 제15조: 서버 설정 보안 미흡
🛡️ 대응 코드/설정 실습

서버는 서비스에 필요한 GET/POST 메서드만 허용하고 TRACE/PUT/DELETE 등 불필요한 메서드는 비활성화해야 합니다. 메서드 제한 설정을 보완하세요.

📚 금융보안원 평가기준 / 조치 가이드

1. 점검 항목

서버 보안 > 불필요한 웹 메서드 차단

2. 위험 분석

  • PUT으로 웹셸 업로드 → 원격 코드 실행
  • DELETE로 임의 파일 삭제
  • TRACE 악용 XST로 쿠키 탈취

3. 조치 방법

  • 서비스 필요한 GET/POST만 허용
  • TRACE/PUT/DELETE 등 비활성화
  • OPTIONS Allow 헤더 점검·최소화
🏗️ 현대 금융 IT 환경에서의 변형
API GatewayK8s IngressCORS

어디가 달라졌나

메서드 통제 지점이 웹서버에서 API 게이트웨이·인그레스로 옮겨 갔습니다. REST 에서는 PUT·DELETE 가 정상 메서드라 “무조건 차단”이 성립하지 않고, 경로별로 허용 메서드를 정의하는 방식이 되었습니다.

현대 스택에서의 조치

  • API 게이트웨이에 정의된 메서드만 라우팅하고 나머지는 405 로 거절합니다. 스펙(OpenAPI)에서 자동 생성하면 어긋남이 줄어듭니다.
  • TRACE·TRACK 은 여전히 차단합니다(XST). 프레임워크 기본값에 남아 있는 경우가 있습니다.
  • CORS 프리플라이트와 혼동하지 않도록 OPTIONS 는 게이트웨이가 처리하고 백엔드로 넘기지 않습니다.
# K8s Ingress — 허용 메서드를 명시적으로 제한
nginx.ingress.kubernetes.io/configuration-snippet: |
  if ($request_method !~ ^(GET|POST|PUT|DELETE|OPTIONS)$) { return 405; }
놓치기 쉬운 곳 — HTTP 메서드 오버라이드 헤더(X-HTTP-Method-Override)를 프레임워크가 해석하면 POST 로 위장한 DELETE 가 통과합니다. 사용하지 않으면 꺼 두세요.