SQL 인젝션: 데이터와 명령의 경계

01개념과 구성 요소

• 성립 원리외부 값이 SQL 문자열에 합쳐져 데이터가 아닌 문법으로 해석되면 쿼리 구조가 변할 수 있다.
• 구성 경계HTTP 입력, 애플리케이션의 쿼리 생성, DB 파서, DB 계정 권한, 결과 출력이 연결된다.
• 핵심 방어값은 바인딩하고 구조 선택은 허용 목록으로 제한한다. DB 최소권한과 비밀번호 검증은 별도 방어층이다.

02조회 입력이 DB 결과가 되는 순서

1. 요청값 수신서버가 GET·POST·세션 등 실제 입력 위치를 읽고 필요한 정규화와 형식 검증을 수행한다.
2. 쿼리 구조 결정개발자가 고정한 SQL 구조를 선택한다. 문자열 연결 방식은 외부 값이 문법에 들어갈 수 있는 지점이다.
3. 매개변수 전달prepare/execute 등 드라이버가 지원하는 인터페이스로 값을 전달한다. 값 바인딩을 테이블명·정렬 구문에 대신 쓰지 않는다.
4. DB 권한으로 실행DB가 애플리케이션 계정의 권한 안에서 문장을 처리한다. SQLi가 DB의 모든 권한을 자동으로 우회하는 것은 아니다.
5. 행과 응답 처리결과 행을 업무 규칙에 맞게 사용하고 안전하게 출력한다. 단순히 행이 있다는 이유만으로 비밀번호 검증을 대신하지 않는다.

03입력이 데이터에서 SQL 문법으로 넘어가는 지점

• 문법 경계SQL Injection은 DB가 사용자 입력이라는 출처를 자동으로 기억하지 않는다는 점에서 시작한다. 애플리케이션이 외부 값을 SQL 문자열에 연결하여 완성된 문장을 DB에 보내면 파서는 전체를 SQL 문법으로 해석한다.
• 구조 변경 문자따옴표는 문자열의 경계, OR는 조건 연산, 주석은 뒤 문법을 무시하는 역할을 하므로 입력이 구조를 바꿀 수 있다.
• PDO 비교아래 PHP 비교의 목적은 요청값이 최종 SQL과 어떻게 연결되는지 보는 것이다. 정상 이름에 작은따옴표가 들어오는 경우에도 문자열 연결 방식은 깨질 수 있다.
• 취약점의 기준취약점의 기준은 특수문자의 존재 자체가 아니라 값으로만 쓰여야 할 내용이 구문이 되는 경계다.

$id = $_GET["id"];
// 취약한 구조: 데이터가 SQL 문자열 일부가 된다.
$sql = "SELECT first_name, last_name FROM users WHERE user_id = '$id'";

// 매개변수 방식: 쿼리 구조와 값을 API에서 분리한다.
$stmt = $pdo->prepare(
  "SELECT first_name, last_name FROM users WHERE user_id = ?"
);
$stmt->execute([$id]);

원문의 PDO 비교를 실제 주소·계정 없이 재구성했다. 두 예시는 구조 비교이며 원본 코드를 실행하지 않았다.

04WHERE는 행마다 조건을 평가한다

• WHERE 평가WHERE는 각 행의 조건을 평가해 참인 행을 결과에 남긴다. DB가 단순히 boolean 한 개만 애플리케이션에 반환하는 것이 아니다.
• 결과 집합 변화정상 user_id=1 조건이 특정 행만 고르는 것과 OR 1=1 조건이 모든 행에서 참이 되는 것은 결과 집합의 차이다. 문자열 리터럴을 닫는 따옴표와 조건을 추가하는 연산자의 역할을 분리하면 변화가 보인다.
• 세 행 예시학습용 예에서는 실제 사용자 데이터 대신 세 개의 가상 행을 생각할 수 있다. ID 1,2,3 가운데 WHERE id=1은 첫 행을 남기지만 WHERE id=1 OR 1=1은 세 행을 남긴다.
• 인증 처리 영향이 결과를 로그인 성공 여부로 잘못 사용하면 비밀번호 검증이 생략되는 별도의 애플리케이션 오류와 연결될 수 있다.

-- 가상 테이블에 대한 SQL 의미 비교
SELECT label FROM demo_items WHERE id = 1;
SELECT label FROM demo_items WHERE id = 1 OR 1 = 1;

-- 첫 번째: id=1인 행
-- 두 번째: 조건이 모든 행에서 참

조건식의 결과 집합을 보여 주는 교육용 SQL이다. 외부 대상으로 보내는 공격 요청이 아니다.

05로그인 쿼리와 비밀번호 검증의 위치

