14강 / 20강

SQL 인젝션 — 검색창으로 DB를 통째로

따옴표 하나가 여는 문, 그리고 준비된 질의

13강의 원칙 — "입력을 문장으로 해석하지 마라" — 를 가장 유명하게 어긴 사례가 SQL 인젝션입니다. 검색창이나 로그인창에 넣은 값이 DB 질의(SQL)의 일부로 해석되면서, 공격자가 DB에게 직접 명령을 내리게 됩니다.

이번 강의는 실제로 우리 쇼핑몰 검색창을 뚫어 회원 정보를 빼내 본 뒤, 막습니다.

고등학생따옴표 하나가 여는 문

13강의 원칙을 가장 유명하게 어긴 사례입니다.

입력이 SQL 문장의 일부가 되면 — 무엇이든 할 수 있다

어떻게 일어나나

query = "SELECT * FROM users WHERE name = '" + 입력 + "'"

입력이 ' OR '1'='1 이면?

SELECT * FROM users WHERE name = '' OR '1'='1'

조건이 항상 참이 된다 — 전부 조회된다 ⚠

할 수 있는 일

—	—
인증 우회	비밀번호 없이 로그인
전체 자료 조회	UNION 으로
변조 · 삭제	권한이 있으면 ⚠
파일 읽기 · 명령 실행	DB 설정에 따라

9강의 최소 권한이 여기서 피해를 줄인다

왜 아직도 이 취약점이 있나

이유	—
20년 넘게 알려진 문제인데	—
문자열을 이어 붙이는 것이 편해서	⚠
동적 쿼리가 필요할 때	정렬 열 이름 등

"편해서" 가 가장 흔한 이유다

고등학생준비된 질의가 막는 방식

해결책의 원리를 봅시다.

SQL 구조를 먼저 보내고 값은 나중에 보낸다

두 단계로 나뉩니다

단계	—
1	DB 가 `SELECT … WHERE name = ?` 를 먼저 해석
2	값을 따로 전달
결과	값은 문장이 될 수 없다 ✔

구조가 이미 굳었으니 값이 구조를 못 바꾼다

문자열 이어 붙이기와의 차이

—	이어 붙이기	준비된 질의
DB 가 받는 것	완성된 문장 ⚠	틀 + 값 ✔
값이 문장이 되나	된다	안 된다

이스케이프보다 근본적이다 — 구조 자체가 다르다

⚠ 준비된 질의로도 못 막는 것

—	—
테이블·컬럼 이름	파라미터로 못 넣는다 ⚠
ORDER BY 컬럼	—

이런 것은 화이트리스트로 처리한다 — 13강

허용 = {"name", "date", "price"}
if 정렬열 not in 허용: 거부

"목록에 있는 것만" — 우회할 방법이 없다 ✔

ORM 도 만능은 아닙니다

—	—
대부분 안전하다	✔
그런데 raw SQL 기능이 있다	거기서 뚫린다 ⚠

도구를 쓴다고 자동으로 안전해지지 않는다

따옴표 하나로 문장을 깬다

검색창에 '(따옴표) 하나만 넣어 봅시다. 앱이 이걸 문장에 그대로 이어 붙이면 SQL 문법이 깨져 오류가 나요. 공격자에게 이 오류는 "여기 인젝션 된다"는 신호입니다.

실습실에서 준비된 질의를 끈 상태로 아래 순서를 시도해 보세요.

' — 문장이 깨져 오류 (탐색)
' OR '1'='1 — 조건이 항상 참 → 전체 상품이 다 나옴
' UNION SELECT email, password FROM users -- — 회원 표가 상품 자리에 나옴 😱

마지막 것이 실제 유출 사고의 모습입니다. 상품을 검색했는데 회원 이메일과 비밀번호 해시가 쏟아져 나오는 거죠.

공격 문자열이 만들어 내는 SQL 을 직접 봅니다.

Python 브라우저 안에서 실행 (계산용)

