SQL Injection

HTTP 요청과 응답
GET과 POST
쿠키와 세션
인증과 인가
HTTPS
웹 로그
입력값 검증
오류 메시지 노출

SQL Injection의 개념을 설명하시오.
SQL Injection의 발생 원인과 대응 방안을 설명하시오.
Prepared Statement가 SQL Injection 대응에 효과적인 이유를 설명하시오.
SQL Injection 공격 로그를 보고 의심 근거와 대응 방안을 제시하시오.

사용자 입력
→ 웹 서버
→ 애플리케이션 서버
→ SQL 쿼리 생성
→ DB 조회
→ 결과 반환

사용자 입력값이 SQL문의 일부로 해석됨
→ 공격자가 SQL 구문을 삽입함
→ DB가 공격자의 의도대로 동작함

SQL Injection = 사용자 입력값이 데이터가 아니라 SQL 명령어처럼 실행되는 문제

SELECT * FROM users WHERE id = 'user01';

users 테이블에서 id가 user01인 사용자를 조회하라.

SELECT * FROM users
WHERE id = '입력한 아이디'
AND password = '입력한 비밀번호';

SQL Injection은 웹 애플리케이션의 입력값에 악의적인 SQL 구문을 삽입하여 데이터베이스를 비정상적으로 조회, 수정, 삭제하거나 인증을 우회하는 공격 기법이다.

SQL Injection = 입력창에 SQL 명령을 넣어 DB를 공격하는 기법

로그인 폼
검색창
게시판
URL 파라미터
쿠키
HTTP 헤더
API 요청값
파일명
정렬 조건

SQL Injection은 입력창에만 생기는 것이 아니다.
서버가 SQL에 사용하는 모든 입력값에서 발생할 수 있다.

사용자 입력값을 검증하지 않고 SQL 문자열에 직접 결합하기 때문

SQL문 = "SELECT * FROM users WHERE id = '" + 사용자입력 + "'"

고정된 SQL 구조 + 사용자 입력값을 문자열로 직접 연결

SELECT * FROM users
WHERE id = '사용자입력ID'
AND password = '사용자입력PW';

ID: user01
PW: pass1234

인증 우회
개인정보 유출
DB 데이터 변조·삭제

아이디가 맞는가?
비밀번호가 맞는가?

SELECT * FROM users
WHERE id = '입력ID'
AND password = '입력PW';

인증 우회형 SQL Injection은 로그인 조건절을 조작하여 비밀번호 검증 없이 인증된 사용자로 처리되게 하는 공격이다.

Prepared Statement 사용
입력값 검증
비밀번호 해시 검증
로그인 실패 횟수 제한
오류 메시지 노출 제한
인증 로직 서버 측 검증

SQL syntax error near ...
Unknown column 'user_pw'
Table 'member_admin' doesn't exist

사용 중인 DB 종류
테이블명
컬럼명
쿼리 구조
서버 경로

오류 기반 SQL Injection은 DB 오류 메시지를 통해 쿼리 구조, 테이블명, 컬럼명 등 내부 정보를 추론하는 공격 방식이다. 대응을 위해 사용자에게 상세 오류를 노출하지 않고, 오류 내용은 서버 로그에만 기록해야 한다.

조건이 참일 때: 정상 페이지 표시
조건이 거짓일 때: 다른 페이지 표시

조건이 참일 때: 응답이 지연됨
조건이 거짓일 때: 바로 응답함

Blind SQL Injection은 쿼리 결과가 화면에 직접 출력되지 않더라도 참·거짓 응답 차이나 응답 지연 시간 등을 이용하여 DB 정보를 추론하는 공격 방식이다.

Prepared Statement
입력값 검증
오류 메시지 제한
DB 권한 최소화
비정상 요청 탐지
WAF 적용

서버가 SQL 생성에 사용하는 모든 외부 입력값은 검증 대상이다.

요청 파라미터에 SQL 키워드와 특수문자가 포함되어 있고, 동일 URL에 반복 요청과 500 오류가 발생하므로 SQL Injection 시도로 의심할 수 있다. 대응 방안으로 해당 출발지 IP와 요청 패턴을 분석하고, 입력값 검증, Prepared Statement 적용 여부, 오류 메시지 노출 여부, WAF 탐지 정책을 점검해야 한다.

Prepared Statement 사용
입력값 검증
DB 권한 최소화
오류 메시지 노출 제한
WAF 적용
로그 모니터링

Prepared Statement는 SQL문의 구조를 미리 정의하고 사용자 입력값을 파라미터로 바인딩하여 SQL 구문과 데이터를 분리하는 방식이다.