• 조건 무효화사용자명 뒤에 평문 비밀번호 조건을 문자열로 붙인 로그인 쿼리는 주입된 주석에 의해 뒤 조건이 무효화될 수 있다. 입력이 문자열을 닫고 나머지를 주석으로 만들면 애플리케이션은 의도하지 않은 행을 받을 수 있다.
• 행 존재의 오용여기에 “행이 있으면 로그인 성공”이라는 처리까지 있으면 인증 상태가 잘못 만들어진다.
• 계정 조회와 해시 검증안전한 흐름은 매개변수로 계정을 조회하고 서버의 비밀번호 검증 함수로 저장된 비밀번호 해시와 입력을 확인한 뒤 세션을 발급하는 것이다. SQL 매개변수화와 비밀번호 해시 검증은 서로 다른 문제를 해결한다.
• 외부 오류계정이 없을 때와 비밀번호가 틀릴 때의 외부 오류 차이를 줄이는 것도 정보 노출을 제한하는 별도의 설계다.

06UNION이 합치는 것은 같은 모양의 결과 집합이다

• UNION 열 구조UNION은 두 SELECT의 결과를 연결한다. 양쪽 열 수가 같고 위치별 자료형이 호환되어야 하며 UNION은 중복을 제거하고 UNION ALL은 유지한다.
• 독립 조건첫 SELECT의 WHERE는 두 번째 SELECT에 자동 상속되지 않는다. 따라서 애플리케이션이 첫 쿼리에만 걸어 둔 행 제한과 별개로 다른 결과를 같은 화면 통로에 실을 수 있다.
• 상수 표식111·222 같은 상수 표식은 화면에 결과의 어느 열이 표시되는지 구분하는 데 사용할 수 있다. 실제 비밀번호나 테이블 자료 대신 두 개의 상수만으로도 출력 통로를 설명할 수 있다.
• ORDER BY 단서ORDER BY의 숫자 위치 오류는 결과 열 위치에 대한 단서이며 테이블에 정의된 모든 컬럼 수를 직접 알려 주는 것은 아니다.

SELECT '원래 결과' AS label, '표시 값' AS detail
UNION ALL
SELECT '표식 A', '표식 B';

UNION의 열 수·표시 위치를 설명하는 가상 상수 예제다.

07애플리케이션 권한과 DB 계정 권한은 다르다

• DB 실행 권한SQLi로 사용자가 웹 화면에서 허용되지 않은 데이터를 보더라도 DB의 GRANT 자체를 무조건 우회한 것은 아니다. 주입된 쿼리는 보통 애플리케이션 DB 계정의 권한으로 실행된다.
• 웹의 행 제한그 계정이 모든 사용자의 행을 읽을 수 있는데 웹 코드가 사용자별 범위를 담당하고 있었다면 쿼리 구조 변조로 그 제한이 깨질 수 있다.
• DEFINER·INVOKERSQL SECURITY DEFINER 뷰는 정의된 권한 문맥에서 기반 데이터를 읽을 수 있고 INVOKER는 호출자 권한 문맥을 사용한다. 뷰에 위임된 접근과 권한 없는 테이블을 마법처럼 읽는 것은 다르다.
• 최소권한최소권한은 주입 자체를 없애지는 않지만 파일 기능·다른 스키마·관리 작업으로 피해가 확장되는 범위를 제한한다.

08응답에 보이는 유형과 보이지 않는 유형

• In-bandIn-band 유형에서는 같은 요청의 응답에 결과나 DB 오류가 나타난다. Error-based는 오류 내용이나 오류의 유무가 단서가 되고 UNION-based는 결과 집합의 출력 통로를 이용한다.
• 정보 은닉의 한계상세 오류를 숨기면 일부 정보가 사라지지만 입력이 SQL 구문이 되는 설계가 그대로라면 취약점은 남는다.
• BlindBlind 유형에서는 결과가 직접 보이지 않아도 참·거짓에 따른 본문 길이, 문구, JSON 필드, 리다이렉트나 시간 차이가 단서가 된다. Boolean-based는 안정적인 응답 차이를, Time-based는 조건에 따른 지연을 관찰한다.
• 지연 대조네트워크 지연·캐시·개인화와 DB 조건의 효과를 구분해야 하며 한 번 느린 응답을 취약점 확정으로 해석하지 않는다.

09GET·POST·세션을 재현하지 못하면 다른 기능을 시험한다

