블라인드 SQL 인젝션 (Blind SQL Injection)
쉽게 풀면
블라인드 SQL 인젝션은 마치 눈을 가린 채 스무고개를 하듯, 직접적인 답은 볼 수 없지만 "예/아니오" 같은 간접적인 반응만으로 정답을 하나씩 유추해 나가는 공격입니다.
일반 SQL 인젝션은 오류 메시지에 데이터베이스 정보가 그대로 노출되지만, 블라인드 방식에서는 화면에 아무 정보도 나타나지 않기 때문에 공격자는 질문을 조금씩 바꿔가며 참일 때와 거짓일 때의 반응 차이를 관찰해 정보를 조금씩 캐냅니다. 시간이 오래 걸리지만 자동화 도구를 쓰면 실질적으로 데이터를 통째로 빼낼 수 있습니다.
왜 중요한가
블라인드 SQL 인젝션은 겉으로 드러나는 단서가 거의 없어 탐지와 방어가 까다롭기 때문에 웹 애플리케이션 보안 연구에서 취약점 진단 자동화와 방어 기법의 핵심 사례로 다뤄집니다. 오류 메시지를 숨기는 것만으로는 근본적인 방어가 되지 않는다는 점을 보여주는 대표적인 공격이기도 합니다.
방어 측 로그에서는 동일한 요청 패턴이 조금씩 변형되며 반복적으로 발생하는 흔적이 남기 때문에, 이러한 반복 질의 패턴 자체가 블라인드 SQL 인젝션을 탐지하는 유용한 단서로 활용됩니다.
핵심 정리
- 위치: 블라인드 SQL 인젝션은 SQL 인젝션의 한 갈래입니다. OWASP는 이를 데이터베이스에 참·거짓으로 답할 수 있는 질문을 던지고 응용프로그램의 응답을 보고 답을 판단하는 유형으로 설명합니다.
- 분류: 무엇을 단서로 삼느냐에 따라 응답 내용의 차이를 보는 내용 기반(content-based)과 응답 지연을 보는 시간 기반(time-based)으로 나눕니다.
- 원인은 일반 SQL 인젝션과 같습니다: MITRE의 약점 목록은 이 계열 전체를 CWE-89, 곧 외부 입력으로 SQL 명령을 구성하면서 명령의 뜻을 바꿀 수 있는 특수 요소를 제대로 무력화하지 않는 약점으로 정의합니다. 블라인드 방식은 공격 패턴 목록에 CAPEC-7로 따로 올라 있습니다.
- 이론적 정의: Su와 Wassermann(2006)은 웹 응용프로그램의 명령 주입을 입력이 질의의 구문 구조를 바꾸는 현상으로 형식화했습니다. 이 정의에서는 결과가 화면에 보이는지와 관계없이 같은 결함입니다.
- 대응: CWE-89가 제시하는 완화책은 매개변수화, 허용 목록에 따른 입력 검증, 최소 권한, 오류 메시지 관리, 응용 방화벽 등으로 블라인드 방식에도 그대로 적용됩니다.
예시로 보기
블라인드 방식이 왜 성립하는지를 방어자의 눈으로 정리하면, 응용프로그램이 의도하지 않게 흘리는 신호의 문제입니다. 공격 구문이나 절차는 다루지 않습니다.
| 새는 신호 | 왜 정보가 되는가 | 방어·탐지에서 보는 것 |
|---|---|---|
| 응답 내용의 차이 | 조건이 참일 때와 거짓일 때 화면이 조금이라도 다르면 그 차이가 ‘예/아니오’ 한 번의 답이 됩니다. | 같은 매개변수에 조금씩 다른 요청이 대량으로 반복되는 양상 |
| 응답 시간의 차이 | 화면이 완전히 같아도 응답이 늦어지는지로 같은 답을 얻습니다. | 특정 요청에서만 응답 시간이 규칙적으로 길어지는 양상 |
이 표가 말해 주는 것은 두 가지입니다. 첫째, 오류 메시지를 감추는 조치는 첫 번째 신호의 일부만 줄일 뿐 결함 자체를 없애지 못합니다. 둘째, 입력이 질의의 구조를 바꿀 수 없게 만들면(매개변수화) 두 신호가 모두 의미를 잃습니다. 방어 연구에는 질의 구조를 보호하려는 접근이 여럿 있습니다. 정적 분석과 실행 중 감시를 결합해 주입을 탐지·차단하는 방법(Halfond & Orso, 2006)이나 무작위화를 이용하는 방법(Boyd & Keromytis, 2004)이 그 예입니다.
자주 하는 오해
| 오해 | 바로잡기 |
|---|---|
| 오류 메시지를 숨기면 SQL 인젝션은 막힌다. | 오류를 숨겨도 응답 내용이나 응답 시간의 차이가 남습니다. 블라인드 방식은 바로 그 상황을 전제로 한 유형입니다. |
| 블라인드 방식은 별개의 취약점이다. | 취약점은 일반 SQL 인젝션과 같은 CWE-89입니다. 달라지는 것은 정보가 드러나는 경로뿐입니다. |
| 정보가 한 번에 조금씩만 새므로 위험이 낮다. | 요청을 자동으로 반복할 수 있어 느리다는 점이 실질적인 장벽이 되지 못합니다. 위험 평가에서 일반 SQL 인젝션보다 낮게 볼 근거가 되지 않습니다. |
| 웹 방화벽을 두면 충분하다. | 방화벽은 CWE-89의 완화책 목록에 있지만 운영 단계의 보완 수단입니다. 설계·구현 단계의 매개변수화와 입력 검증을 대신하지 못합니다. |
| 탐지 도구가 찾지 못했으면 취약점이 없다. | 자동 진단은 응답 차이를 판별하는 기준에 의존하므로 놓치는 경우가 있습니다. 논문에서 진단 도구를 평가할 때 탐지율과 함께 오탐·미탐을 보고하는 이유입니다. |
논문에서는 이렇게 쓰입니다
실제 논문에서
이 용어를 직접 쓴 국내 논문 문장을 아직 수집하지 못했습니다. 수집되는 대로 출처와 함께 싣겠습니다.
예시 문장
아래는 용어의 쓰임을 보여 주려고 만든 예시로, 실제 논문에서 가져온 문장이 아닙니다.
불리언 기반 블라인드 SQL 인젝션 탐지 방식을 설명하는 문장입니다.
시간 지연을 이용한 블라인드 SQL 인젝션 공격 방식을 설명하는 문장입니다.
조금 더 깊게 보면
블라인드 SQL 인젝션은 크게 참/거짓 조건에 따라 응답 페이지 내용이 달라지는지를 관찰하는 불리언 기반 방식과, 조건이 참일 때 데이터베이스 함수를 이용해 응답을 의도적으로 지연시키는 시간 기반 방식으로 나뉩니다. 두 방식 모두 한 번에 한 글자씩 또는 한 비트씩 조건을 바꿔가며 반복 질의를 수행하기 때문에, 자동화 스크립트를 이용해 데이터를 순차적으로 복원하는 경우가 일반적입니다.
주의할 점
오류 메시지를 사용자에게 노출하지 않도록 처리했다고 해서 SQL 인젝션 자체가 방어되는 것은 아니며, 근본적인 대응은 매개변수화된 쿼리(prepared statement) 사용과 입력값 검증에 있습니다.
헷갈리기 쉬운 용어
같은 약점에서 나오는 유형과, 이름이 비슷한 다른 주입 계열을 구분합니다.
| 용어 | 무엇을 가리키나 | 블라인드 방식과의 관계 |
|---|---|---|
| SQL 인젝션 | 입력이 SQL 질의의 구조를 바꾸는 약점과 이를 이용한 공격 전체 | 상위 개념 |
| 블라인드 SQL 인젝션 | 결과가 직접 보이지 않을 때 응답의 차이로 정보를 추론하는 유형 | — |
| 내용 기반(불리언 기반) | 참·거짓에 따른 응답 내용의 차이를 단서로 삼음 | 블라인드 방식의 하위 유형 |
| 시간 기반 | 응답 지연 여부를 단서로 삼음 | 블라인드 방식의 하위 유형 |
| 크로스사이트 스크립팅 | 입력이 다른 사용자의 브라우저에서 스크립트로 실행되는 약점 | 주입 계열이지만 대상이 데이터베이스가 아니라 브라우저 |
참고 문헌
- Su, Z., & Wassermann, G. (2006). The essence of command injection attacks in web applications. In Conference Record of the 33rd ACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages, 372–382. ACM.
- Boyd, S. W., & Keromytis, A. D. (2004). SQLrand: Preventing SQL injection attacks. In Applied Cryptography and Network Security (Lecture Notes in Computer Science), 292–302. Springer.
- Halfond, W. G. J., & Orso, A. (2006). Preventing SQL injection attacks using AMNESIA. In Proceedings of the 28th International Conference on Software Engineering, 795–798. ACM.
표의 기준값은 위 문헌에 근거한 관례이며, 분야·학술지마다 다른 기준을 쓸 수 있습니다.