SQL Injection

Portswigger 에서 제공하는 SQL Injection 학습 및 Lab 실습을 마쳤다.

 

2025 SQL 현재 동향

"요즘도 SQL Injection이 쓰일까?" 6의 예방법을 학습하면서 이런 생각이 들었다. Prepared Statement, ORM, WAF가 널리 사용되면서 이미 사라진 취약점처럼 느껴졌다. 이렇게 간단하게 방어가 되는 공격이라면, 예전은 몰라도 이제는 많이 사용 되지 않을 것 같았다. 그래서 요즘의 SQL Injection은 어떤 식으로 인식 되고 있는지 동향을 살펴봤다. 확실히 “옛날 공격 기법”이라는 인식이 점점 강해지고 있었다. 

 

하지만 실제 통계를 보면, SQL Injection은 지금도 현업에서 꾸준히 발견되고 있었다. 국내 보안업체 Monitorapp의 2025년 웹 공격 동향 보고서에 따르면[1], SQL Injection은 전체 웹 공격 트래픽 중 약 25~37%를 차지하는 것으로 분석된다. 특히 보고서에 따르면, 복잡한 UNION 쿼리보다 True or False로 비교적 단순한 Blind SQL을 자동화하여 대량 공격에서 종종 쓰이는 것 같다. 또 Blind SQLi은 공격 패턴이 아니라 '논리 조건'에 가까워 보이기 때문에 WAF에서 차단하기 힘든 것도 한 몫하는 것 같다.

 

또한, Aikido Security가 공개한 분석[2]에 따르면, SQL Injection은 전체 취약점 중에서 차지하는 비율은 감소했지만 완전히 사라지지는 않았다. 오픈소스 소프트웨어 취약점 중 약 6.7%, 클로즈드 소스(상용 소프트웨어)에서는 약 10% 가 발견되었다. 즉, 최신 프레임워크 환경에서는 줄었지만 레거시 코드, 커스텀 SQL, 내부 시스템에서는 여전히 발견된다.

 

여담으로, OWASP Top 10[3]에서는 과거처럼 “SQL Injection 단독 항목”이 아니라 Injection 카테고리로 통합되어 관리되고 있다. 이는 SQLi가 사라졌기 때문이 아니라, SQL Injection, Command Injection, LDAP Injection 등이 공통적인 설계 결함에서 발생하기 때문이다. 즉, 위험도가 낮아진 것이 아니라 분류 방식이 바뀐 것에 가깝다.

 

결과적으로, SQL Injection은 여전히 상용 웹사이트 10% 정도에서는 발견되는 취약점이며, 사라지지 않았다. 좀 더 자세하게는,

  • UNION SQLi는 줄었지만, Blind / Time-based SQLi는 여전히 현실적이며
    • 이유1: 간략성 때문에 대량 공격에 종종 사용
    • 이유2: 정상적인 논리조건과 같은 생김새 때문에서 WAF에서 차단 힘듬
  • 레거시·API·관리 페이지에서는 계속 발견된다

Reference

+ Recent posts

티스토리툴바