SQL 인젝션 탐지에서 오탐이 다수 발생한 적이 있습니다. 저는 경고 알림만으로 판단하지 않고 탐지된 쿼리를 확인했습니다. 정상 쿼리로 확인한 뒤 오탐으로 판단했고, 탐지 패턴을 정교화했습니다.
이 경험에서 제가 강조하고 싶은 것은 정상처럼 보이는 내용 안에도 공격 요소가 숨어 있을 수 있다는 점입니다. 오탐을 줄이는 과정에서도 실제 공격을 탐지하는 기준을 함께 살펴야 합니다. 이 글에서는 오탐과 미탐의 발생 원인, SQL 인젝션 경고의 확인 항목, 패턴 조정 시 판단 기준을 정리합니다.
오탐과 미탐은 경고의 유무만으로 판단하지 않습니다
False Positive는 정상 행위를 위협으로 잘못 탐지한 ‘오탐’이며, False Negative는 실제 위협을 탐지하지 못한 ‘미탐’입니다. 반대로 위협을 올바르게 탐지한 결과는 정탐입니다. NIST SP 800-94는 두 오류를 설명하면서 탐지 설정에 따라 서로의 발생 가능성이 달라질 수 있다고 밝힙니다. 이 문서는 기본 개념의 근거로 사용합니다. [1]
| 실제 행위 | 위협 경고 발생 | 위협 경고 없음 |
|---|---|---|
| 위협 행위 | 정탐 | 미탐 |
| 정상 행위 | 오탐 | 정상 판정 |
미탐은 경고 목록에 나타나지 않으므로 경고가 적다는 사실만으로 탐지가 잘된다고 결론 내릴 수 없습니다. 또한 공격 시도가 실패했다는 이유만으로 그 경고를 오탐으로 분류해서는 안 됩니다. 공격 시도의 탐지 여부와 실제 피해 발생 여부는 별도로 확인할 항목입니다.
정상 업무와 겹치는 패턴, 보이지 않는 데이터가 오류를 만듭니다
오탐은 탐지 조건이 정상 업무의 문자열이나 동작과 겹칠 때 발생할 수 있습니다. SQL 관련 단어나 기호가 포함됐다는 사실만으로 입력값이 공격이라고 확정할 수는 없습니다. OWASP CRS 문서도 범용 탐지 규칙이 개별 웹 서비스의 특성을 알지 못해 정상 요청과 잘못 일치할 수 있다고 설명합니다. [2]
반면 미탐은 위협이 규칙의 탐지 범위 밖에 있거나, 판단에 필요한 데이터가 수집되지 않을 때 발생할 수 있습니다. 탐지 대상에서 지나치게 넓은 범위를 제외하는 것도 확인할 지점입니다. 이전에 정상으로 판단한 요청과 겉모양이 비슷하다는 이유로 이후 요청까지 정상이라고 간주하면 달라진 공격 요소를 놓칠 수 있습니다.
따라서 원인을 나눠 봐야 합니다. 정상 쿼리와 패턴이 겹친 문제라면 규칙 조건을 검토하고, 원본 데이터가 없다면 수집 상태를 확인합니다. 경고가 이미 생성됐지만 분석자가 잘못 종결한 경우는 탐지 규칙의 미탐과 분석 단계의 판단 오류를 구분해 관리합니다.
SQL 인젝션 경고는 탐지된 내용과 업무 맥락을 대조합니다
아래 표는 탐지된 쿼리를 확인한 경험과 연결해 활용할 수 있는 일반적인 점검 항목입니다. 실제 사례에서 이 항목을 모두 수행했다는 의미는 아닙니다. 제품별 설정을 바꾸기 전에 확보한 자료가 무엇을 보여주는지부터 구분합니다.
| 확인 항목 | 판단할 내용 |
|---|---|
| 일치한 부분과 전체 내용 | 어떤 조건이 일치했으며 전체 문맥에서도 공격 의도가 의심되는지 확인합니다. |
| 업무 기능과 입력 위치 | 해당 기능에서 허용되는 입력인지, 정상 처리 목적과 맞는지 대조합니다. |
| 데이터가 관찰된 계층 | 웹 요청의 파라미터인지 DB 쿼리 기록인지 구분하고 실제 실행 여부를 따로 확인합니다. |
| 추가 근거와 불확실성 | 필요한 경우 관련 요청·애플리케이션 기록을 대조하고 근거가 부족하면 판정을 보류합니다. |
웹방화벽이 관찰하는 요청 문자열과 데이터베이스에서 실제 실행된 SQL은 동일한 자료가 아닐 수 있습니다. 경고 화면에 SQL처럼 보이는 내용이 있다고 해서 해당 내용이 그대로 실행됐다고 단정해서는 안 됩니다. 정상 업무에서 사용되는 값인지와 SQL의 실행 구조를 바꾸려는 입력인지 구분해 살펴야 합니다.
한 부분이 정상으로 보인다고 요청 전체를 정상으로 확정하지 않는 것이 제 판단 기준입니다. 분석 자료를 공유할 때에는 쿼리나 요청에 포함된 개인정보·인증정보도 확인하고 필요한 부분만 익명화해 사용해야 합니다.
탐지 패턴 정교화는 제외 범위와 남겨야 할 탐지를 함께 검증합니다
오탐이 많다는 이유로 탐지 규칙 전체를 끄면 정상 요청뿐 아니라 해당 규칙이 찾던 공격까지 보이지 않을 수 있습니다. 먼저 어떤 정상 조건이 잘못 일치했는지 찾고, 변경 범위를 해당 기능과 입력 항목에 맞게 좁히는 방안을 검토합니다. 제품마다 조정 방법이 다르므로 실제 설정은 제품 문서와 운영 기준에 따라야 합니다.
예를 들어 OWASP CRS는 원본 규칙 파일을 직접 고치기보다 별도의 규칙 제외 기능을 이용하도록 권고합니다. 이는 CRS의 구현 지침이며 모든 제품에 같은 설정 방식을 적용한다는 뜻은 아닙니다. [2]
변경 후에는 오탐으로 확인한 정상 사례와 탐지해야 할 위협 사례를 함께 검증하는 방법을 권합니다. 변경 사유, 적용 범위, 확인 결과, 되돌릴 조건을 기록하면 다음 검토에서도 판단 근거를 이어갈 수 있습니다.
탐지 조정과 취약점 예방도 구분해야 합니다. OWASP는 SQL 인젝션 예방을 위해 데이터 값에는 매개변수화된 쿼리를 사용하고, 동적 쿼리 구조는 애플리케이션이 정한 선택지로 제한하는 등의 방어를 안내합니다. 탐지 패턴 조정만으로 애플리케이션의 SQL 인젝션 취약점이 제거됐다고 볼 수는 없습니다. [3]
자주 묻는 질문
SQL 문법이 정상이라면 오탐으로 판단해도 되나요?
문법이 올바르다는 사실만으로 정상 업무라고 확정할 수는 없습니다. 해당 기능에서 허용되는 요청인지, 사용자의 권한과 처리 목적에 맞는지까지 대조해야 합니다. 판단 근거가 부족하면 정상으로 종결하기보다 추가 확인 대상으로 남기는 편이 적절합니다.
정교화한 탐지 패턴은 언제 다시 검토해야 하나요?
서비스 기능이나 입력 형식이 바뀌거나 탐지 규칙이 업데이트되면 기존 조정 조건의 재검토를 권합니다. 이전의 정상 사례가 여전히 정상으로 처리되는지와 탐지해야 할 위협 사례가 계속 탐지되는지를 함께 확인합니다. 예외를 적용했다면 그 범위와 유지 사유도 다시 살펴봅니다.
경고가 없는 상태에서 미탐 여부는 어떻게 점검하나요?
승인된 테스트 환경에서 탐지돼야 할 사례를 검증하거나, 사후에 확인된 위협의 기록을 당시 탐지 결과와 대조하는 방법을 사용할 수 있습니다. 이때 원본 데이터 수집, 규칙 평가, 경고 생성·전달 중 어느 단계에서 누락됐는지 나눠 확인합니다. 검증 사례를 통과한 결과는 그 범위의 확인이며 모든 미탐이 없다는 보장은 아닙니다.
결론
오탐과 정탐을 구분할 때는 경고 제목보다 탐지된 내용과 정상 업무의 근거를 먼저 확인해야 합니다. 제가 탐지된 쿼리를 확인한 경험도 그 출발점에 해당합니다. 정상 요청 안에도 공격 요소가 섞일 수 있다는 관점을 유지하면서, 판정 근거와 패턴 변경 범위, 변경 후 검증 결과를 남기는 것이 다음 행동입니다.