[DVWA] SQL Injection (WHERE 구문 우회 - 전체 데이터 조회)

Vulnerability: SQL Injection

쿼리문의 구조를 파악하고, SQL Injection을 이용하여 전체 데이터를 조회(출력)해보는 것을 목적으로 한다.

DVWA SQL Injection 실습

실습 환경
- Windows Docker를 이용한 DVWA
- Windows 환경의 Burp Suite

Security Level: Low

Low 레벨의 경우, User ID에 해당하는 파라미터를 직접 입력하는 것이 가능하다.

위의 User ID에는 1~5의 숫자에 대한 값이 존재한다. 각각의 입력에 대한 결과는 다음과 같다.

위의 결과 값을 정리해보면 다음과 같다.

ID: 1 - First name: admin / Surname: admin
ID: 2 - First name: Gordon / Surname: Brown
ID: 3 - First name: Hack / Surname: Me
ID: 4 - First name: Pablo / Surname: Picasso
ID: 5 - First name: Bob / Surname: Smith

 

Query 예상

입력 파라미터(parameter)는 user ID 이고, 그에 해당하는 First name과  Sun name을 반환해주고 있다.

SELECT First_name, Sun_name FROM ~~~ WHERE UserID = '_____' ;

실제 Query

$query  = "SELECT first_name, last_name FROM users WHERE user_id = '$id';";

쿼리 상으로 user_id에 해당하는 파라미터는 '___' 사이에 들어갈 것이기 때문에, user_id' or 참인 값을 대입하는 경우, 항상 참인 값이 되기 때문에 모든 user 정보를 얻을 수 있을 것이라고 생각하고 이를 확인해본다.

1' or 1=1 # / 1' or '1'='1

(가능하면 주석은 사용하지 않는 것이 좋다.)

위와 같이 1~5의 전체 데이터가 조회되는 것을 확인할 수 있다.

WHERE id = '____' ; 과 같은 Query 의 빈칸에 1' or '1'='1를 입력하는 경우 다음과 같다.

WHERE id = '1' or '1'='1';

위와 같은 경우 WHERE 조건이 항상 참이 되기 때문에 모든 사용자의 정보가 출력되는 것이다.

 

생각해볼 점

하나의 값을 입력하여서, 전체 데이터가 조회되는 것은 이미 SQL Injection이 가능하다는 증빙이 된다.
사용자의 입력 값이 전달되는 경로는 웹 브라우저(Web Browser) -> 웹 애플리케이션(Web Application) -> DB 서버(SQL Parser, SQL 분석기)로 추정이 가능할 것이다.