Prepared Statement = SQL 구조와 입력값을 분리하는 안전한 쿼리 방식

SQL 구조 + 사용자 입력값이 섞임

SQL 구조는 고정
사용자 입력값은 데이터로만 처리

Prepared Statement는 SQL 구조와 사용자 입력값을 분리하고 입력값을 파라미터로 바인딩하므로, 입력값에 SQL 구문이 포함되더라도 명령어로 해석되지 않고 데이터로 처리된다. 따라서 SQL Injection 방지에 효과적이다.

Prepared Statement + 입력값 검증 + DB 권한 최소화 + 오류 메시지 제한

입력값 검증은 사용자 입력이 허용된 형식, 길이, 범위, 문자 집합에 맞는지 확인하여 비정상 입력을 차단하는 보안 조치이다.

user_id = 숫자만 허용
page = 1 이상의 정수만 허용
email = 이메일 형식만 허용
sort = name, date, price 중 하나만 허용

허용목록 = 허용된 값만 통과시키는 방식

name
date
price

차단목록 = 위험해 보이는 값만 막는 방식

입력값 검증은 차단목록 방식보다 허용목록 방식을 적용하는 것이 바람직하다. 허용된 문자, 형식, 길이, 범위만 통과시켜 우회 입력 가능성을 줄일 수 있기 때문이다.

이스케이프만으로 SQL Injection 방어를 끝냈다고 보면 안 된다.
Prepared Statement가 우선이다.

특수문자 이스케이프는 보조적인 대응책이며, SQL Injection 방어의 핵심은 SQL 구조와 입력값을 분리하는 Prepared Statement 사용이다.

웹 애플리케이션 DB 계정이 모든 테이블에 SELECT, INSERT, UPDATE, DELETE, DROP 권한을 가짐

웹 애플리케이션 기능에 필요한 테이블과 작업 권한만 부여

DB 권한 최소화는 웹 애플리케이션 DB 계정에 업무 수행에 필요한 최소 권한만 부여하는 것이다. SQL Injection이 발생하더라도 공격자가 수행할 수 있는 조회, 수정, 삭제 범위를 제한하여 피해를 줄일 수 있다.

사용자에게는 일반 오류 메시지만 표시한다.
상세 오류는 서버 로그에만 기록한다.

상세 SQL 오류 메시지는 DB 종류, 테이블명, 컬럼명, 쿼리 구조 등 내부 정보를 노출하여 SQL Injection 공격에 활용될 수 있다. 따라서 사용자에게는 일반화된 오류 메시지만 제공하고, 상세 오류는 서버 로그에 기록하여 관리자만 확인하도록 해야 한다.

HTTP 요청의 URL, 파라미터, 쿠키, 헤더, 본문을 분석하여 SQL Injection 패턴을 탐지·차단

WAF = 보조 방어
시큐어 코딩 = 근본 방어

WAF는 SQL Injection 공격 패턴을 탐지하고 차단하는 데 도움이 되지만, 애플리케이션 코드의 취약점을 제거하는 근본 대책은 아니다. 따라서 Prepared Statement와 입력값 검증 등 시큐어 코딩과 함께 적용해야 한다.

저장 프로시저 내부에서 사용자 입력값으로 동적 SQL을 문자열 결합하여 실행하는 경우

저장 프로시저를 사용하더라도 내부에서 사용자 입력값을 문자열로 결합한 동적 SQL을 실행하면 SQL Injection이 발생할 수 있다. 따라서 저장 프로시저 내부에서도 파라미터 바인딩과 입력값 검증을 적용해야 한다.

ORM의 파라미터 바인딩 기능을 사용하는 경우

ORM에서 직접 작성한 원시 SQL에 사용자 입력값을 문자열로 결합하는 경우

ORM을 사용하더라도 사용자 입력값을 원시 SQL 문자열에 직접 결합하면 SQL Injection이 발생할 수 있다. ORM의 안전한 파라미터 바인딩 기능을 사용하고 입력값 검증을 함께 적용해야 한다.

Prepared Statement 사용

입력값 검증

DB 권한 최소화

오류 메시지 노출 제한

WAF, 로그 모니터링, 취약점 점검

정의 → 원인 → 피해 → 대응책

SQL Injection은 사용자 입력값에 악의적인 SQL 구문을 삽입하여 DB를 비정상적으로 조작하는 공격이다.
주요 원인은 입력값을 검증하지 않고 SQL 문자열에 직접 결합하는 것이다.
대응 방안으로는 Prepared Statement 사용, 입력값 검증, DB 권한 최소화, 오류 메시지 노출 제한, WAF 적용, 로그 모니터링 등이 있다.

