SQLmap으로 SQL Injection 탐지 자동화하기

개념

시작하기 전에 — 레슨 10과 같은 경고

이 레슨의 도구는 반드시 자신이 소유했거나 명시적으로 테스트 허가를 받은 환경에서만 실행해야 한다. SQLmap은 레슨 10에서 사람이 손으로 하던 시도를 자동화·대량화한 도구이므로, 허가 없이 쓰면 그만큼 더 심각한 불법 행위가 된다.

레슨 10에서 손으로 하던 것을 도구가 대신한다

레슨 10에서 ' OR '1'='1, ' UNION SELECT ... 같은 페이로드를 하나씩 손으로 시도하고 에러 메시지를 관찰했다. SQLmap은 이 과정을 자동화한 전문 도구다.

sqlmap -u "https://test.example.com/search?q=노트북" --batch

이 한 줄이 내부적으로 하는 일은, 레슨 10의 표에서 사람이 하나씩 시도했던 것과 원리는 같지만 규모가 다르다.

1. 대상 파라미터(q)에 수십~수백 가지 SQL Injection 페이로드 변형을
   자동으로 순서대로 시도
2. 각 시도의 응답을 비교·분석해 정상 응답과 다른 패턴을 탐지
   (레슨 10의 "에러 기반 탐지"를 포함해, 화면에 아무 신호가 없어도
   응답 시간 차이로 탐지하는 블라인드 기법까지 포함)
3. 취약점이 확인되면, 그 뒤에 실제로 어떤 데이터베이스 종류
   (MySQL, PostgreSQL 등)인지, 어떤 테이블이 있는지까지 자동으로
   알아낼 수 있음

사람이 손으로는 발견하기 어려운 것 — 블라인드 SQL Injection

레슨 10에서 "화면에 신호가 없는 블라인드 SQL Injection은 더 찾기 어렵다"고 언급했다. SQLmap이 강력한 이유가 바로 이 지점이다 — 화면에 에러가 안 보여도, "참인 조건을 주면 응답이 0.1초, 거짓인 조건을 주면 5초"처럼 미묘한 응답 시간 차이를 수백 번 반복 요청해서 통계적으로 탐지해낼 수 있다. 사람이 손으로 수백 번 요청을 반복하며 시간을 재는 건 사실상 불가능하지만, 도구에게는 반복 작업일 뿐이다.

도구가 대신 못 하는 것 — 심각도 판단과 리포트

SQLmap이 취약점을 확인하고 데이터베이스 구조까지 알아내도, 그게 비즈니스적으로 얼마나 심각한지, 개발팀에 어떻게 전달할지는 여전히 사람의 몫이다.

SQLmap 결과: "users 테이블에서 데이터를 추출할 수 있음을 확인"
 
QA가 판단해야 할 것:
- users 테이블에 어떤 민감정보(비밀번호 해시, 개인정보)가 있는가?
- 이 파라미터가 로그인 없이도 접근 가능한 공개 API인가, 인증이
  필요한 내부 API인가?
- 레슨 10에서 배운 심각도 기준으로 볼 때 왜 Critical인지, 파급
  범위를 어떻게 설명할 것인가?

이건 모듈 18-C(AI 교차검증)에서 다룰 "AI/도구가 만든 결과를 검증 없이 신뢰하면 안 된다"는 원칙과 같은 구조다 — SQLmap도 사람 대신 판단해주는 게 아니라, 사람의 판단에 필요한 근거를 빠르고 정확하게 모아주는 도구일 뿐이다.

왜 도구를 배운 뒤에도 레슨 10의 수동 방식이 필요한가

SQLmap 같은 도구를 쓸 수 있다고 레슨 10의 수동 확인법을 몰라도 되는 게 아니다. 오히려 반대다 — 도구가 왜 그렇게 판단했는지 이해하려면, 사람이 손으로 했을 때 어떤 신호를 보는지 먼저 알아야 한다. 도구의 결과 리포트에 "Boolean-based blind" 같은 용어가 나왔을 때, 레슨 10에서 배운 개념이 없으면 그게 무슨 뜻인지조차 이해할 수 없다.