• 입력 위치DVWA 예제의 id는 GET 쿼리에 있고 Mutillidae의 author는 POST 본문에 있었다. 같은 URL만 복사하고 본문을 빼면 원래 기능과 다른 요청이다.
• 세션·보안 단계로그인 Cookie나 보안 단계, CSRF 토큰이 달라져도 서버가 실행하는 경로가 달라진다. 도구의 취약점 판정 이전에 정상 요청이 같은 기능까지 도달하는지가 중요하다.
• 재현 실패302 로그인 이동, 반복 404, 다른 보안 단계는 취약점 유무보다 요청 재현 실패를 먼저 설명할 수 있다. 자동 도구의 Parameter·Type·Title·DBMS 필드는 추정 결과를 요약하지만 데이터에 대한 근거와 성공 조건을 대신하지 않는다.
• 대조군과도한 요청이나 데이터 덤프 없이 가상 표식과 정상 대조군으로 원리와 수정 효과를 읽을 수 있다.

POST /training/search HTTP/1.1
Host: app.example
Content-Type: application/x-www-form-urlencoded
Cookie: sid=<가상 세션>

author=sample-user&action=search

응답 비교: 상태 코드 / 리다이렉트 / 본문 구조 / 요청 ID

본문 파라미터가 URL과 별도로 존재한다는 점을 보여 주는 가상 정상 요청이다.

10URL 문법과 SQL 주석 문법을 구분하기

• URL fragment브라우저 URL의 # 뒤 조각은 일반적으로 서버 요청 대상으로 전송되지 않는다. DB에서 #이 주석 문법으로 쓰이는 경우와는 다른 파서의 동작이다.
• DB별 주석 문법또한 MySQL 계열의 -- 주석은 뒤 공백 또는 제어문자 조건이 있고 다른 DBMS의 문법은 다를 수 있다. 문자 하나가 어디서 해석되는지를 명확히 해야 서버에 실제 도달한 값을 이해할 수 있다.
• 문자 차단의 한계이 차이를 근거로 특정 주석 문자열을 차단하는 것은 근본 방어가 아니다. 입력이 숫자·문자열·식별자 중 어느 문맥에 놓였는지와 드라이버의 처리 방식에 따라 구조가 달라진다.
• 파싱 추적URL 디코딩과 문자열 정규화 뒤 실제 SQL 값이 무엇인지 로그와 소스의 대응 관계로 추적한다.

11매개변수로 묶을 수 없는 구조는 허용 목록으로 선택한다

• 값과 식별자매개변수는 값 자리를 위한 것이며 테이블명·컬럼명·정렬 방향을 임의로 바인딩하여 SQL 문법으로 사용하는 인터페이스가 아니다. 정렬 옵션이 필요하면 외부의 짧은 선택값을 서버가 정한 컬럼 표현에 매핑한다.
• ORM의 경계ORM을 사용해도 raw SQL 문자열에 입력을 연결하면 같은 경계 문제가 다시 생긴다.
• PDO 전달 방식PDO prepare와 execute의 API 분리는 학습 원리다. 모든 드라이버가 네트워크에서 SQL 구조와 값을 반드시 두 개의 독립 메시지로 보내는 것은 아니며 네이티브·에뮬레이션 설정도 실제 구현에 영향을 준다.
• 드라이버 조건사용 중인 드라이버가 지원하는 바인딩 방법으로 구조를 분리하고 그 위에 DB 최소권한과 외부 오류 제한을 결합한다.

$sortMap = [
  "name" => "display_name",
  "recent" => "created_at"
];
$column = $sortMap[$_GET["sort"] ?? "recent"] ?? "created_at";
$sql = "SELECT display_name FROM demo_users ORDER BY " . $column;

외부 문자열을 그대로 SQL 식별자로 쓰지 않고 서버의 고정 후보로 매핑하는 예제다.

15수정 결과는 쿼리 구조와 정상 기능에서 드러난다

• 정상 기능수정 후 같은 따옴표 포함 이름이 정상 데이터로 저장·검색되고 조건식 모양의 입력도 문자열 값으로만 취급되어야 한다. 오류가 사라졌다는 사실만으로는 충분하지 않다.
• 오류 제거의 한계화면 출력이 끊겼거나 요청을 전부 막아도 오류는 보이지 않을 수 있기 때문이다. 소스의 바인딩, DB 계정 권한, 정상 결과와 변조 입력의 결과를 함께 연결한다.
• 재현 근거재현 자료에는 메서드·입력 위치·인증 문맥, 최종 SQL 구조, 애플리케이션과 DB의 권한 경계, 응답 관찰값을 연결한다. 같은 입력에 대한 결과가 바뀐 이유를 쿼리의 구조로 설명하면 자동 도구의 성공·실패 표시와 무관하게 수정의 효과를 해석할 수 있다.
• 내부 오류 기록실제 DB 오류는 내부에서 요청 ID와 연결하되 비밀값은 불필요하게 남기지 않는다.