SQL Injection

Injection은 OWASP에서도 지속적으로 거론되는 공격수법이다.

• OWASP (The Open Web Application Security Project) : 오픈소스 웹 어플리케이션 보안 프로젝트

1. What is 'Injection' ?

• Injection : 명령 코드 삽입

Injection은 (“inject" : "주사하다, 주입하다”) 그 어휘에서 알 수 있듯이 명령 코드 삽입 취약점을 의미한다. 명령 삽입 취약점, 즉 명령 삽입 공격은 서버가 클라이언트의 입력값을 잘 필터링하지 못할 때 발생한다.

• 파라미터(parameter 매개변수, 인수) : 변수의 특별한 한 종류로서, 함수 등과 같은 서브루틴의 인풋으로 제공되는 여러 데이터 중 하나를 가리키기 위해 사용된다.

클라이언트는 서버에 무언갈 요청할 때 인수값을 보내기도 하는데 대표적인 인수(parameter)로 아이디와 패스워드가 있다. 이와 같은 클라이언트의 요청을 처리하기 위해 전송받는 인수(parameter)에 특정명령을 실행할 수 있는 코드가 포함되는 경우가 Injection이다. 시스템을 직접적으로 조작하지는 않지만 시스템 상의 결함을 이용한 공격이고 따라서 쉬운 난이도에 비해 파급력이 크다는 특징이 있다.

2. Injection 공격에 가장 많이 쓰이는 언어, SQL

• SQL(Structured Query Language) : 구조화된 질의어로 데이터베이스 언어의 일종

그래서 SQL이 무엇이냐? SQL은 Structured Query Language의 약어로 구조화된 질의어이다. 이 질의어는 데이터베이스와 대화하기 위한 수단인데 데이터베이스란 쉽게 데이터의 모임(공유하기 위한)이다. 우리가 데이터를 저장하는 곳이라고 이해하면 된다.

CF> 알다시피 대부분의 웹서버는 데이터베이스와 연동되어서 운영된다.

CF> SQL은 우리가 흔히 쓰는 엑셀 시트와 매우 비슷하다. 엑셀 시트를 살펴보면 행과 열이 있고 그 안에 데이터가 있듯이 SQL도 엑셀 시트와 대응하여 테이블이라는 것이 있고 테이블 역시 행과 열로 이루어져 있으며 그 안에 데이터가 있다.

3. Client-Server 모델에 비추어본 SQL Injection

우선 URL을 통해 페이지를 요청하면 이에 응하여 서버는 HTML 파일을 보내준다. 이후 요청한 웹페이지가 활성화되고 다시 해당 웹페이지를 통해서 대화형으로 요청과 응답이 이어진다.

이 과정에서 서버는 데이터베이스를 참조하게 되는데 이때 CGI(common gateway interface)가 서버와 응용프로그램 사이에 데이터를 주고받기위한 표준 방법으로 쓰인다. 그리고 이 CGI를 통해 데이터베이스를 참조할 때 비로소 SQL문이 사용되는 것이다.

• CGI(common gateway interface) : 공용 게이트웨이 인터페이스. 웹 서버 상에서 사용자 프로그램을 동작시키기 위한 조합이다. 존재하는 많은 웹 서버 프로그램은 CGI의 기능을 이용할 수 있다. 웹 서버 프로그램의 기능의 주체는 미리 준비된 정보를 이용자(클라이언트)의 요구에 응답해 보내는 것이다. 그 때문에 서버 프로그램 그룹에서는 정보를 그 장소에서 동적으로 생성하고 클라이언트에 송신하려하는 조합을 작성하는 것이 불가능했다. 서버 프로그램에서 다른 프로그램을 불러내고, 그 처리 결과를 클라이언트에 송신하는 방법이 고안되었다. 이를 실현하기 위한 서버 프로그램과 외부 프로그램과의 연계법을 정한 것이 CGI이다.

4. 공격 시나리오

다음은 공격시나리오를 살펴보자.
(이해를 위해 작성한 예시지 실제 공격시 이렇게 허술하게 뚫리지 않는다)

데이터베이스 속 테이블에 유저의 정보(아이디, 패스워드)가 다음과 같이 저장되어 있다고 가정할 때 정상적인 로그인 상황에서는 클라이언트가 정확한 입력값을 받아 그것을 아이디 패스워드라는 인수에다 담아 서버에 보내게 되고 웹서버는 전달받은 인수가 실제 데이터베이스에 존재하는지 SQL을 통해 물어보게 된다.
(CF> 여기서 SELECT은 검색을 의미하고 WHERE은 조건을 의미한다.
-> User 테이블에서 검색을 한다는 의미고 조건은 입력된 아이디와 패스워드가 동시에 일치해야 한다.)