공격자가 삽입한 SQL 구문이 해석되었다면 SQL Parser에서 or 연산자와, 주석(#) 따위를 처리한 것이기 때문에 SQL Injection 취약점이 있다는 것을 확인할 수 있다.

좀 더 자세한 확인을 위해서는 and 연산자를 이용하여 참(true) / 거짓(false) 값을 각각 확인해볼 수 있다.
1' or 1=1 # (전체 데이터 조회)
1' or 1=2 # (1 과 같은 결과)
1' and 1=1 # (1과 같은 결과)
1 ' and 1=2 # (결과 없음)
과 같이 or / and 연산자에 대한 참/거짓 값에 의하여 출력 값에 변화가 있는 것을 관찰할 수 있다.

---

Security Level: Medium

Medium 레벨의 경우, 다음과 같이 콤보 박스(Combo Box)에 1~5의 값이 존재한다.

위의 콤보 박스 부분은 다음과 같이 이루어져 있다.

해당 콤보 박스의 경우, 사용자는 직접 값을 입력할 수 없고, 목록에 존재하는 1~5에 대해서만 값을 선택할 수 있다.

하지만 Burp Suite로 확인해보면 해당 값에 대한 파라미터 값이 존재하기 때문에 이를 변조하여 다른 값을 삽입할 수 있다.

id=1~5&Submit=Submit

위와 같이 기본적으로는 id 파라미터에 콤보박스에 존재하는 1~5가 입력되지만, 이것을 변조하여 요청하면 다음과 같다.

id=1+or+1=1# / id=1+or+1=1

(가능하면 주석은 사용하지 않는 것이 좋다.)

위와 같이 id 파라미터를 변조하여 요청하는 경우 모든 user 정보가 출력되는 것을 확인할 수 있다.

실제 쿼리를 살펴보면 위와 같은데, mysqli_real_escape_string을 이용하여 NUL (ASCII 0), \n, \r, \, ', ",  CTRL+Z. 와 같은 값을 막는다. 콤보 박스로 값을 받고 있기 때문에 해당 값은 숫자 값으로 받아지기 때문에 ' 와 " 등을 막는 역할을 하는 것으로 보여진다. 하지만 위와 같이 데이터를 전체 조회하는 데에는 문제가 없었다.

---

Security Level: High

High 레벨의 경우, 팝업창을 통해 입력을 받는다.

here to change your ID. 를 누르면 다음과 같은 팝업 창이 나온다.

// Get input
$id = $_SESSION[ 'id' ];

// Check database
$query = "SELECT first_name, last_name FROM users WHERE user_id = '$id' LIMIT 1;";

SQL문에서 사용할 id 값을 서버의 세션(session)으로부터 읽어서 사용하기 때문에 온전하게 안전한 방법이라고 할 수 있다. 실질적으로 사용자가 서버에 저장된 세션 내의 값을 조작할 방법이 없기 때문이다.

하지만 해당 문제의 경우 서버의 세션에 저장되는 값을 사용자가 변경할 수 있는 아래와 같은 웹 애플리케이션을 제공한다. 

이것은 비현실적인 상황을 가정한 것으로 보아도 무방하다고 할 수 있다. 일반적으로 세션은 서버가 자동으로 만드는 것으로, 로그인을 하는 과정에서 검증된 값(ID, 권한)을 저장한다. 이러한 값은 서버에 저장되는 값으로서 사용자가 관여할 수 있는 경우는 거의 없다고 볼 수 있다.

위의 입력 창에 대하여 살펴보면 다음과 같다.

해당 입력창을 통해 입력하면 해당 입력값이 입력창에 나타나고, 해당 값이 전달된다.

우선 이전 레벨에서 시도해봤던 값을 입력해본다.

1' or '1'='1

위와 같이 입력한 결과를 보면, 다음과 같은 결과가 나온다.

이전의 레벨과 쿼리문이 같다고 가정한다면, 전체 데이터가 조회되어야 한다. 하지만 High 레벨의 경우, 한 줄만 출력되었다. 그렇다면 이것은 반환되는 행 수를 제한했다고 볼 수 있다.

MySQL 에서 LIMIT을 이용한 행수의 제한은 다음과 같은 쿼리를 가진다.

mysql> SELECT 열명 FROM 테이블명 WHERE 조건식 ORDER BY 열명 LIMIT 함수;

그렇다면 위의 경우, ORDER BY 구문은 없다고 생각할 수 있으니, 조건식인 WHERE 구문 뒤에 LIMIT 함수가 붙어 있다고 생각할 수 있다. 그렇다면 주석을 이용하면 우회가 가능하다고 볼 수 있다.

여기서 주석은 # 또는 --  를 이용할 수 있다. ( -- 의 경우 -- 뒤에 공백이 한칸 적용되어야 주석으로 인식한다.)

그렇다면 다음과 같은 값을 입력해볼 수 있다.

1' or 1=1 # / 1' or 1=1 --
(1=1 을 입력하거나 '1'='1'을 입력해서  or 뒤의 값은 참이기만 하면된다.)

위와 같이 입력해준 결과는 다음과 같다.

위와 같이 전체 데이터가 조회되는 것을 확인할 수 있다. 이를 Burp 통해 확인해보면 다음과 같다.

실제 쿼리 부분을 살펴보면 위와 같이 LIMIT 1을 이용하여, 한 줄만 출력해주고 있는 것을 확인할 수 있었다.

---

Security Level: Impossible

Impossible 레벨의 경우 다음과 같이 Low 레벨과 같이 입력 값을 직접 입력할 수 있다. 하지만 숫자 값만 받도록 조치되어 있고, 기존의 Medium 의 보안 조치와 더불어 Prepared State를 이용하고 있기 때문에 완벽한 보안 조치를 취하고 있다고 볼 수 있다.

위와 같이 입력되는 파라미터에 대하여 숫자인지 확인하고, 결과 값에 대하여도, 한줄의 결과만이 나오는지 확인하고 있다.

---

질문 환영, 수정 및 보완에 대한 지적 환영