SQL 인젝션 (SQL Injection)
쉽게 풀면
우체국 접수증의 "받는 사람" 칸에 원래는 사람 이름만 적어야 하는데, 누군가 그 칸에 "홍길동, 그리고 창고에 있는 소포를 전부 나에게 보내줘"라고 적어 넣었다고 생각해봅시다. 접수 직원이 이 문장을 "이름"이 아니라 실제 "지시사항"으로 착각하고 그대로 실행해 버리면 큰 문제가 생깁니다. SQL 인젝션도 마찬가지입니다. 프로그램이 로그인 아이디나 검색어처럼 사용자가 입력한 문자열을 "그냥 데이터"로만 다뤄야 하는데, 이를 SQL 명령문 안에 그대로 이어 붙여버리면, 입력값 속에 숨겨둔 명령어가 진짜 SQL 명령의 일부로 실행되어 버립니다. 그 결과 로그인 검증을 우회하거나, 다른 사용자의 정보를 몰래 조회하거나, 데이터베이스 전체를 삭제하는 일까지 벌어질 수 있습니다.
왜 중요한가
SQL 인젝션은 웹 애플리케이션 보안 취약점 중 가장 오래되고 파급력이 큰 유형에 속해, 웹 보안·소프트웨어 공학·정보보호 분야 논문에서 취약점 탐지 기법이나 방어 기법을 평가하는 대표 사례로 자주 다루어집니다. 실제 서비스에서 데이터 유출 사고의 주요 원인으로 반복적으로 보고되기 때문에, 자동화된 취약점 스캐너나 정적 분석 도구의 성능을 검증하는 벤치마크로도 널리 활용됩니다. 이런 배경에서 SQL 인젝션 탐지·방어는 보안 연구와 실무 양쪽에서 꾸준히 다뤄지는 주제입니다.
논문에서는 이렇게 쓰입니다
이 문장은 사용자 입력을 그대로 SQL 명령에 끼워 넣는 방식이 보안에 위험하다는 것을 실험으로 보이고, 입력값과 명령어를 분리해서 처리하는 방어 기법을 적용해 문제를 해결했다는 뜻입니다.
보안·머신러닝 융합 논문에서는 정규표현식 같은 규칙 기반 탐지 대신 기계학습 모델로 악성 쿼리 패턴을 학습시켜 SQL 인젝션을 자동으로 걸러내는 접근을 다루는 경우가 많습니다.
조금 더 깊게 보면
SQL 인젝션에는 오류 메시지를 통해 정보를 알아내는 방식, 참/거짓 결과의 차이를 이용하는 블라인드 인젝션, 응답 시간 차이를 이용하는 시간 기반 블라인드 인젝션 등 여러 변형이 있어 방어 전략도 그에 맞춰 다양하게 논의됩니다. 근본적인 방어책으로는 입력값과 명령어를 분리하는 매개변수화된 쿼리 외에도, 데이터베이스 계정에 최소한의 권한만 부여하는 최소 권한 원칙, 그리고 웹 애플리케이션 방화벽(WAF)을 이용한 이상 패턴 탐지가 함께 언급되는 경우가 흔합니다.
주의할 점
SQL 인젝션은 입력 길이를 제한하거나 특수문자 일부만 걸러내는 방식으로는 완전히 막을 수 없다. 사용자 입력과 SQL 명령을 근본적으로 분리하는 준비된 문장(prepared statement)이나 매개변수화된 쿼리(parameterized query)를 사용해야 하며, 암호화는 저장된 데이터 자체를 보호하는 기법일 뿐 SQL 인젝션 공격 자체를 막아주지는 않는다는 점을 혼동하지 말아야 한다.