해당 값들이 유저 테이블에 있다는 것이 확인되면 결과값이 송출되고 웹서버는 로그인 이후의 페이지를 클라이언트에게 응답하게 된다.

여기서 핵심은 어떤 수단을 쓰든 SQL의 결과 값에 NULL이 나오지 않고 출력 값이 나오게 하면 로그인에 성공할 수 있다는 것이다.

다음은 비정상적으로 로그인에 성공하는 경우다. 사진을 보면 아이디는 같으나 패스워드를 다르게 입력한 것을 확인할 수 있다. 하지만 입력한 패스워드의 경우 파란색 부분이 무조건 참이고 OR 연산자와 합쳐져서 NULL이 아닌 결과값을 도출하기 때문에 서버는 아무런 의심 없이 로그인 이후의 페이지를 클라이언트에게 제공하게 되는 것이다.
-> 패스워드로 'or''='를 입력하면 입력값이 따옴표로 감싸져서 ''or''=''이 되기 때문에 구문상 참이 되는 것이다!

5. 원인 및 대응방법

인젝션 공격의 발생 원인은 서버에서 클라이언트의 입력값을 적절하게 필터링 하지 못했기 때문이다. 따라서 대응방안은 입력값을 필터링하면 된다. 구체적인 방법으로는 아래 세 가지 정도가 있다.

• 프리페어드 스테이트먼트(prepared statement) : 파라미터라이즈드 스테이트먼트(parameterized statement)라고도 하며 데이터베이스 관리 시스템(DBMS)에서 동일하거나 비슷한 데이터베이스 문을 높은 효율성으로 반복적으로 실행하기 위해 사용되는 기능이다. 일반적으로 쿼리나 업데이트와 같은 SQL 문과 함께 사용되는 프리페어드 스테이트먼트는 템플릿의 형태를 취하며, 그 템플릿 안으로 특정한 상수값이 매 실행 때마다 대체된다.

• Complete Mediation(완전 매개) : 시스템에 대한 모든 접근은 접근제어방식(Access Control Mechanism)을 거쳐야 함을 의미하는 보안 설계 원칙이다.

첫 번째는 escape 함수 및 prepared statement를 사용한다. escape 함수는 특수 문자열(따옴표 등등)을 이스케이프하기위해 사용하며 이를 통해 서버에 요청 수행시 안전하게 질의할 수 있도록 한다. prepared statement는 반복되는 질의문에 대해서 질의문 구조를 템플릿처럼 정형화하고 그것에 들어갈 인자값(파라미터)만 따로 받는다. 즉, ‘준비된 서술’로서 SQL 쿼리를 사전에 ‘컴파일’한 뒤 변수만 따로 집어넣어 실행하는 것이다. 두 가지 모두 입력값을 직접적으로 전달하지 않고 그 전에 나름 검증 및 필터링을 걸친다는 점에서 안전한 시스템 설계 중 완벽한 조정(Complete Mediation)과 관련있다.

• 최소권한의 원칙(Least Privilege) : 사람과 시스템 모두 해야 할 일을 하는데 필요한 최소한의 권한만 승인해야한다는 시스템 설계 원칙

두 번째는 데이터베이스로 질의시 유저별로 접근 권한과 사용 가능한 명령어를 제한한다. 즉 필요한 만큼의 권한만 부여한다는 점에서 안전한 시스템 설계 중 최소한의 권한과 관련있다.

• 권한분리(Separation of Privilege) : 시스템은 단일 조건에 따라 권한을 부여해서는 안 된다는 시스템 설계 원칙

세 번째는 이중필터 사용이다. 일전에 대응방법으로 필터링을 강조했는데 서버뿐만 아니라 클라이언트 쪽에서도 필터링을 걸쳐서 이중 필터링을 하는 것이다. 접근과정에서 한 가지 이상의 조건을 따진다는 점에서 안전한 시스템 설계 중 권한 분리와 관련지을 수 있다.

• 클라이언트 측 -> 클라이언트 측의 입력을 받을 웹 사이트에서 자바스크립트로 폼 입력값을 한 번 검증 (이때의 폼 검증은 사용자에게 인젝션에 필요한 특수문자의 사용이 불가능하다고 알리는 용도.)
• 서버 측 -> 서버 측은 클라이언트 측의 자바스크립트 필터가 없다고 가정하고 한번 더 입력값을 필터.