오늘 끝나면
SQL 인젝션
- ✓SQL 인젝션의 핵심 문제를 한 문장으로 설명한다
- ✓오른쪽 실습에서 SQL이 어떻게 움직이는지 관찰한다
- ✓다음 강의와 이어지는 한계를 말할 수 있다
실습 미션
입력 한 줄로 쿼리를 비트는 원리 이 문장이 실제로 무슨 뜻인지 실습에서 한 번 손으로 확인한다.
성공 조건
- □실습의 기본값을 먼저 관찰
- □입력값이나 모드를 한 번 이상 바꿔 결과 비교
- □왜 결과가 바뀌었는지 한 문장으로 설명
화이트해킹 · 05
SQL
인젝션
입력을 쿼리에 그대로 붙이면 입력이 쿼리 구조를 바꿈.
따옴표 한 개로 조건을 참 만들어 로그인을 우회함.
근본 방어는 입력을 코드와 안 섞는 것임.
입력이 쿼리가 된다
서버는 로그인할 때 DB에 물어봄. “이 아이디·비번 맞는 사람 있냐”고. 그 질문이 SQL 쿼리임.
많은 코드가 쿼리를 이렇게 만듦. "... pw = '" + 입력 + "'" / 사용자가 친 글자를 쿼리 문자열에 그대로 이어붙임.
문제는 여기서 시작됨. 쿼리 한 줄 안에 데이터(비번 값)와 명령(SELECT, WHERE)이 같은 문자열로 섞여 있음.
DB는 둘을 구분 못 함. 따옴표가 닫히는 순간 그 뒤 글자를 명령으로 읽음.
즉 입력이 데이터에 머물지 않고 쿼리의 구조가 되어 버림.
"... pw = '" + 입력+ "'"
WHERE id = 'admin' AND pw = '1234'
따옴표로 조건을 참으로
공격자는 비번 칸에 비번을 안 적음. 대신 x' OR '1'='1 같은 글자를 넣음.
이게 쿼리에 붙으면 pw = 'x' OR '1'='1'이 됨. 앞쪽 따옴표가 비번 문자열을 일찍 닫고, 그 뒤 OR '1'='1'이 새 조건으로 끼어듦.
1=1은 언제나 참임. 조건이 OR로 묶여서 비번이 틀려도 전체가 참이 됨.
DB는 시키는 대로 “조건 맞는 행”을 돌려줌 → 비번을 몰라도 로그인 통과.
입력 한 줄로 인증을 우회한 것임. 이게 SQL 인젝션의 핵심 장면임.
pw = 'x' OR '1'='1'
| pw = '1234' | 거짓 |
| '1' = '1' | 참 |
| 거짓 OR 참 | 참 |
전체가 참 → 비번 몰라도 통과
원인 — 신뢰 못 할 입력
버그는 따옴표가 아니라 가정에 있음. 코드가 입력을 “얌전한 값”이라고 믿은 것임.
입력은 사용자 손에서 옴 / 그 손이 공격자일 수 있음. 따옴표·세미콜론·SQL 키워드를 섞어 보낼 수 있음. 통제 못 하는 바깥에서 오는 모든 입력은 일단 의심해야 함.
그래서 인젝션은 한 종류가 아님. 입력을 명령에 그대로 섞는 곳마다 생김 / SQL은 DB에, 셸 명령은 OS에, HTML은 브라우저(다음 강 XSS)에.
공통 패턴은 하나임 — 신뢰 못 할 입력이 명령으로 해석됨.
그러니 막는 법도 하나로 모임. 입력을 명령과 못 섞이게 떼어놓는 것임.
따옴표·키워드 섞어 보낼 수 있음
여기 들어오면 코드로 실행됨
경계를 넘는 입력을 검사 없이 명령에 섞으면 = 인젝션. SQL · 셸 · HTML 다 같은 구조임.
직접 — 쿼리가 바뀌는 걸 본다
오른쪽에서 직접 해봄. 실제 DB 아님 / 입력이 어떤 쿼리를 만드는지 보여주는 가상 시뮬임.
문자열 이어붙이기 모드에서 비번 칸에 x' OR '1'='1을 넣어 보셈. 만들어진 쿼리에서 그 부분이 강조되고 결과가 인증 우회로 바뀜.
이제 파라미터 바인딩 모드로 토글해 봄. 같은 입력인데 쿼리가 pw = ?로 바뀌고 입력은 그냥 값으로 들어감 → 막힘.
입력을 코드에 붙이느냐, 값으로 떼어놓느냐 — 그 한 끗 차이를 손으로 느끼는 칸임.
SELECT * FROM users WHERE id = 'admin' AND pw = 'x' OR '1'='1'
비번 칸의 따옴표가 문자열을 닫고, OR '1'='1'이 새 조건이 됨. 입력이 코드가 된 것임.
조건이 항상 참(1=1)이라 비번을 몰라도 통과함. 입력을 쿼리에 그대로 붙인 게 원인임.
방어 — 파라미터 바인딩
근본 방어는 단순함. 입력을 쿼리 문자열에 붙이지 말고, 쿼리는 미리 짜두고 값만 따로 넘기는 것임.
쿼리에 ? 자리표시자를 두고 WHERE id = ? AND pw = ?처럼 구조를 먼저 고정함. 그 다음 입력을 자리표시자에 “값”으로 묶어 보냄.
이걸 파라미터 바인딩(prepared statement)이라 함.
이러면 입력에 따옴표를 백 개 넣어도 쿼리 구조는 안 바뀜 / DB가 그걸 명령이 아니라 비번 글자로만 봄. 인젝션이 원천 차단됨.
보조로 입력 검증·최소권한 계정·에러 메시지 숨기기를 겹치면 더 단단함. 핵심은 바인딩임 — 코드와 데이터를 섞지 않는 것.
Q. SQL 인젝션의 근본 방어는? (입력에서 따옴표 지우기 · 파라미터화 쿼리로 입력을 코드와 안 섞기 · 비번 길게 받기 · 관리자 페이지 숨기기)
정답은 파라미터화 쿼리로 입력을 코드와 안 섞기임.따옴표만 지우면 다른 트릭으로 우회됨 / 비번 길이·페이지 숨김은 인젝션과 무관함.
입력을 쿼리 문자열에 붙이는 한 위험은 남음. 자리표시자 ?로 입력을 값에 가두면 구조가 안 바뀜.
한 줄로 — 코드와 데이터를 분리하면 인젝션이 사라짐.
WHERE id = ? AND pw = ?
? = "x' OR '1'='1"
따옴표째 비번 '값'으로 비교됨 → 안 맞음
입력이 쿼리 구조를 못 바꿈. 코드와 데이터가 분리됨.