Web Security 실전 플레이북
3줄 요약
- 실전 대응은
탐지 → 증거 보존 → 영향 범위 산정 → 차단/완화 → 사용자 보호 → 재발 방지를 순서 있는 행동으로 만드는 일이다.
- 로그인, 토큰, 권한, 브라우저 보안 사고는 같은 보안 사고처럼 보여도 확인해야 할 로그, 임시 차단 지점, 사용자 영향도가 다르다.
- 좋은 플레이북은 장애 대응 문서가 아니라 공격자가 남긴 흔적과 방어 실패 지점을 복원할 수 있는 실행 문서여야 한다.
핵심 정리
- 로그인 장애는 먼저
정상 장애, credential stuffing, password spraying, 계정 잠금 우회, MFA 피로 공격을 분리한다.
- Token 탈취는 단일 access token보다 refresh token family, 기기 세션, 재사용 탐지, 강제 로그아웃 범위를 기준으로 판단한다.
- 권한 우회는 패치보다 먼저 이미 열람되거나 변경된 resource 범위를 산정해야 한다.
- CORS, CSRF, XSS 사고는 브라우저 정책, 서버 설정, 사용자 세션 피해가 함께 얽히므로 원인별 containment가 달라야 한다.
- 사고 보고서는 비난 자료가 아니라 타임라인, 판단 근거, 남은 불확실성, 재발 방지 소유자를 남기는 운영 산출물이다.
- 모든 대응은 원문 secret, password, token, 주민번호, 카드번호를 로그에 남기지 않는 전제로 설계한다.
하위 문서 연결
-
- 로그인 장애와 계정 탈취 의심 대응: 실패율 증가가 장애인지 공격인지 나누고, 계정 보호 조치를 정한다.
-
- Token 탈취와 세션 무효화 대응: token 재사용을 탐지하고 세션 폐기 범위를 결정한다.
-
- 권한 우회 취약점 대응: BOLA/IDOR 사고에서 영향 데이터를 산정하고 임시 차단과 영구 수정을 분리한다.
-
- CORS CSRF XSS 사고 대응: Origin, CSRF token, DOM sink, CSP report를 기준으로 브라우저 보안 사고를 수습한다.
-
- 보안 사고 보고서와 재발 방지: 사고 후속 문서를 검증 가능한 조치 목록으로 만든다.
헷갈리는 지점
로그인 실패가 많다는 사실만으로는 장애인지 공격인지 알 수 없다.
- 계정별, IP별, ASN별, user agent별, credential pair별 분포를 같이 봐야 한다.
- 공격이면 차단이 성공한 이벤트도 증거이며, 장애이면 정상 사용자의 재시도 패턴이 핵심 증거다.
logout 처리와 탈취 token 무효화는 다르다.
- logout은 현재 세션 종료에 가깝고, 사고 대응은 같은 token family와 위험 기기의 후속 사용을 끊는 일이다.
- refresh token rotation을 쓰는 경우 재사용 탐지가 가장 중요한 경보가 된다.
권한 버그를 고쳤다와 피해 범위를 확인했다는 다르다.
- 권한 우회 사고는 어떤 사용자가 어떤 resource를 언제 열람/수정했는지 복원해야 한다.
- 로그가 부족하면 DB 스냅샷, access log, CDN log, audit table을 교차 확인해야 한다.
CORS 오류가 항상 보안 사고는 아니다.
- 단순 프론트 배포 오류일 수 있지만, credential 포함 CORS가 열린 상태라면 민감 응답 노출 여부를 먼저 확인한다.
- CSRF와 XSS는 사용자의 브라우저와 세션을 이용하므로 서버 로그만으로는 충분하지 않을 수 있다.
확인 질문
- 보안 사고 대응에서 가장 먼저 보존해야 하는 것은 무엇인가?
- 수정 전 증거다. access log, audit log, 배포 버전, 설정 값, 영향을 받은 계정과 resource 목록을 먼저 보존한다.
- 차단 조치를 바로 적용하기 전에 확인할 것은 무엇인가?
- 차단이 증거를 지우는지, 정상 사용자 피해가 얼마나 큰지, 공격자가 우회할 다음 경로가 무엇인지다.
- 재발 방지 항목이 좋은지 판단하는 기준은 무엇인가?
- 담당자, 기한, 검증 방법, 실패 시 경보가 있으며 코드, 테스트, 로그, 운영 절차 중 어디가 바뀌는지 분명해야 한다.