로그인 기능이나 검색 기능에서 입력값 검증이 제대로 이루어지지 않는다면 어떤 일이 발생할까요? 단 한 줄의 악의적인 SQL 구문만으로도 공격자는 데이터베이스에 저장된 정보를 탈취할 수 있습니다. SQL 인젝션은 오랜 기간 잘 알려진 공격 기법이지만, 여전히 실제 보안 사고의 주요 원인으로 작용하고 있습니다. 이번 글에서는 SQL 인젝션의 개념부터 공격 시나리오, 그리고 대응 방안까지 정리해보겠습니다.
■ SQL 인젝션(SQL Injection)이란?
SQL 인젝션은 악의적인 SQL질의문을 삽입해 데이터베이스(DB)가 의도되지 않은 비정상적 동작을 하도록 조작하는 공격 기법입니다.
웹 애플리케이션에서 입력된 데이터에 대한 입력값 검증을 하지 않을 경우, 공격자가 입력 폼 및 URL 입력란을 통한 입력값에 SQL 문을 삽입해 DB로부터 정보를 열람하거나 악의적인 쿼리를 실행할 수 있습니다.
취약한 웹 애플리케이션에서는 사용자로부터 입력된 값을 필터링 과정 없이 넘겨받아 동적쿼리(Dynamic Query)를 생성하기 때문에 개발자가 의도하지 않은 쿼리가 생성되어 정보 유출에 악용될 수 있습니다.
■ SQL 인젝션은 어디에서 주로 발생할까?
SQL 인젝션은 사용자 입력값이 데이터베이스 쿼리에 직접 사용되는 모든 기능에서 발생할 수 있습니다. 특히 웹 애플리케이션의 입력/조회 기능에서 발생 가능성이 높습니다.
1️⃣ 로그인/인증 기능
아이디·비밀번호 입력값이 검증없이 SQL 쿼리에 직접 사용되는 경우, 공격자가 인증 우회 구문을 삽입하여 로그인 우회 공격을 수행할 수 있고 심한 경우 관리자 계정 탈취로 이어질 수도 있습니다.
2️⃣ 검색 기능
검색어 입력값이 검증없이 SQL 쿼리에 그대로 포함되는 경우, 공격자가 조건 조작 구문을 삽입하여 의도하지 않은 데이터 조회를 수행할 수 있습니다. 이를 통해 공격자는 전체 게시글 조회, 특정 정보 노출 등이 가능해집니다.
3️⃣ 게시판 / 댓글 / 입력 폼
게시글, 댓글, 문의 등 사용자 입력값을 저장하거나 조회하는 기능에서도 입력값 검증이 미흡한 경우, 공격자가 SQL 구문을 삽입하여 데이터 조회·변조 등의 공격을 수행할 수 있습니다.
4️⃣ 관리자 기능
관리자 페이지의 검색/수정/삭제 기능에서 입력값 검증이 부족할 경우 대량 데이터 조회, 데이터 수정·삭제 등의 공격으로 이어질 수 있습니다.
■ SQL 인젝션 공격은 어떻게 동작할까? (공격 시나리오)
⚠️ 인증 우회
다음과 같이 웹 애플리케이션에서 사용자 입력값을 기반으로 로그인 검증을 수행하는 기능이 있을 때, 정상적으로는 아이디와 비밀번호가 일치해야 로그인에 성공합니다.
|
SELECT * FROM users |
하지만 공격자가 비밀번호 입력값에 다음과 같은 문자열을 삽입하면
| ‘ OR ‘1’=’1 |
실제 실행되는 쿼리는 다음과 같이 변경됩니다.
|
SELECT * FROM users |
따라서 ‘1’=’1′ 조건이 항상 참(True)이 되면서 비밀번호 검증 없이 로그인 우회가 발생할 수 있습니다.
⚠️ 데이터 조회 우회 (조건 무력화)
다음과 같이 사용자별 데이터를 조회하는 기능이 있습니다.
|
SELECT * FROM items |
공격자가 itemname 값에 다음과 같은 공격을 입력합니다.
| name’ OR ‘a’=’a |
쿼리는 다음과 같이 변경됩니다.
|
SELECT * FROM items |
따라서 조건이 항상 참이 되어 특정 사용자 데이터뿐 아니라 전체 데이터 조회가 가능해집니다.
■ SQL 인젝션 대응 방안은?
1️⃣ Prepared Statement
사용자 입력값을 SQL 쿼리와 분리해 처리하는 방식입니다. 입력값이 쿼리 구조를 변경하지 못하도록 차단하며 SQL 인젝션 방어의 가장 기본이자 핵심 방법입니다.
|
PreparedStatement pstmt = conn.prepareStatement( |
2️⃣ 입력값 검증
사용자 입력값에 대해 허용된 값만 처리하도록 제한합니다.
- 특수문자 제한 (‘, “, –, ; 등)
- 길이 제한
- 숫자/문자 타입 검증
3️⃣ 최소 권한 원칙 적용
웹 애플리케이션과 관리자 계정을 분리하고, 최소 권한만 부여해야 합니다. 계정이 탈취되더라도 제한된 권한으로 인해 데이터베이스 전체를 장악하기 어렵고 피해 범위를 최소화할 수 있습니다.
■ SQL 인젝션 대응은 스패로우의 애플리케이션 보안 테스팅 도구와 함께!
SQL 인젝션을 예방하기 위해서는 개발 단계와 운영 단계에서 지속적인 보안 점검이 필요하며, Sparrow SAST와 DAST 도구를 활용하면 SQL 인젝션 취약점을 탐지, 예방할 수 있습니다.
🔴 소스코드 보안 약점 분석 도구, Sparrow SAST
✅ 주요 점검 방식
Sparrow SAST는 아래와 같은 경우에 SQL 인젝션이 발생할 수 있는 취약한 소스코드를 검출합니다.
– 사용자 입력값이 검증 없이 SQL 쿼리에 사용되는 경우
– 문자열 결합 방식으로 SQL 쿼리를 생성하는 경우
– 쿼리 실행 메서드에 외부 입력값이 직접 전달되는 경우
– Prepared Statement를 사용하지 않는 경우
✅ 조치 가이드 제공
Sparrow SAST는 SQL인젝션을 발생할 수 있는 위험한 예시, SQL 인젝션을 예방할 수 있는 안전한 예시를 제공합니다. 또한 SQL 인젝션을 조치할 수 있는 소스코드 수정 방법을 제안해 SQL 인젝션 취약점을 효율적으로 조치할 수 있도록 지원합니다.
✅ 활용 방안
소스코드 개발 단계에서 주기적으로 Sparrow SAST 점검을 수행하여, SQL 인젝션을 발생시킬 수 있는 소스코드를 식별하고 수정해야 합니다. 또한 GitLab과 같은 형상관리 도구, Jenkins와 같은 빌드·배포 도구와 연동해 SQL 인젝션이 발생 가능한 취약한 소스코드를 형상관리 이관제어 및 배포제어 하도록 구성할 수 있습니다.
🟠 웹 애플리케이션 취약점 동적 분석 도구, Sparrow DAST
✅ 주요 점검 방식
Sparrow DAST는 실행 중인 웹 애플리케이션의 입력폼, URL 파라미터, API 요청 등 입력값이 존재하는 요청에 다양한 SQL 인젝션 페이로드를 삽입하여 요청을 수행하고, 응답을 분석하여 취약점을 식별합니다.
✅ 분석 정보 제공
실제로 수행하는 공격 방식과 그 결과를 확인하여, 운영 중인 서비스가 어떠한 방식의 공격에서 취약한지와 어떤 부분을 보완해야 하는지 정보를 제공합니다.
✅ 활용 방안
개발 배포 환경이나 운영 배포 환경에서 Sparrow DAST 점검을 수행하여 실제 서비스 중인 웹 애플리케이션에 존재하는 SQL 인젝션 취약점을 식별합니다. 특히, 개발 배포 단계에서 Sparrow DAST를 활용해 취약점을 미리 식별하고 조치하면 운영 배포 서비스에서 발생할 수 있는 SQL 인젝션 보안 사고를 예방할 수 있습니다.
SQL 인젝션은 가장 오래되었지만 여전히 가장 위험하고 널리 악용되는 웹 보안 취약점 중 하나입니다. 그러나 대부분 복잡한 공격이 아니라, 기본적인 입력값 처리 방식에서 발생합니다. 즉, 올바른 쿼리 작성과 입력값 검증만으로도 충분히 예방 가능한 취약점입니다. 따라서 개발 단계에서 안전한 코딩 방식을 적용하고, 코드 리뷰 및 보안 점검을 병행해 SQL 인젝션에 대응해보시길 바랍니다.
▶️ Sparrow SAST 바로가기 : https://sparrow.im/kr/product/sast/
▶️ Sparrow DAST 바로가기 : https://sparrow.im/kr/product/dast/
FAQ – SQL 인젝션에 대해 자주 묻는 질문
Q1. SQL 인젝션이란 무엇인가요?
A. SQL 인젝션은 공격자가 악의적인 SQL 질의문을 삽입해 데이터베이스가 의도하지 않은 동작을 하도록 조작하는 공격 기법입니다.
Q2. SQL 인젝션은 어디에서 주로 발생하나요?
A. SQL 인젝션은 로그인, 검색, 게시판, 댓글, 입력 폼, 관리자 기능처럼 사용자 입력값이 데이터베이스 쿼리에 직접 사용되는 기능에서 발생할 수 있습니다.
Q3. SQL 인젝션 공격 시나리오에는 어떤 것이 있나요?
A. 대표적인 SQL 인젝션 공격 시나리오로는 비밀번호 검증을 우회하는 인증 우회 공격과, 조건을 무력화해 전체 데이터를 조회하는 데이터 조회 우회 공격이 있습니다.
Q4. SQL 인젝션 대응 방안은 무엇인가요?
A. SQL 인젝션 대응을 위해서는 Prepared Statement 사용, 입력값 검증, 최소 권한 원칙 적용, 개발·운영 단계의 지속적인 보안 점검이 필요합니다.
