2021/01/15 - [프로젝트/DVWA 실습] - DVWA 실습 #8 - SQL Injection
문제 해결 방법
이번 단계에서는 사용자에게서 직접 id 값을 입력받지 않고 HTML의 셀렉트박스를 이용해서 지정된 값만 입력할 수 있도록 제한하고 있다.
하지만 이는 별 의미가 없는게 결국 GET이든 POST든 전달되는 데이터를 수정하면 되기 때문에 Burp Suite를 이용해서 이전 단계에서 사용했던 쿼리를 집어넣으면 되지 않을까? 동일하게 입력해봤지만 다음처럼 에러가 발생하는 것을 볼 수 있었다.
에러를 확인해 보니 쿼리의 '\' union select user_id, password from dvwa.users#'에서 문제가 발생했다고 하는데 우리가 수정한 값인 "' union select ..."가 "\' union select ..."로 이스케이프되어 있었다. 그렇다면 여기서 우리는 mysql_real_escape_string() 같은 SQL Injection 필터링 함수가 적용되어 있다고 추측할 수 있다. 그렇다면 이를 우회할 방법은 뭐가 있을까? 소스 코드를 확인해보면 뭐가 문제인지 알 수 있다.
SELECT first_name, last_name FROM users WHERE user_id = $id;
이전 단계와는 달리 id 파라미터가 삽입되는 부분이 따옴표로 감싸지지 않았다. 사용자들의 id는 문자열이 아닌 숫자기 때문에 숫자끼리 비교하기 위해 의도적으로 누락한 것 같은데 이는 역시 뒤에 추가적인 쿼리가 삽입될 수 있다는 취약점이 존재한다. 비록 따옴표나 쌍따옴표를 사용하진 못하겠지만 LoS를 풀 때 몇번 했던 것처럼 ord(), substr() 함수 등으로 충분히 정보를 유출시킬 수 있으며 이전 단계에서 사용한 페이로드에서 따옴표를 빼고 원래 쿼리의 user_id 파라미터에 들어갈 값을 아무거나 입력해준 후 Burp Suite에서 id 파라미터를 수정해주면 다음처럼 사용자 정보가 노출되는 것을 볼 수 있다.
SELECT first_name, last_name FROM users WHERE user_id = 0 union select user_id, password from dvwa.users#;
이는 HTML 코드를 수정해서 select 태그 대신 input 태그를 사용하면 Low 단계와 비슷한 형태로 풀 수 있다.
SQL Injection에 대한 방지책으로 입력값을 필터링하려는 시도가 있었으나 서버측에서는 불충분했으며 클라이언트측에서는 거의 무의미했기 때문에 여전히 취약한 것을 알 수 있었다.
'프로젝트 > DVWA 실습' 카테고리의 다른 글
DVWA 실습 #8-3 - SQL Injection(high) (0) | 2021.01.15 |
---|---|
DVWA 실습 #8-1 - SQL Injection(low) (0) | 2021.01.15 |
DVWA 실습 #8 - SQL Injection (0) | 2021.01.15 |
DVWA 실습 #7-3 - Insecure CAPTCHA(high) (0) | 2021.01.15 |
DVWA 실습 #7-2 - Insecure CAPTCHA(medium) (0) | 2021.01.15 |