SQLi

쿼리 조작 방식은 SQL 인젝션 공격의 핵심으로, 공격자가 애플리케이션의 데이터베이스 쿼리 구조를 변조하여 의도하지 않은 동작을 유발하는 방법을 의미한다. 주로 사용자 입력 필드, URL 파라미터, HTTP 헤더 등 외부에서 데이터를 받는 부분을 통해 악의적인 SQL 코드를 주입한다. 이 과정에서 애플리케이션이 사용자 입력을 적절히 필터링하거나 이스케이프 처리하지 않고 쿼리 문자열에 직접 결합할 때 취약점이 발생한다.

가장 기본적인 방식은 쿼리 구문 종료 및 재구성이다. 공격자는 원래 쿼리의 조건을 무력화시키기 위해 작은따옴표(')나 큰따옴표(")를 사용해 문자열 리터럴을 조기 종료시킨 후, OR '1'='1'과 같은 항상 참이 되는 조건을 추가한다. 이를 통해 인증 우회나 데이터 무조건 반환 등의 결과를 얻는다. 예를 들어, SELECT * FROM users WHERE id = 'INPUT'이라는 쿼리에서 INPUT 자리에 ' OR '1'='1을 삽입하면, 최종 쿼리는 WHERE id = '' OR '1'='1'이 되어 모든 사용자 레코드를 반환한다.

또 다른 주요 방식은 다중 쿼리 실행이다. 일부 데이터베이스 시스템(예: MySQL, Microsoft SQL Server)은 세미콜론(;)을 구분자로 사용해 단일 요청에 여러 SQL 문을 실행할 수 있다. 공격자는 '; DROP TABLE users; --와 같은 페이로드를 입력해 기존 쿼리 뒤에 데이터 삭제나 수정 등의 추가 명령을 실행할 수 있다. 주석 표시자(-- 또는 #)를 활용하여 원래 쿼리의 나머지 부분을 무시하는 것도 흔한 기법이다.

더 복잡한 조작에는 UNION 기반 공격이 포함된다. UNION 연산자를 이용해 원래 SELECT 문의 결과에 공격자가 원하는 다른 테이블의 데이터를 결합해 반환받는다. 이 기법을 성공시키려면 두 쿼리의 컬럼 수와 데이터 타입이 일치해야 하며, 공격자는 일반적으로 널(NULL) 값을 사용하거나 컬럼 수를 추정하는 과정을 거친다. 예시 페이로드는 ' UNION SELECT username, password FROM members --와 같은 형태를 가진다.

이러한 조작은 데이터 유출, 무결성 훼손, 인증 우회, 심지어 데이터베이스 서버에 대한 원격 코드 실행으로까지 이어질 수 있다. 따라서 애플리케이션은 모든 사용자 입력을 신뢰할 수 없는 데이터로 간주하고 적절한 방어 기법을 적용해야 한다.

공격 벡터는 SQL 인젝션 공격이 애플리케이션에 주입될 수 있는 다양한 입력 경로나 지점을 의미한다. 주로 사용자가 데이터를 입력하거나 조작할 수 있는 모든 웹 애플리케이션 요소가 잠재적 공격 벡터가 된다.

주요 공격 벡터는 다음과 같다.

이러한 벡터를 통해 악의적인 SQL 코드가 애플리케이션의 백엔드 데이터베이스 쿼리와 결합된다. 공격자는 단일 벡터를 대상으로 하거나, 여러 벡터를 조합하여 더 복잡하고 탐지하기 어려운 공격을 수행할 수 있다. 따라서 보안 검증은 모든 외부 입력 소스에 대해 균일하게 적용되어야 한다.

Classic/In-band SQLi는 가장 일반적이고 직관적인 SQL 인젝션 공격 유형이다. 이 공격 방식은 공격자가 악의적인 SQL 쿼리를 삽입하고, 애플리케이션의 응답을 통해 직접 그 결과를 확인할 수 있다는 특징을 지닌다. 공격과 결과 확인이 동일한 통신 채널(인밴드)을 통해 이루어지기 때문에 '인밴드'라는 명칭이 붙었다. 주로 UNION 연산자를 이용한 공격과 오류 기반 공격으로 세분화된다.

UNION 기반 공격은 악의적인 쿼리에 UNION SELECT 구문을 추가하여 원래 쿼리의 결과 집합에 임의의 데이터를 결합시키는 방식이다. 예를 들어, ' UNION SELECT username, password FROM users--와 같은 구문을 삽입하여 데이터베이스의 사용자 자격 증명을 탈취할 수 있다. 이 공격이 성공하기 위해서는 UNION 절 앞뒤의 컬럼 수와 데이터 타입이 일치해야 한다는 전제 조건이 있다.

오류 기반 공격은 의도적으로 잘못된 SQL 구문을 삽입하여 데이터베이스 서버가 반환하는 오류 메시지를 분석하는 방식이다. 오류 메시지에 데이터베이스 구조, 테이블명, 컬럼명 등 민감한 정보가 포함되어 있을 경우, 공격자는 이를 활용해 추가적인 공격을 수행한다. 예를 들어, ' AND 1=CAST(@@version AS INT)--와 같은 구문을 통해 데이터베이스 버전 정보를 유출할 수 있다.

이 유형의 공격은 공격자가 쿼리 결과를 직접 확인할 수 있어 비교적 간단하고 빠르게 데이터를 탈취할 수 있다는 장점이 있다. 따라서 방어 측면에서도 사용자 입력값에 대한 철저한 검증과 준비된 문장 사용이 가장 효과적인 대응책으로 꼽힌다.

Blind SQL 인젝션은 공격자가 데이터베이스로부터 직접적인 결과(예: 데이터베이스 오류 메시지 또는 쿼리 결과)를 확인할 수 없지만, 애플리케이션의 동작 변화(응답 시간 차이, HTTP 상태 코드, 페이지 내용의 미묘한 차이)를 관찰하여 데이터를 추론하거나 탈취하는 공격 기법이다. 데이터베이스 오류 메시지가 사용자에게 노출되지 않는 구성에서도 공격이 가능하다는 점이 특징이다.

주로 두 가지 방식으로 구분된다. 첫 번째는 Boolean-based Blind SQLi이다. 공격자는 데이터베이스에 참(TRUE) 또는 거짓(FALSE) 조건을 주입하고, 애플리케이션의 HTTP 응답이 조건에 따라 어떻게 달라지는지 관찰한다. 예를 들어, ' AND (SELECT SUBSTRING(password,1,1) FROM users WHERE id=1)='a'-- 와 같은 쿼리를 주입하여 첫 번째 문자가 'a'인지 확인하고, 페이지 응답의 미묘한 차이(예: "로그인 실패" 메시지 유무)를 통해 한 글자씩 데이터를 추론한다.

두 번째는 Time-based Blind SQLi이다. 이 방식은 데이터베이스에 지연 함수를 주입하여 응답 시간의 차이를 통해 정보를 유추한다. 조건이 참일 때만 특정 시간(예: 10초) 동안 대기하도록 쿼리를 구성한다. MySQL의 경우 SLEEP(10) 함수를, PostgreSQL은 pg_sleep(10)을 사용한다. 공격 구문은 '; IF (SELECT COUNT(*) FROM admin_users) > 0 WAITFOR DELAY '0:0:10'-- 과 같다. 응답이 10초 후에 도착하면 조건이 참임을 의미하므로, 이를 반복하여 데이터를 추출한다.

이 공격 방식은 매우 느리고 수많은 요청이 필요하지만, 자동화된 도구를 이용해 실행된다. 방어 측면에서는 준비된 문장(Prepared Statements) 사용이 가장 효과적이며, 오류 메시지를 외부에 노출하지 않고, 예상치 못한 지연 함수 호출을 모니터링하는 것이 중요하다.

Out-of-band SQLi(Out-of-band SQL injection)는 공격자가 SQL 쿼리 결과를 직접 응답으로 받지 못하는 상황에서, 데이터베이스 서버가 외부 네트워크 채널을 통해 정보를 전송하도록 유도하는 공격 기법이다. 이 방식은 Blind SQLi와 마찬가지로 쿼리 결과가 애플리케이션 화면에 직접 표시되지 않거나 오류 메시지가 억제된 환경에서 유용하게 활용된다. 공격 성공 여부나 추출한 데이터는 DNS 조회나 HTTP 요청과 같은 대역 외(Out-of-band) 통신을 통해 확인한다.

공격은 일반적으로 데이터베이스 서버의 특정 함수를 활용하여 실행된다. 공격자는 악의적인 SQL 쿼리에 데이터베이스가 외부 도메인으로 DNS 조회나 HTTP 요청을 보내는 함수를 삽입한다. 이 요청에는 데이터베이스에서 추출한 민감한 데이터가 포함된다. 예를 들어, LOAD_FILE()[2], UTL_HTTP.request()[3], 또는 xp_dirtree[4]와 같은 함수를 사용하여 공격자가 통제하는 서버로 데이터를 유출시킬 수 있다.

이 공격 기법의 성공 여부는 데이터베이스 서버의 구성에 크게 의존한다. 데이터베이스 서버가 외부 네트워크에 대한 아웃바운드 연결(예: DNS, HTTP, SMB)을 허용해야 하며, 필요한 함수를 실행할 권한이 있어야 한다. 방어 측면에서는 데이터베이스 서버의 불필요한 외부 네트워크 접근을 차단하고, 위험한 시스템 함수 및 확장 저장 프로시저의 실행 권한을 철저히 제한하는 것이 핵심적인 완화 조치가 된다.

수동 테스트 기법은 SQL 인젝션 취약점을 발견하기 위해 테스터가 직접 다양한 입력을 시도하고 응답을 분석하는 과정을 말한다. 자동화 도구에 의존하기 전에 초기 탐지나 도구가 놓칠 수 있는 복잡한 취약점을 찾는 데 유용하다. 일반적으로 쿼리 조작 방식을 이해하고, 애플리케이션의 입력 지점을 식별한 후 체계적으로 테스트를 진행한다.

가장 기본적인 방법은 단일 따옴표(')나 쌍따옴표(")와 같은 메타 문자를 입력 필드에 삽입하여 오류 메시지를 유발하는 것이다. 예를 들어, '를 입력했을 때 데이터베이스 오류(예: You have an error in your SQL syntax)가 화면에 노출되면 해당 지점에 취약점이 존재할 가능성이 높다. 논리적 테스트도 자주 사용되며, ' OR '1'='1과 같은 항상 참(TRUE)이 되는 조건을 주입하여 로그인 우회나 데이터 필터링을 우회하려 시도한다.

더 정교한 테스트를 위해 Blind SQLi를 의심할 수 있는 상황에서는 조건부 응답을 관찰한다. 쿼리의 참/거짓 결과가 애플리케이션의 응답 시간이나 화면에 미묘한 차이로 나타나는지 확인한다. 시간 지연 함수를 활용한 테스트는 이때 중요한 지표가 된다. 예를 들어, ' AND SLEEP(5)-- 와 같은 페이로드를 주입했을 때 서버 응답이 5초 정도 지연되면 취약점이 존재할 수 있다.

수동 테스트 시 고려해야 할 주요 입력 지점과 테스트 케이스는 다음과 같다.

테스트 과정에서 얻은 오류 메시지는 데이터베이스 종류(예: MySQL, Microsoft SQL Server, Oracle)를 판단하는 데 결정적인 단서를 제공한다. 모든 테스트는 개발 또는 테스트 환경에서 사전 허가를 받은 후 수행해야 하며, 무단 테스트는 법적 문제를 일으킬 수 있다.

자동화 도구는 SQL 인젝션 취약점을 체계적이고 효율적으로 탐지하기 위해 널리 활용된다. 수동 테스트만으로는 놓치기 쉬운 복잡한 취약점이나 대규모 애플리케이션의 광범위한 테스트에 특히 유용하다. 이러한 도구는 일반적으로 사전 정의된 공격 패턴(페이로드) 데이터베이스를 기반으로 하여, 다양한 입력 지점에 자동으로 테스트 요청을 전송하고 응답을 분석하여 취약점을 식별한다.

주요 자동화 도구는 다음과 같은 범주로 나눌 수 있다.

자동화 도구를 활용할 때는 주의가 필요하다. 과도한 공격 요청은 대상 서비스에 부하를 줄 수 있으며, 테스트 환경이 아닌 실제 운영 환경에서의 사용은 데이터 손상이나 서비스 중단을 초래할 수 있다. 또한, 도구가 모든 유형의 Blind SQLi나 복잡한 논리적 결함을 완벽하게 찾아내지 못할 수 있으므로, 수동 테스트와 병행하는 것이 권장된다. 효과적인 활용을 위해서는 도구가 생성하는 페이로드와 공격 기법을 이해하고, 보고된 결과를 정확히 해석하여 위험도를 평가하는 것이 중요하다.

[5]

준비된 문장은 SQL 인젝션 공격을 방어하는 가장 효과적이고 권장되는 방법 중 하나이다. 이 기법은 SQL 쿼리의 구조를 사전에 정의(준비)하고, 사용자 입력을 나중에 별도의 매개변수로 전달하는 방식을 사용한다. 이로 인해 쿼리 로직(구조)과 데이터(입력값)가 명확하게 분리되어, 악의적인 입력이 쿼리 명령어로 해석되는 것을 근본적으로 차단한다.

동작 원리는 크게 두 단계로 나뉜다. 첫 번째 단계에서 애플리케이션은 데이터베이스에 쿼리의 골격(템플릿)을 전송한다. 이 템플릿에는 사용자 입력이 들어갈 자리를 플레이스홀더(예: ? 또는 :name)로 표시한다. 데이터베이스는 이 템플릿을 구문 분석하고 최적화하여 실행 계획을 수립한다. 두 번째 단계에서 애플리케이션은 실제 사용자 입력값을 매개변수로 플레이스홀더에 바인딩한다. 이때 데이터베이스는 바인딩된 값을 오직 '데이터'로만 처리하며, 이미 컴파일된 쿼리 구조를 변경할 수 없다.

주요 프로그래밍 언어와 데이터베이스 인터페이스는 준비된 문장을 지원하는 API를 제공한다. 아래는 일반적인 사용 방식을 보여주는 표이다.

준비된 문장을 사용하면, 공격자가 userInput 자리에 1 OR 1=1과 같은 값을 입력하더라도 이는 전체 문자열로 취급되어 id 필드의 값과 비교 대상이 된다. 결과적으로 id = '1 OR 1=1'인 사용자를 찾게 되어 공격이 성립하지 않는다. 이 기법은 입력값 검증이나 이스케이프 처리만으로는 놓치기 쉬운 복잡한 공격을 방어하는 데 매우 유용하다. 모든 데이터베이스 쿼리, 특히 사용자 입력이 포함되는 부분에 준비된 문장을 일관되게 적용하는 것이 보안 강화의 핵심이다.

입력값 검증은 사용자로부터 받은 모든 데이터가 애플리케이션에서 기대하는 형식, 길이, 타입 및 범위를 따르는지 확인하는 과정이다. 검증은 가능한 한 서버 측에서 수행되어야 하며, 클라이언트 측 검증만으로는 충분하지 않다. 허용 목록 방식을 사용하는 것이 안전한데, 이는 허용된 문자나 패턴만을 통과시키고 나머지는 모두 거부하는 방식이다. 검증은 비즈니스 로직에 맞춰 수행되어야 하며, 예를 들어 이메일 주소 필드에는 이메일 형식 검증을, 숫자 ID 필드에는 숫자만 허용하는 검증을 적용한다.

입력값 이스케이프는 사용자 입력에 포함될 수 있는 특수 문자를 안전한 형태로 변환하여 데이터베이스 쿼리의 일부로 해석되지 않도록 하는 기법이다. 예를 들어, 작은따옴표(')를 데이터베이스에서 문자열의 끝으로 해석하지 않고 일반 문자로 처리하도록 \'와 같이 변환한다. 이스케이프 처리는 사용되는 데이터베이스 관리 시스템(DBMS)과 연결 라이브러리에 따라 구체적인 규칙이 다르므로, 해당 환경에 맞는 공식 함수(예: PHP의 mysqli_real_escape_string())를 사용하는 것이 중요하다.

그러나 입력값 이스케이프는 준비된 문장(Prepared Statements)에 비해 2차 방어선으로 간주된다. 이스케이프 로직에 오류가 있거나 특정 컨텍스트(예: 식별자, ORDER BY 절)에서 적용되지 않으면 우회당할 수 있기 때문이다. 따라서 최선의 방어 전략은 준비된 문장을 1차 방어 수단으로 사용하고, 입력값 검증을 보조 수단으로 활용하며, 필요에 따라 이스케이프를 추가적으로 적용하는 다층 방어를 구축하는 것이다.

데이터베이스 계정에 과도한 권한을 부여하는 것은 SQL 인젝션 공격이 성공했을 때 그 피해 범위를 크게 확장시킨다. 따라서 애플리케이션은 필요한 최소한의 권한만을 가진 데이터베이스 사용자 계정을 사용해야 한다. 예를 들어, 특정 웹 애플리케이션 모듈이 오직 데이터 조회(SELECT)만 수행한다면, 해당 모듈이 사용하는 데이터베이스 연결 계정에는 SELECT 권한만 부여하고, 데이터 변경(DROP, INSERT, UPDATE, DELETE)이나 시스템 명령 실행(xp_cmdshell) 등의 권한은 제거해야 한다.

권한 분리는 데이터베이스 스키마 수준에서도 적용될 수 있다. 서로 다른 기능을 가진 애플리케이션 모듈마다 별도의 데이터베이스 사용자 계정과 스키마를 사용하도록 구성하면, 한 모듈에서 발생한 침해 사고가 전체 시스템으로 전파되는 것을 차단할 수 있다. 또한, 운영체제 수준에서 데이터베이스 서버 프로세스가 실행되는 계정의 권한도 최소화해야 한다.

다음은 일반적인 애플리케이션 기능과 권한을 매핑한 예시이다.

이러한 접근 방식은 공격자가 SQL 인젝션을 통해 획득한 데이터베이스 세션의 능력을 근본적으로 제한한다. 비록 인젝션 자체를 완전히 차단하지 못하더라도, 데이터 유출 규모를 줄이거나 시스템 파괴, 권한 상승과 같은 2차 피해를 방지하는 데 핵심적인 역할을 한다. 이 원칙은 OWASP의 보안 권고사항과 여러 정보보호 관리체계 표준에서도 강조되는 기본적인 보안 설계 요소이다.