'오래됐지만 여전히 효과적'··· SQL 인젝션 공격의 개념과 방어방법

SQL 인젝션(SQL injection), 줄여서 SQLi는 공격자가 웹 애플리케이션 데이터베이스를 장악할 수 있는 가장 원시적인 형태의 웹 애플리케이션 보안 공격이다. XKCD 327의 만화 <Little Bobby Drop Tables>로 잘 알려진 SQLi는 1998년 처음 발견됐지만 지금까지도 인터넷 전역에서 웹 애플리케이션을 괴롭히고 있다. 심지어 OWASP는 상위 10가지 웹 애플리케이션 보안 위협 목록에서 인젝션을 최상위 위협으로 선정했다.

좋은 소식이라면, SQL 인젝션이 공격자뿐만 아니라 방어자에게도 가장 다루기 쉬운 공격 수법이라는 점이다. SQLi는 NSA 섀도우 브로커(Shadow Brokers) 키트와 같은 첨단을 달리는 공격이 아니다. 너무 간단해 3살짜리 아이도 할 수 있을 정도다. 또한 웹 애플리케이션을 고쳐 SQLi의 위험을 완화하는 방법도 너무 쉬워서 이걸 못했다면 심각한 태만 외의 다른 이유를 찾기 어렵다.



SQL 인젝션의 정의와 유형
SQL 인젝션에는 여러 가지 유형이 있지만 공통점은 공격자가 애플리케이션 데이터베이스 쿼리에 임의의 SQL을 삽입한다는 것이다. 가장 간단한 SQL 인젝션은 사용자 입력을 통하는 방법이다. 일반적으로 웹 애플리케이션은 양식을 통해 사용자 입력을 받고, 프론트 엔드는 해당 사용자 입력을 처리하기 위해 백 엔드 데이터베이스에 전달한다. 웹 애플리케이션이 사용자 입력을 무결 처리(sanitize)하지 못할 경우, 공격자는 원하는 SQL을 백 엔드 데이터베이스에 삽입해 데이터베이스 내용을 삭제, 복사하거나 수정할 수 있다.

또한 공격자는 쿠키를 수정해 웹 애플리케이션의 데이터베이스 쿼리를 오염시킬 수 있다. 쿠키는 클라이언트 상태 정보를 로컬에 저장하며, 웹 애플리케이션은 일반적으로 쿠키를 로드해 이 정보를 처리한다. 악의적 사용자 또는 악성코드는 쿠키를 수정해 백 엔드 데이터베이스에 SQL을 삽입할 수 있다.

HTTP 헤더와 같은 서버 변수도 SQL 인젝션 공격 벡터로 사용될 수 있다. 웹 애플리케이션이 이런 입력을 무결 처리하지 못할 경우, 임의 SQL이 포함된 위조된 헤더가 데이터베이스에 이 코드를 삽입할 수 있다.

2차 SQL 인젝션 공격은 즉시 실행되지 않고 훨씬 더 나중에 실행된다는 측면에서 SQL 인젝션 공격 중에서 가장 교활한 수법이다. 개발자가 즉각적인 공격에 대비해 모든 입력을 올바르게 무결 처리한다 해도 오염된 데이터가 다른 컨텍스트에서 사용되는 경우 2차 SQLi에 당할 수 있다.

SQL 인젝션은 어떻게 이뤄지는가
SQL 인젝션은 오래된 수법이다. 현재 SQLi를 사용해 공격하는 사람들 중에서는 SQL 인젝션보다 나중에 태어난 사람이 많다. SQLi 공격은 기초적이며 오래 전부터 자동화됐다. SQL닌자(SQLninja), SQL맵(SQLmap) 및 하비즈(Havij)과 같은 툴은 웹 애플리케이션을 손쉽게 테스트할 수 있게 해주지만 동시에 공격도 쉽게 해준다.

10년 전 SQLi 웜이 인터넷을 강타했을 때와 크게 바뀐 것이 없다. SQL 인젝션 문제에 대한 인식은 널리 퍼졌지만 웹 애플리케이션의 상당수는 여전히 취약한 상태다.

자동화된 테스트 툴을 사용하면 쉬운 먹이감을 찾는 공격자보다 한걸음 앞서 나갈 수 있다. SQL맵과 같은 툴로 웹 애플리케이션에서 침투 테스트를 하면 공격 방지책이 충분한지 여부를 빠르게 확인할 수 있다. SQL맵은 현재 사용되는 거의 모든 주요 데이터베이스를 지원하며 알려진 SQL 인젝션 취약점 대부분을 탐지, 익스플로잇할 수 있다.

입력을 무결 처리하되 테스트를 통해 공격 방지책이 성공적으로 작동하는지 여부를 확인해야 한다. 블루 팀과 레드 팀으로 나누어 테스트하는 것이 효과적이다.

SQL 인젝션 공격의 예
기본적인 SQL 인젝션 공격을 보자. 예를 들어 고객이 ID를 입력해 자신의 고객 프로필을 불러올 수 있는 웹 애플리케이션이 있다. 이 웹 애플리케이션의 프론트 엔드는 사용자가 입력한 고객 ID를 백 엔드 데이터베이스로 전달한다. 데이터베이스는 SQL 쿼리를 실행하고 결과를 웹 애플리케이션에 반환한다. 웹 애플리케이션은 최종 사용자에게 결과를 표시한다.

백 엔드 데이터베이스 쿼리는 아마 다음과 같은 형태일 것이다.