HTTPS를 사용해도 SQL Injection은 발생할 수 있다.

HTTPS는 클라이언트와 서버 간 통신을 암호화하여 도청과 변조를 방지하지만, 서버 애플리케이션이 입력값을 SQL문에 직접 결합하는 취약점을 제거하지는 못한다. 따라서 SQL Injection 방어를 위해서는 HTTPS와 별도로 Prepared Statement, 입력값 검증, DB 권한 최소화 등을 적용해야 한다.

탐지
→ 분석
→ 차단
→ 영향 범위 확인
→ 취약점 수정
→ 복구
→ 재발 방지

SQL Injection 공격이 의심되면 웹 로그, WAF 로그, DB 로그를 분석하여 공격 IP, 요청 URL, 파라미터, 발생 시간, DB 접근 내역을 확인해야 한다. 이후 공격 요청을 차단하고, 데이터 유출·변조 여부를 조사하며, Prepared Statement와 입력값 검증을 적용해 취약점을 수정하고 로그 모니터링과 정기 취약점 점검으로 재발을 방지해야 한다.

SQL Injection = DB 공격
XSS = 브라우저 공격
CSRF = 요청 위조

1. 사용자가 아이디와 비밀번호를 입력한다.
2. 서버가 입력값을 받는다.
3. 서버가 SQL을 만들어 DB에 조회한다.
4. 입력값을 SQL 문자열에 직접 붙이면 SQL Injection이 발생할 수 있다.
5. 공격자는 조건절을 조작해 인증 우회나 정보 조회를 시도할 수 있다.
6. DB 오류 메시지가 노출되면 테이블명이나 컬럼명을 추측할 수 있다.
7. 공격이 성공하면 개인정보 유출, 데이터 변조, 삭제가 발생할 수 있다.

1. 서버에서 입력값 형식과 길이를 검증한다.
2. Prepared Statement로 SQL 구조와 입력값을 분리한다.
3. DB 계정에는 필요한 최소 권한만 부여한다.
4. 상세 오류 메시지는 사용자에게 노출하지 않는다.
5. WAF와 로그 모니터링으로 비정상 요청을 탐지한다.
6. 정기적으로 취약점 점검을 수행한다.

SQL Injection은 웹 애플리케이션의 입력값에 악의적인 SQL 구문을 삽입하여 데이터베이스를 비정상적으로 조회, 수정, 삭제하거나 인증을 우회하는 공격이다. 주로 사용자 입력값을 검증하지 않고 SQL 문자열에 직접 결합할 때 발생한다.

SQL Injection 대응을 위해 SQL 구조와 입력값을 분리하는 Prepared Statement를 사용하고, 입력값의 형식·길이·범위를 서버 측에서 검증해야 한다. 또한 DB 계정에는 필요한 최소 권한만 부여하고, 상세 오류 메시지 노출을 제한하며, WAF와 로그 모니터링을 통해 공격 시도를 탐지해야 한다.

Prepared Statement는 SQL문의 구조를 미리 정의하고 사용자 입력값을 파라미터로 바인딩하여 SQL 구문과 데이터를 분리한다. 따라서 입력값에 SQL 문법이 포함되더라도 명령어로 실행되지 않고 데이터로 처리되어 SQL Injection을 방지할 수 있다.

DB 권한 최소화는 웹 애플리케이션이 사용하는 DB 계정에 업무 수행에 필요한 최소한의 권한만 부여하는 것이다. SQL Injection이 발생하더라도 공격자가 수행할 수 있는 조회, 수정, 삭제, 권한 변경 범위를 제한하여 피해를 줄일 수 있다.

상세 SQL 오류 메시지는 DB 종류, 테이블명, 컬럼명, 쿼리 구조, 서버 경로 등 내부 정보를 노출할 수 있다. 공격자는 이를 이용해 SQL Injection 공격을 정교화할 수 있으므로 사용자에게는 일반화된 오류 메시지만 제공하고 상세 오류는 서버 로그에 기록해야 한다.

SQL Injection 공격이 의심되면 웹 로그, WAF 로그, DB 로그를 분석하여 공격 IP, 요청 URL, 파라미터, 발생 시간, DB 접근 내역을 확인해야 한다. 이후 공격 요청을 차단하고 데이터 유출·변조 여부를 조사하며, Prepared Statement와 입력값 검증을 적용해 취약점을 수정하고 로그 모니터링과 정기 취약점 점검으로 재발을 방지해야 한다.