# 왜 ' OR '1'='1 이 통하는지, 만들어지는 문장을 보면 명확합니다
for inp in ["mango", "' OR '1'='1", "' UNION SELECT email,password FROM users -- "]:
    q = "SELECT * FROM products WHERE name = '" + inp + "'"
    print(f"입력: {inp}")
    print(f"  → {q}")
    print()
print("입력이 문장 구조 자체를 바꿔 버립니다. 이것이 인젝션입니다.")

고등학생sqlmap — 공격은 이미 자동화되어 있습니다

note 의 이 이야기가 현실을 보여 줍니다.

공격 도구가 공개돼 있다 — 실력이 필요 없다

자동화 도구가 하는 일

단계	—
1	파라미터마다 탐침을 넣는다
2	응답 차이로 취약점을 판단
3	DB 종류를 알아낸다
4	테이블·자료를 자동으로 덤프 ⚠

사람은 주소만 입력하면 된다

블라인드 인젝션

오류 메시지가 안 보여도 뚫립니다.

방법	—
참/거짓 차이	페이지가 달라지는지 본다
시간 지연	"참이면 5초 기다려라" ⭐

응답이 느려지는 것만으로 한 비트씩 알아낸다

느리지만 자동화돼 있으니 시간은 문제가 안 됩니다.

그래서 오류 숨기기는 보조일 뿐

조치	효과
오류 메시지 숨기기	느리게 할 뿐 ⚠
준비된 질의	근본 해결 ✔

2강의 버전 숨기기와 같은 성격 — 보조는 보조다

방어자도 확인해 봐야 합니다

—	—
내 서버에 도구를 돌려 본다	공격자보다 먼저 찾는다 ✔
단	내 것에만 — 1강의 원칙 ⚠

준비된 질의를 켰는지에 따라 결과가 갈립니다.

🥷 공격자 브라우저 안에서 실행 (계산용)

# 공격자가 자동 도구로 우리 검색 파라미터를 훑습니다 (시뮬레이션)
sqlmap -u "http://mallshop.kr/products?id=1"

근본 해결 — 준비된 질의(placeholder)

필터링으로 위험한 글자를 막으려는 시도는 늘 뚫립니다(우회가 무한해요). 정답은 구조적으로 데이터와 명령을 분리하는 것 — 준비된 질의입니다.

위험 — 이어 붙이기

"...name = '" + 입력 + "'"

입력이 문장이 됨

안전 — placeholder

"...name = ?", (입력,)

입력은 값으로만 들어감

준비된 질의에서는 DB가 문장 구조를 먼저 정하고, 입력은 나중에 값 자리에만 채웁니다. 따옴표를 아무리 넣어도 '그런 이름의 상품 없음'이 될 뿐, 문장이 안 바뀌어요.

고등학생여러 겹으로 막기

14강을 마치며 층별 방어를 정리합시다.

층	조치	강도
코드	준비된 질의 · ORM	필수 ⭐
입력	타입·범위 검증	보조
DB 권한	최소 권한 (9강)	피해 축소 ⭐
WAF	패턴 차단	보조 · 시간 벌기
탐지	이상 쿼리 로그 (18강)	—

1번이 없으면 나머지로 못 막는다 — 순서가 있다

DB 권한이 왜 그렇게 중요한가

앱 계정 권한	뚫렸을 때
전체	테이블 삭제 · 파일 읽기 ⚠
SELECT·INSERT 만	조회 · 추가만 ✔
읽기 전용 (조회 화면)	변조 불가 ✔

같은 취약점인데 피해가 다르다 — 9강의 심층 방어

WAF 의 한계

—	—
패턴을 맞히면 막는다	—
우회 방법이	계속 나온다 ⚠

13강의 블랙리스트 한계 그대로다 — 근본 해결이 먼저다

다만 WAF 는 패치할 시간을 버는 데 유용합니다. 새 취약점이 발표됐을 때요.

임시 방어와 근본 수정은 역할이 다르다 — 둘 다 필요하다

🤔 확인 문제

SQL 인젝션의 근본 해결책은?

🤔 확인 문제

웹 앱 DB 계정에서 DROP·GRANT 권한을 뺐습니다(9강). SQL 인젝션이 성공하면?