SELECT *
FROM customers
WHERE customer_id = '1234567'

사용자가 웹 양식 필드에 다음과 같은 customer_id를 입력했다고 가정해 보자.

1234567; DELETE * customers WHERE '1' = '1

이후 백 엔드 데이터베이스는 다음 SQL을 순순히 실행한다.

SELECT *
FROM customers
WHERE customer_id = '1234567';
DELETE *
FROM customers
WHERE 'x' = 'x'

여러 SQL 문이 세미콜론으로 구분된 경우 데이터베이스는 이런 SQL 문을 아무런 의심 없이 연속으로 실행한다는 점을 유의해야 한다. 홑 따옴표 "'" 문자에 대한 사용자 입력을 무결 처리하지 못하는 경우 공격자가 전체 테이블을 삭제하는 것이 가능해진다. 이렇게 되면 백업이 있기를 바라는 수밖에 없다.

앞에서 설명한 것은 아주 간단히 살펴본 예제다. 다양한 SQL 인젝션 공격 벡터가 존재하지만 그 작동 방식은 동일하다. 웹 애플리케이션에서 입력 무결 처리에 실패하고 이것이 원격 SQL 코드 실행으로 이어진다는 것이다.

SQL 인젝션을 탐지할 수 있는가
SQL 인젝션 공격을 완화하기는 어렵지 않지만 아무리 똑똑하고 꼼꼼한 개발자라도 실수를 저지르는 법이다. 따라서 탐지는 SQL 인젝션 공격의 위험을 완화하기 위한 중요한 구성 요소다. 웹 애플리케이션 방화벽(WAF)은 기본적인 SQL 인젝션 공격을 탐지하고 차단할 수 있지만 이를 유일한 방어책으로 사용해서는 안 된다.

네트워크 기반 혹은 호스트 기반의 침입 탐지 시스템(Intrusion Detection Systems, IDS)을 튜닝해 SQL 인젝션 공격을 탐지할 수 있다. 네트워크 기반 IDS는 데이터베이스 서버의 모든 연결을 모니터링하고 의심스러운 활동에 플래그를 지정할 수 있다. 호스트 기반 IDS는 웹 서버 로그를 모니터링하고 특이 사항이 발생하면 경고할 수 있다.

그러나 궁극적으로 SQL 인젝션 공격은 잘 알려져 있고 손쉽게 차단이 가능하며, 위험 완화의 초점은 SQL 인젝션 공격이 발생하지 않도록 사전에 차단하는 데 둬야 한다.

SQL 인젝션을 차단하는 방법
앞서 언급한 만화 <Little Bobby Tables>의 교훈에 따라 데이터베이스 입력을 무결 처리하라. 엡 애플리케이션 데이터베이스로 들어가는 모든 입력은 신뢰할 수 없는 것으로 간주하고 취급해야 한다. 또한 "코드에서 SQL 인젝션 취약점을 피하기는 매우 쉽다. 따라서 많은 SQL 인젝션 공격이 성공하고 있다는 것은 부끄러운 일"이라는 OWASP의 충고를 새겨 들어야 한다.

OWASP SQL 인젝션 참조 문서는 이번 기사에서 다루기 어려운 더 깊이 있는 내용을 다룬다. OWASP에 따르면, SQL 인젝션 공격 차단을 위해서는 개발자가 입력 유효성 검사를 화이트리스팅해(블랙리스팅이 아님) 매개 변수화된 쿼리가 있는 준비된 문을 사용하고 모든 사용자 입력을 이스케이프해야 한다.

또한 계정 권한을 제한하라. 침해가 발생한다고 전제해야 한다. 개발자가 사용자 입력 필드 하나를 무결 처리하지 못하면 어떻게 될까. 이런 일은 늘 발생한다. 개발자도 인간이기 때문이다. 입력을 무결 처리하되 깜박 놓치는 부분이 있음을 전제하라. 데이터베이스 사용자의 계정 권한을 제한하라. 예를 들어 웹 애플리케이션이 읽기 전용인가? DROP TABLES 권한이 필요한가? 필요없는 경우가 많다. 최소 권한 원칙은 여기에도 적용된다. 웹 애플리케이션 실행에 필요한 최소한의 권한만 부여하라.

저장 프로시저도 SQLi를 훨씬 더 어렵게 만들 수 있다(불가능하게는 못하지만). 웹 애플리케이션에서 소수의 SQL 쿼리만 실행한다면 이런 쿼리를 실행하는 저장 프로시저를 만든다. 일반적으로 저장 프로시저를 만들거나 수정할 권한은 데이터베이스 관리자만 소유한다. 다만 많은 데이터베이스가 기본 저장 프로시저를 포함한 상태로 출하되고 공격자도 이를 알고 있다는 점을 유의해야 한다. 반드시 필요한 경우가 아니라면 기본 저장 프로시저를 제거하는 것이 좋다.

SQL 인젝션 차단, 보안에서의 최소한의 주의
SQL 인젝션 차단은 가장 쉬운 웹 애플리케이션 보안이다. SQL 인젝션은 잘 알려진 공격 벡터이고 서툰 공격자도 손쉽게 익스플로잇할 수 있다. 그러나 약간의 주의만 기울이면 간단히 무력화할 수 있다. 2018년에도 SQL 인젝션에 취약한 웹 애플리케이션이 있다면 더 이상 변명의 여지는 없다. SQL 인젝션 차단은 웹 애플리케이션 보안에서 최소한의 주의임을 명심하자. editor@itworld.co.kr