1. 개요
1.1 실습 목적
본 실습은 DVWA(Damn Vulnerable Web Application)을 활용하여 웹 애플리케이션 취약점 중 SQL 인젝션 취약점 공격을 실습하여, 웹 취약점 이해 및 그에 따른 공격 기법과 대응 방법 학습을 목적으로 진행되었습니다.
1.2 실습 환경 구성 및 도구
실습 환경에 사용한 운영체제(OS) 및 프로그램 환경, 도구는 다음과 같습니다.
1.3 실습 대상
- SQL Injection Medium Level
2. SQL 인젝션(SQL Injection)
2.1 SQL 인젝션 개요
2.1.1 정의
SQL 인젝션은 애플리케이션의 입력값 검증이 미흡할 때, 공격자가 데이터베이스(DB)로 전달되는 쿼리문을 조작하는 공격입니다. 이를 통해 공격자는 권한이 없는 민감 데이터 조회, 수정, 삭제, 탈취 및 관리자 권한을 탈취할 수 있습니다.
2.1.2 발생 원인
SQL 인젝션의 주요 발생 원인은 사용자 입력값에 대한 검증 로직이 미흡할 때 발생합니다.
- 사용자 입력값을 별다른 조치 없이 SQL 쿼리 문자열에 직접 결합하는 경우
- 악용될 수 있는 특수 문자 등에 대한 치환이나 차단 처리가 되어있지 않은 경우
- 웹이나 관리자가 과도한 권한을 가진 경우
- 영업 사원이 본인이 담당하는 지역이 아닌 다른 지역 데이터베이스에도 접근 가능한 경우
- 신입사원이 팀장의 권한에 접근 가능하여 활용이 가능한 경우
2.1.3 공격 유형
1) Union-based
두 개의 쿼리 결과를 합치는 UNION 연산자를 활용하여, 기존 쿼리에 공격자가 원하는 데이터를 조회하는 쿼리를 합쳐 화면에 노출시킵니다.
2) Error-based
에러 메시지를 유도한 후, 메시지 내용이나 다른 함수를 같이 사용하여 데이터베이스나 서버의 내부 구조를 파악하여 공격에 활용합니다.
3) Boolean-based
참/거짓에 따른 응답 값의 차이로 정보를 유추합니다.
4) Time-based
서버의 응답 지연 시간을 이용하여, 조건이 참일 경우 서버가 늦게 응답하게 하여 정보를 유추합니다.
5) Out-of-band SQL Injection
서버가 공격자에게 직접 응답하지 않고, DNS나 HTTP 등 별도의 프로토콜을 사용하여 공격자의 서버로 데이터를 전송하도록 만드는 방식입니다.
2.1.4 영향
SQL 인젝션은 위험도가 높은 취약점으로 평가됩니다. 공격자는 SQL 구문을 통해 데이터베이스에 접근하여 아래와 같은 위협을 발생할 수 있습니다.
- 데이터베이스에 접근하여 회원 정보, 비밀번호 등 민감 데이터를 유출할 수 있습니다.
- 데이터를 수정하거나 삭제하여 서비스가 중단될 수 있습니다.
- 일부 최소 권한이 설정되어 있지 않는 데이터베이스 환경에서는 운영체제 명령어를 실행하여 서버를 장악할 수 있습니다.
2.2 DVWA Medium Level SQL 인젝션 취약점 분석
페이지 DVWA Medium Level을 기준으로 분석하였습니다.
2.2.1 소스코드 취약점 분석
DVWA의 SQL 인젝션 Medium 레벨의 소스코드 분석 결과, 다음과 같은 취약점들을 확인했습니다. 소스코드 취약점의 상세 분석은 다음과 같습니다.
mysqli_real_escape_string() 함수는 " 등 SQL 구문에 영향을 줄 수 있는 특수 문자의 앞에 백슬래시를 붙여 일반 문자열로 입력되게 합니다.
그러나 캡처 1를 보면, 사용자 입력 값이 숫자로 작성되어 특수문자(') 없이도 SQL 문법 조작이 가능합니다.
DVWA의 SQL 인젝션 Medium 레벨에서는 사용자 입력값이 숫자형으로 입력되기 때문에 사용자 입력값이 쿼리의 일부로 실행됩니다.
쿼리 실행 실패 시 mysqli_error를 통해 구체적인 DB 에러를 출력하고 있습니다. 공격자가 Error-based SQL Injection을 시도할 때 에러 메시지를 보고 DB 구조를 파악할 수 있습니다.
개발자 도구에서 User ID 5의 Value 값을 문자로 바꿔준 뒤 에러 메시지 노출을 시도하였습니다.
발생한 에러가 별도의 조치 없이 그대로 브라우저에 출력되고 있어 /var/www/html/DVWA/vulnerabilities/sqli/source/medium.php라는 서버 경로가 노출되고 있습니다. 공격자는 이 경로를 통해 파일 업로드 등 다른 공격을 시도할 수 있습니다.
취약점 분석 결론
mysqli_real_escape_string() 함수를 통해 문자에 대한 입력값을 필터링하고 있으나, 숫자 입력값에 대한 조치가 미흡하여 공격자는 이를 통해 SQL 인젝션 공격을 시도할 수 있습니다.
또한 숫자 입력값에 대해 작은따옴표(")로 감싸져 있지 않아 입력값이 그대로 쿼리문으로 실행되고 있습니다.
또한 오류 메시지가 별도의 필터링 없이 경로와 같은 정보가 노출되고 있고, 이를 통해 파일 업로드 등 2차 공격이 이뤄질 수 있습니다.
또한 클라이언트에서만 입력값을 검증하고 있어 프록시(Proxy) 도구인 Burp Suite나 개발자 도구를 이용해 id 파라미터 값을 변조하여 전송하여 이를 우회할 가능성이 있습니다.
2.3 시나리오 기반 모의 해킹 실습
2.3.1 Union-based SQL 인젝션
두 개의 쿼리(ORDER BY, UNION SELECT)의 결과를 조합하여, 공격자가 원하는 정보를 조회하는 시나리오를 아래와 같이 단계별로 진행하였습니다.
실습에 개발자 도구를 활용하였습니다.
- 공격자, ORDER BY 활용, 현재 테이블의 컬럼 개수 파악
- 공격자, 이후 UNION SELETE 활용, 데이터 출력 위치 확인
- 공격자, 데이터베이스 정보 탈취
- 공격자, 테이블 정보 탈취
- 공격자, 탈취한 정보들을 조합하여 사용자 ID 및 PW 탈취
Security Level을 Medium으로 설정 후 DVWA의 SQL 인젝션 페이지로 접근하였습니다.개발자 도구의 조사(Inspector)를 이용하여 숫자 입력 목록을 좌클릭한 뒤, 입력값과 관련된 코드를 탐색했습니다.
value 값에 1 ORDER BY 2, 1 ORDER BY 3과 같이 ORDER BY를 활용하여, 데이터베이스 테이블의 컬럼 개수를 파악하기 위해 해당 구문을 입력했습니다.
1 ORDER BY 3를 value 값에 입력했을 때, Unknown column '3' in 'ORDER BY' 라는 오류 메시지가 노출되는 것을 확인했습니다. 1 ORDER BY 2 입력 시 데이터가 정상적으로 출력되었으므로 컬럼의 수는 2개라고 추론할 수 있었습니다.
UNION SELECT를 활용하여 임시로 999와 888을 1 UNION SELECT 999.888을 컬럼 수에 맞게 입력한 뒤 데이터 출력 위치를 확인하였습니다.
데이터베이스의 버전과 이름을 확인하기 위해 1UNION SELECT @@version, database() 구문을 value 값에 입력하였습니다. 결과에서 11.8.3-MariaDB와 같이 데이터베이스의 버전 정보와 dvwa라는 데이터베이스 명이 출력되었습니다.
users 테이블의 컬럼 이름을 탈취하기 위해 아래와 같은 구문을 value 값에 입력했습니다.
1 UNION SELECT 1, group_concat(column_name) FROM information_schema.columns WHERE table_name = users
users 컬럼이 존재하지 않는다고 오류 메시지가 반환되었습니다.
이는 앞서 살펴본 mysqli_real_escape_string() 함수가 문자열을 필터링하기 때문에, 입력한 문자열 users가 'users'로 변환되어 발생한 문제입니다. 해당 레벨은 숫자형 입력값을 기반으로 작동하므로, 변환된 문자열 구문이 올바르게 해석되지 않아 문법 오류가 발생했습니다.
mysqli_real_escape_string() 함수는 특수문자(따옴표 등)를 필터링하는 역할을 하지만, 데이터의 형식을 검증하지는 않습니다. 캡처 15번 소스 코드를 보면 $id 변수가 따옴표로 감싸져 있지 않기 때문에, 공격자는 숫자 입력값을 이용하여 SQL 인젝션을 시도할 경우 이를 우회할 가능성이 있습니다.
1 UNION SELECT 1, group_concat(column_name) FROM information_schema.columns WHERE table_name = 0x7573657273
헥사 값 변환 뒤, 결과를 조회하였을 때 users 테이블의 컬럼명을 확인할 수 있었습니다.
앞서 탈취한 users의 테이블 컬럼명으로 사용자의 계정 탈취를 시도하였습니다.
계정 탈취 시도 결과, 사용자의 ID와 md5 함수로 암호화된 비밀번호가 노출되는 것이 확인되었습니다. md5 역시 이미 암호화 방식이 노출된 함수이므로 공격자가 이를 복호화한다면 평문 비밀번호를 얻을 수 있습니다.
2.3.2 sqlmap 도구 활용
sqlmap 도구를 활용하여 SQL 인젝션 실습에 활용하였습니다. 시나리오 순서는 아래와 같습니다.
- 공격 대상의 패킷을 가로채기 (Burp Suite 활용)
- 가로챈 요청 패킷의 내용을 복사한 뒤 동일 내용을 가진 파일 생성 (
request.txt) - sqlmap 실행
sqlmap 도구 활용에 필요한 요청 패킷 내용을 얻기 위해 프록시 도구인 Burp Suite의 Intercept 기능을 통해 요청 패킷을 중간에 가로챘습니다.
요청 패킷 전문을 복사해준 뒤, request.txt 파일을 생성하여 그대로 붙여넣기 하였습니다.
sqlmap 명령어를 사용하여 데이터베이스 스캔을 시도하였습니다. dvwa와 infomation_schema라는 접근이 가능한 데이터베이스 2개가 확인되었습니다.
sqlmap 도구의 명령어를 사용하여 이전에 확인한 dvwa의 데이터베이스 테이블명 탈취를 시도하였고, dvwa에서 총 4개의 테이블명이 확인되었습니다.
터미널 화면에 표 형태로 user, password 등의 내용이 출력되는 것을 확인하였고, sqlmap에서 암호화된 비밀번호를 복호화하여 해시된 비밀번호도 출력되는 것을 볼 수 있었습니다.
모의해킹 실습 결론
DVWA Mediem 레벨의 SQL 인젝션은 mysqli_real_escape_string() 함수로 문자열 검증을 하나, 숫자 입력값에 대한 검증이 미흡하여 users를 헥사 값으로 전환하여 이를 우회할 수 있었습니다. 또한 md5 라는 이미 암호화 방식이 알려진 함수를 사용하여서, 암호화된 비밀번호를 도구를 통해 복호화하여 평문 비밀번호를 얻을 수 있었습니다.
2.4 SQL Injection 대응 방안
[개인정보 보호법], [정보통신망 이용촉진 및 정보보호 등에 관한 법률(이하 정보통신망법)], [개인정보의 안전성 확보조치 기준 행정규칙]에서 제시한 규정을 바탕으로 시스템 환경 여건에 맞는 안정성 확보에 필요한 조치를 적용하는 것을 권고 드립니다.
대응 방안의 내용은 한국인터넷진흥원(KISA)의 "소프트웨어 보안약점 진단가이드 (2021)", "주요정보통신기반 시설 기술적 취약점 분석·평가 방법 상세가이드(2026)" 그리고 OWASP (Open Web Application Security Project)의 SQL 인젝션 문서를 참고했습니다. SQL 인젝션의 주요 대응 방안으로 작성된 사용자 입력값에 대한 적절한 검증을 통해 비정상적인 쿼리가 실행되지 않도록 할 것을 명시하고 있습니다.
2.4.1 SQL 쿼리 내 사용되는 문자열을 검증하는 로직 구현
외부 입력값에서 SQL 삽입이 가능한 문자열들을 필터링하여 안전한 값으로 치환하도록 하는 Filter 컴포넌트를 생성하고, DB에서 관리하는 데이터를 처리하는 모든 애플리케이션에 일괄 적용한다.
1) SQL 키워드/특수문자에 대하여 사용자 입력 값으로 지정 금지 및 필터링 로직 구현
String sqlKeywords = {"SELECT", "UNION", "INSERT", "UPDATE", "DELETE", "DROP", "--");
- SQL 인젝션 공격에 사용될 수 있는 키워드를 블랙리스트 방식으로 필터링
String pattern = "(?i)\\b(" + String.join("|", sqlKeywords) + ")\\b|[\\'\\\\:()<>#/\\*!]"; 정규 표현식
2) Prepared Statements를 사용하여 사용자 입력과 SQL 쿼리를 분리하여 처리
Prepared Statements 가 적절하지 않은 환경일 경우, 화이트리스트 및 블랙리스트 적절히 혼합하여 검증 로직을 구현한다.
- 아이디, 전화번호, 이메일 등 정형 데이터는 화이트리스트 검증
- 본문 내용 등 자유로운 입력이 필요한 경우 블랙리스트 검증
3) 입력값 데이터 타입 검증 (숫자형, 문자형)
4) 입력값 문자 길이 검증
5) 외부 입력값이 삽입되는 SQL 문 동적 생성 실행 지양
만일 외부 입력값을 이용해 동적으로 SQL 질의문을 생성해야 하는 경우, 입력값에 대해 클라이언트와 서버 양측에서 입력값에 대해 안전한 값만 사용될 수 있도록 검증 작업을 수행한 뒤 사용해야 한다.
6) 웹 방화벽(WAF)에 대하여 SQL Injection 관련 규칙 추가
2.4.2 에러메시지 예외처리
시스템에서 제공하는 에러 메시지 및 DBMS 에서 제공하는 에러코드가 노출되지 않도록 예외 처리를 한다. 에러코드에는 구조, 주소 등 서버 환경을 특정할 수 있는 정보가 노출될 수 있기에 적절한 예외 처리 로직을 구현해야 한다.
2.4.3 애플리케이션에서 DB연결을 수행할 때 최소 권한의 계정을 사용
침해사고가 발생하더라도 나머지 부분에 대해 공격자가 액세스 권한을 가지지 않도록 애플리케이션에서 사용하는 DB연결 계정은 해당 애플리케이션이 사용하는 데이터에 대한 읽기, 쓰기, 삭제, 업데이트 권한만 설정해야 한다.
- 영업 담당자에게 고객 데이터베이스 읽기/쓰기 권한은 주어지되 다운로드 및 복사 권한 X
- 정부 직원이 자신의 보안 허가 수준에서 접근할 수 있는 정보 및 직무와 유관한 정보에만 액세스할 수 있음(예: 식품의약국 직원은 국방 관련 정보에 접근할 수 없음).
- 직무상 청구서를 처리해야 하는 직원이 회계 애플리케이션에서 해당 기능에만 접근할 수 있으며 매출 채권이나 급여 처리 기능에는 접근 제한 설정