SQL Injection은 사용자 입력값에 악의적인 SQL 구문을 삽입하여 DB를 비정상적으로 조회, 수정, 삭제하거나 인증을 우회하는 공격이다.

SQL Injection은 주로 사용자 입력값을 검증하지 않고 SQL 문자열에 직접 결합할 때 발생한다.

Prepared Statement는 SQL 구조와 사용자 입력값을 분리하고 입력값을 파라미터로 바인딩하여 SQL Injection을 방지한다.

입력값 검증은 차단목록 방식보다 허용목록 방식을 적용하는 것이 바람직하다.

DB 권한 최소화는 SQL Injection이 발생하더라도 공격자가 수행할 수 있는 작업 범위를 제한하여 피해를 줄인다.

상세 SQL 오류 메시지는 DB 종류, 테이블명, 컬럼명, 쿼리 구조를 노출할 수 있으므로 사용자에게 표시하지 않아야 한다.

WAF는 SQL Injection 공격 패턴 탐지에 도움이 되지만, Prepared Statement와 입력값 검증 같은 시큐어 코딩을 대체할 수는 없다.

HTTPS는 통신 구간을 암호화하지만 SQL Injection 취약점 자체를 제거하지는 못한다.

저장 프로시저나 ORM을 사용하더라도 사용자 입력값을 원시 SQL 문자열에 직접 결합하면 SQL Injection이 발생할 수 있다.

SQL Injection 의심 시 웹 로그, WAF 로그, DB 로그를 분석하고 공격 차단, 영향 범위 확인, 취약점 수정, 재발 방지 조치를 수행해야 한다.

1. SQL Injection이란 무엇인가?
2. SQL Injection의 주요 발생 원인은 무엇인가?
3. SQL Injection으로 발생할 수 있는 피해 4가지를 쓰시오.
4. 인증 우회형 SQL Injection이란 무엇인가?
5. 오류 기반 SQL Injection이 위험한 이유는 무엇인가?
6. Blind SQL Injection이란 무엇인가?
7. SQL Injection이 발생하기 쉬운 입력 위치 5가지를 쓰시오.
8. SQL Injection 의심 로그의 특징 4가지를 쓰시오.
9. Prepared Statement란 무엇인가?
10. Prepared Statement가 SQL Injection 방어에 효과적인 이유는 무엇인가?
11. 입력값 검증이란 무엇인가?
12. 허용목록 방식과 차단목록 방식의 차이를 쓰시오.
13. DB 권한 최소화가 필요한 이유는 무엇인가?
14. 오류 메시지 노출 제한이 필요한 이유는 무엇인가?
15. WAF가 SQL Injection 대응에 어떻게 활용되는가?
16. WAF가 근본 대책이 아닌 이유는 무엇인가?
17. 저장 프로시저를 사용해도 SQL Injection이 발생할 수 있는 경우는?
18. ORM을 사용해도 SQL Injection이 발생할 수 있는 경우는?
19. HTTPS만으로 SQL Injection을 방어할 수 없는 이유는 무엇인가?
20. SQL Injection 사고 대응 절차를 간단히 쓰시오.

21. 사용자 입력값을 SQL 문자열에 직접 붙여 쿼리를 생성하고 있다.
22. 로그인 조건절이 조작되어 비밀번호 없이 로그인된 것으로 보인다.
23. 화면에 DB 테이블명과 컬럼명이 포함된 오류 메시지가 표시된다.
24. 검색 파라미터에 SQL 키워드와 특수문자가 반복적으로 포함되어 있다.
25. 쿼리 결과는 보이지 않지만 참·거짓 반응 차이로 정보가 추론된다.
26. SQL 구조와 입력값을 분리해 입력값을 데이터로만 처리하고 싶다.
27. 웹 애플리케이션 DB 계정이 모든 테이블 삭제 권한까지 가지고 있다.
28. 공격 패턴을 HTTP 요청 단계에서 탐지·차단하고 싶다.
29. HTTPS를 사용 중이지만 검색 기능에서 SQL Injection이 발생했다.
30. 저장 프로시저 내부에서 입력값을 문자열로 결합해 동적 SQL을 실행한다.

31. SQL Injection의 개념과 발생 원인을 설명하시오.

32. SQL Injection의 대응 방안을 설명하시오.

33. Prepared Statement가 SQL Injection 방어에 효과적인 이유를 설명하시오.

34. SQL Injection 대응에서 DB 권한 최소화가 필요한 이유를 설명하시오.

35. SQL Injection 공격이 의심될 때 대응 절차를 설명하시오.