실무에서 왜 필요한가

전문 침투 테스터가 아닌 QA라도, 릴리스 전 SQLmap을 스테이징 환경의 주요 API에 한 번 돌려보는 것만으로 레슨 10의 수동 확인으로는 놓쳤을 블라인드 취약점을 잡아낼 수 있다. 다만 이 레슨의 핵심은 "도구를 켜고 결과를 그대로 복사해 리포트에 붙여넣는 것"이 아니라, 그 결과가 실제로 무엇을 의미하는지 레슨 10의 개념으로 해석하고, 심각도를 판단해 전달하는 것이다. 도구는 발견을 빠르게 해주고, 판단은 여전히 사람의 몫이라는 이 관계는 이 커리큘럼 전체가 반복해온 원칙이다.

실습 과제

과제 1 — 손으로 한 것과 도구가 한 것 비교하기 (10분)

레슨 10에서 손으로 시도했던 4가지 페이로드와, 이 레슨에서 배운 SQLmap의 자동 탐지 과정을 비교해, "사람이 하던 것 중 무엇을 도구가 대신하는지"와 "도구가 대신할 수 없는 것"을 각각 최소 2가지씩 적는다.

과제 2 — 리포트 완성하기 (12분)

"SQLmap으로 /api/products?category= 파라미터에서 Boolean-based blind SQL Injection이 확인됐고, 데이터베이스가 MySQL이며 orders 테이블이 존재한다는 것까지 알아냈다"는 상황에서, 이 발견을 레슨 10에서 배운 리포트 형식(재현 절차·실제 결과·기대 결과·심각도)으로 작성한다. 심각도 판단 근거에 "블라인드 방식이라 화면에는 아무 신호도 없었다"는 점을 어떻게 반영할지도 포함한다.

자가 체크리스트

• SQLmap이 레슨 10의 수동 시도를 자동화·대량화한 것이라는 관계를 설명할 수 있다
• 블라인드 SQL Injection이 무엇이고, 왜 사람이 손으로 찾기 어려운지 설명할 수 있다
• SQLmap이 대신해주는 것(탐지, 구조 파악)과 대신할 수 없는 것(심각도 판단, 리포트)을 구분할 수 있다
• 도구의 결과 리포트를 그대로 복사하지 않고, 사람이 해석해 전달해야 하는 이유를 설명할 수 있다
• 블라인드 취약점이 "발견하기 어려움 = 덜 위험함"이 아닌 이유를 설명할 수 있다

흔한 실수

• SQLmap 결과를 그대로 복사해 리포트로 제출한다. 도구 출력은 기술적 근거일 뿐, 비즈니스 영향과 심각도는 사람이 번역해야 개발팀과 관리자가 이해하고 우선순위를 정할 수 있다.
• 레슨 10의 수동 개념 없이 도구부터 배우려 한다. 도구가 왜 그렇게 판단했는지 이해하지 못하면, 도구가 실수했을 때(오탐)도 알아챌 수 없다.
• 허가 없는 환경에 SQLmap을 실행한다. 자동화된 대량 요청은 수동 시도보다 훨씬 공격적으로 보일 수 있고, 법적 문제도 더 커진다.
• 블라인드 취약점을 "화면에 아무 문제도 안 보이니 괜찮다"고 낮게 평가한다. 오히려 아무도 눈치 못 채고 오래 방치될 위험이라는 걸 기억해야 한다.

참고 자료

• SQLmap 공식 문서 — 사용법과 탐지 기법(Boolean-based, Time-based 등)의 공식 설명
• OWASP — Blind SQL Injection — 블라인드 SQL Injection의 공식 정의와 원리