[PYTHON] Raw SQL 사용 시 SQL Injection 3가지 완벽 해결 방법 및 ORM과의 차이

SQL Injection

 

 

현대의 웹 애플리케이션 개발에서 Django ORM이나 SQLAlchemy와 같은 객체 관계 매핑(ORM) 도구는 생산성을 비약적으로 향상시켜 주는 필수적인 존재입니다. ORM은 기본적으로 SQL Injection(SQL 인젝션) 공격에 대한 강력한 방어 기제를 내장하고 있어, 대다수의 일상적인 데이터베이스 작업은 보안 걱정 없이 수행할 수 있습니다. 하지만 실제 대규모 서비스나 레거시 시스템을 다루다 보면, 통계 쿼리나 복잡한 JOIN, 윈도우 함수 등을 ORM으로 표현하기엔 성능이 터무니없이 낮거나 구현 자체가 불가능한 상황에 직면하게 됩니다. 이때 우리는 최적의 성능을 위해 Raw SQL(직접 작성한 SQL)이라는 강력하지만 위험한 칼을 뽑아 들게 됩니다. 오늘 이 글에서는 파이썬 백엔드 엔지니어의 숙명과도 같은 '복잡한 Raw SQL 쿼리 작성 시 SQL Injection 공격을 어떻게 완벽하게 방어할 것인가'에 대한 실무적인 해결책을 심층적으로 다룹니다.

---

1. SQL Injection 공격의 근본적인 원인과 파이썬에서의 위협

SQL 인젝션 공격은 사용자가 입력한 데이터가 쿼리 구조의 일부로 오해받아 실행되는 보안 취약점입니다. 가장 흔하지만 치명적인 실수 중 하나는 파이썬의 문자열 포맷팅(f-string, %)을 사용하여 쿼리문을 동적으로 생성하는 것입니다.

위험한 f-string 포맷팅 예시

# 매우 위험한 방식 - 절대 사용 금지!
user_id = "1 OR 1=1"
query = f"SELECT * FROM users WHERE id = {user_id}"
# 실제 실행되는 쿼리: SELECT * FROM users WHERE id = 1 OR 1=1
# 모든 사용자 정보가 유출됩니다.

---

2. ORM vs Raw SQL: 보안과 성능의 트레이드오프 비교

N+1 문제 해결 등 복잡한 요구사항을 맞추기 위해 Raw SQL을 선택할 때, 우리는 보안성을 ORM 수준으로 유지해야 하는 과제를 안게 됩니다. 두 방식의 보안성 차이를 표로 정리했습니다.

비교 항목	ORM (Django, SQLAlchemy)	Raw SQL (cursor.execute)
보안성 (SQL Injection)	기본적으로 Parameterized Query를 사용하여 매우 안전함	개발자가 직접 파라미터 바인딩을 구현해야 하므로 주의 필요
복잡한 쿼리 구현	구현이 어렵거나 성능 최적화가 힘들 수 있음	성능 최적화 및 복잡한 기능 구현 용이
보안 해결 방법	프레임워크가 자동 해결	개발자가 3가지 대책을 직접 적용

---

3. Raw SQL 사용 시 SQL Injection 3가지 완벽 해결 방법 (대책)

복잡한 Raw SQL을 안전하게 작성하기 위해 파이썬 엔지니어가 반드시 숙지해야 할 3가지 핵심 보안 대책입니다.

해결 방법 1: Parameterized Query (파라미터 바인딩) - 최고의 해결책

파이썬의 데이터베이스 드라이버(psycopg2, mysqlclient 등)는 쿼리와 데이터를 분리하여 서버에 전송하는 기능을 제공합니다. 이를 매개변수화된 쿼리 또는 플레이스홀더(Placeholder) 사용이라고 합니다. 이 방식을 사용하면 사용자가 입력한 데이터는 SQL 엔진에서 쿼리 구조가 아닌 '순수한 데이터'로만 취급되므로, 악의적인 SQL 문법이 포함되어 있더라도 실행되지 않습니다.

[Sample Example] Django에서 안전한 Raw SQL 작성

from django.db import connection

def get_active_user_products(username, category):
    # f-string 대신 %s 플레이스홀더 사용
    query = """
        SELECT p.id, p.name
        FROM products p
        JOIN users u ON p.owner_id = u.id
        WHERE u.username = %s AND p.category = %s AND u.is_active = TRUE
    """
    with connection.cursor() as cursor:
        # 두 번째 인자로 튜플 또는 리스트 형태로 파라미터 전달 (드라이버가 안전하게 바인딩)
        cursor.execute(query, [username, category])
        results = cursor.fetchall()
    return results

※ 주의: 플레이스홀더 문법은 DB 드라이버마다 다를 수 있습니다. (PostgreSQL: %s, SQLite/MySQL: ?, Oracle: :name 등)

해결 방법 2: 엄격한 입력 데이터 유효성 검사 (Validation)

파라미터 바인딩을 사용하더라도, 입력 데이터 자체의 형식을 검증하는 것은 보안의 기본입니다. Django Form이나 Pydantic과 같은 라이브러리를 활용하여 데이터 타입을 강제하고, 허용된 문자열 패턴(정규표현식 등)만 통과시켜 비정상적인 데이터의 유입을 원천 차단합니다.

해결 방법 3: 데이터베이스 식별자(Identifier) 바인딩 해결책

테이블명이나 컬럼명처럼 SQL 문법 자체를 동적으로 변경해야 하는 상황은 매우 드물지만, 이를 Parameterized Query (%s)로 처리할 수는 없습니다. (데이터 드라이버는 식별자 바인딩을 지원하지 않음) 이런 복잡한 해결 상황에서는 White-list (허용 목록) 방식을 적용해야 합니다. 입력받은 식별자가 미리 정의된 안전한 목록에 포함되어 있는지 확인한 후, 포함된 경우에만 쿼리에 문자열 포맷팅으로 삽입합니다. 또는 SQLAlchemy의 text()와 같은 도구를 활용하여 식별자를 안전하게 인용(Quoting) 처리합니다.

---

4. 내용의 출처 및 참고 문헌

• Django Project Documentation: "Database access - Security against SQL injection"
• SQLAlchemy Documentation: "SQL Expression Language Tutorial - Parameterized Query"
• OWASP (Open Web Application Security Project): "SQL Injection Prevention Cheat Sheet"
• MySQL Developer Guide: "Prepared Statements and SQL Injection"