쇼핑몰 행사 시작 직후 접속이 급증했다. 같은 시각 보안 장비에는 반복 요청과 비정상 입력 경고가 쌓였다. 이때 요청이 많다는 이유만으로 접속 IP를 차단하면 실제 구매자까지 막을 수 있다. 반대로 행사 트래픽이라고 넘기면 그 사이에 섞인 공격 시도를 놓칠 수 있다.
웹 요청은 HTTP 메서드, 요청 경로, 헤더, 매개변수와 본문 등으로 구성된다. 정상 요청과 공격 요청은 같은 형식을 쓰기 때문에 겉모양만으로 나누기 어렵다. 실무에서는 요청 내용, 반복 양상, 사용자 맥락, 서버 처리 결과를 함께 비교해 판단 근거를 쌓아야 한다.
정상 기준은 서비스 기능별로 지정
상품 조회, 로그인, 파일 업로드는 정상적인 요청 형태부터 다르다. 상품 목록은 비로그인 상태로 반복 조회할 수 있고, 사내 연동 API는 사람이 누르지 않아도 일정한 간격으로 호출된다. 자동화되었다는 사실과 악의적인 행위라는 판단은 구분해야 한다.
먼저 기능별로 허용하는 메서드와 입력 형식, 인증 필요 여부, 평소 호출량과 실패 양상을 정리한다. 행사 일정, 배포 작업, 배치 실행 같은 업무 변화도 함께 기록한다. 여기서 말하는 정상 기준은 영구적인 허용 목록이 아니라 현재 서비스의 동작을 비교하기 위한 기준선이다.
의심 신호는 비정상에 포함시켜 분석
아래 표는 초기 분류를 위한 운영 판단 예시이며, 어느 항목도 단독으로 공격을 확정하는 기준은 아니다.
| 확인 항목 | 의심할 만한 양상 | 정상일 수 있는 반례 | 함께 확인할 정보 |
|---|---|---|---|
| 요청량·간격 | 특정 기능에 호출이 집중되거나 실패 뒤에도 반복 | 행사 접속, 배치 작업, 클라이언트 재시도 | 기능별 평소 호출량, 작업 일정, 서버 부하 |
| 경로·메서드 | 없는 경로를 연속 조회하거나 허용하지 않은 메서드 사용 | 오래된 즐겨찾기, 잘못 배포한 앱 | 배포 이력, 경로 분포, 실제 기능 명세 |
| 입력 내용 | 필드 목적과 맞지 않는 구문이나 형식 위반 | 코드 게시글, 서식 있는 문서 입력 | 탐지 위치, 해당 필드의 용도, 서버 검증 |
| 인증·권한 | 로그인 실패 반복, 권한 없는 대상 접근 | 비밀번호 오입력, 만료된 연동 자격 증명 | 계정별 실패 양상, 권한 검사 결과 |
| 응답·업무 결과 | 오류 증가, 예상하지 않은 조회·변경 | 서비스 장애, 배포 결함 | 오류 로그, 실제 업무 처리 내역 |
출발지 IP와 User-Agent도 참고 정보지만 사용자 신원을 보장하지 않는다. 회사망이나 통신사망에서는 여러 사용자가 하나의 공인 IP를 공유할 수 있다. User-Agent 역시 요청자가 지정할 수 있으므로 익숙한 브라우저 이름만 보고 안전하다고 판단해서는 안 된다.
WAF 경고와 공격 성공은 다른 성격으로 분류
웹 방화벽인 WAF는 요청이 규칙에 맞는지 검사해 경고나 차단을 수행한다. OWASP CRS의 이상 점수 방식은 규칙에 일치할 때 점수를 누적하고 임계값과 비교한다. 이 점수는 규칙 기반 판단 값이며 공격 확률이나 피해 규모를 나타내는 수치가 아니다. 모든 WAF가 동일한 방식으로 동작하는 것도 아니다. [1]
경고가 발생했다면 탐지 규칙과 일치한 필드, 장비가 실제 수행한 조치를 확인한다. 탐지 전용 모드라면 경고가 있어도 요청은 전달될 수 있다. 반대로 차단 응답이 기록되어 있어도 그 응답을 만든 계층이 WAF인지 애플리케이션인지 구분해야 한다.
HTTP 200은 업무 처리가 성공했다는 증거가 아니고, 403이나 500도 공격 성공의 증거가 아니다. 동일 요청의 애플리케이션 처리 결과와 예상하지 않은 조회·변경 여부까지 확인해야 한다. 따라서 기록에는 ‘규칙 일치’, ‘요청 차단’, ‘피해 확인’을 구분해 남기는 편이 좋다.
가상 예시: 같은 경고가 다른 결론으로 이어지는 경우
다음은 이해를 위한 가상 예시다. 사내 게시판에서 개발 문서를 올릴 때 코드와 태그가 포함된 입력이 탐지되었다고 하자. 해당 필드가 원래 코드를 저장하는 용도이고 권한·저장·출력 처리가 의도대로 동작한다면 오탐 가능성을 검토할 수 있다. 코드가 입력되었다는 이유만으로 안전한 것은 아니며, 애플리케이션의 검증 방식도 확인해야 한다.
반면 같은 유형의 입력이 숫자만 받는 조회 조건에 반복되고, 존재하지 않는 경로 탐색까지 이어진다면 조사 우선순위가 높아진다. 이때도 공격 시도 여부와 실제 피해 여부는 별도로 판단한다. OWASP CRS 문서 역시 정상적인 입력이 일반 탐지 규칙과 겹쳐 오탐을 일으킬 수 있음을 설명한다. [2]
오탐을 줄이는 점검 순서
다음은 공식 문서의 로깅·규칙 조정 원칙을 바탕으로 정리한 운영 권고다. 진행 중인 피해 정황이나 서비스 장애가 있다면 긴급 대응을 우선하고, 아래 순서를 일률적으로 기다리지 않는다.
- 경고가 발생한 시각과 시간대, 요청 식별자, 경로·메서드, 규칙 ID와 조치를 확보한다.
- 앞뒤 요청을 확인해 하나의 입력 문제인지, 여러 경로·계정을 대상으로 반복되는 행위인지 구분한다.
- 애플리케이션 로그와 연결해 인증·권한 검사 및 실제 업무 결과를 확인한다.
- 정상 기능에서 재현되는지 승인된 시험 환경에서 확인하고, 개발·업무 담당자와 입력 목적을 검토한다.
- 오탐이 확인되면 해당 경로·필드·규칙 등 필요한 범위로 예외를 좁힌다. 변경 이유, 담당자, 재검토 조건과 원복 방법을 남긴다.
- 변경 후 정상 기능이 복구되었는지와 다른 탐지가 유지되는지를 함께 점검한다.
CRS는 규칙 원본을 직접 수정하기보다 별도의 제외 설정을 활용하도록 안내한다. 한 건의 오탐 때문에 전체 공격 유형의 탐지를 끄거나 전역 임계값을 계속 높이는 방식은 탐지 범위를 약화시킬 수 있다. 실제 적용 가능한 예외 범위는 사용하는 제품과 구성에 따라 확인해야 한다. [참고 1·2]
실무에서는 판단 가능한 로그부터 확보
분석을 위해 요청 본문 전체를 무조건 저장하는 방식은 피한다. OWASP는 애플리케이션 로그가 사용자와 행위·결과의 맥락을 제공한다는 점과 비밀번호·접근 토큰 같은 민감정보를 로그에서 제외해야 한다는 점을 설명한다. 원문 세션 값 대신 별도의 상관분석 식별자를 사용하는 등 분석 목적에 맞춰 수집 범위를 정한다. [3]
소규모 조직이라면 처음부터 복잡한 점수 체계를 만들기보다 경고와 실제 업무 결과를 연결할 수 있는지 먼저 점검하는 편이 현실적이다. ‘어떤 요청이 왜 걸렸고, 어디서 막혔으며, 업무에 어떤 영향이 있었는지’를 설명할 수 있어야 차단과 예외 조정 모두 근거를 갖는다. 보안 담당자가 경고를 분석하고 개발·운영 담당자가 정상 동작과 처리 결과를 확인하는 역할 분담도 함께 정한다.
적용할 때 남겨야 할 판단 근거
웹 공격 트래픽은 단일 문자열이나 요청 횟수만으로 구분하기 어렵다. 기능별 정상 기준과 실제 처리 결과를 연결하고, 의심 요청은 조사 우선순위에 따라 검토한다. 정상 여부를 확인하지 못했다면 미확인으로 남기고, 예외를 적용할 때는 범위와 원복 조건을 함께 기록해야 다음 경고에서도 같은 판단을 반복할 수 있다.