NoSQL 인젝션이란? 작동 방식과 예방법

NoSQL 인젝션이란?

NoSQL 인젝션은 공격자가 검증되지 않은 사용자 입력에 악성 연산자, JavaScript 코드 또는 조작된 구문을 삽입해 NoSQL 데이터베이스로 전송되는 쿼리를 조작하는 취약점입니다. Common Weakness Enumeration(CWE)에서 CWE-943, "데이터 쿼리 로직의 특수 요소를 부적절하게 무력화"로 분류됩니다. 표준 SQL 대신 유연하고 스키마가 없는 쿼리 언어를 사용하는 MongoDB, Redis, Cassandra, Elasticsearch 같은 데이터베이스가 공격 대상입니다.

공격에 성공하면 잘못된 쿼리 하나에 그치지 않는 피해가 발생합니다. 공격자는 인증을 완전히 우회하고, 민감한 데이터를 한 글자씩 추출하고, 레코드를 수정하고, 서비스 거부를 유발하거나 서버에서 임의의 코드를 실행할 수 있습니다. OWASP WSTG에 따르면 NoSQL 인젝션 페이로드는 선언형 쿼리 언어뿐 아니라 JavaScript 같은 절차형 언어에서도 실행될 수 있으므로 "잠재적 영향이 기존 SQL 인젝션보다 큽니다."

NoSQL 데이터베이스는 이제 로그인 시스템과 채팅 플랫폼부터 전자상거래 카탈로그와 IoT 관리 콘솔까지 폭넓게 사용됩니다. 도입이 늘어나는 가운데 "SQL이 없으면 인젝션도 없다"는 오해가 널리 퍼져 있어 이 취약점은 지속적인 위험으로 남아 있습니다. 이는 잘못된 믿음이며, 공격자는 이를 노립니다. 

NoSQL 인젝션의 실제 작동 방식을 살펴보기 전에 표준 취약점 분류 체계에서 어디에 속하는지 알아보겠습니다.

OWASP 분류

OWASP는 2021년과 2025년 Top 10에서 모두 NoSQL 인젝션을 인젝션 범주로 분류합니다. SQL 인젝션과 같은 위험군에 속하지만 근본 원인에 대한 분류가 달라 테스트 및 보고 방식에도 차이가 있습니다.

핵심 차이는 CWE 매핑입니다. 기존 SQL 인젝션은 CWE-89(SQL 명령에 사용되는 특수 요소를 부적절하게 무력화)에 속하지만, NoSQL 인젝션은 CWE-943(데이터 쿼리 로직의 특수 요소를 부적절하게 무력화)에 해당합니다. CWE-943은 MongoDB의 Binary JSON(BSON) 연산자, Redis 프로토콜 명령, CouchDB의 REST 기반 쿼리 등 SQL 이외의 쿼리 언어를 포괄합니다.

보안 테스트 프로그램이나 규정 준수 보고에서 CWE-89만 추적한다면 NoSQL 인젝션 발견 사항을 잘못 분류하거나 완전히 놓칠 수 있습니다. 도구와 분류 체계를 CWE-943에 맞춰 사각지대를 없애세요. 

분류를 확인했다면 다음으로 공격자가 NoSQL 쿼리 인터페이스를 악용하는 구체적인 방식을 살펴보겠습니다.

NoSQL 인젝션은 어떻게 작동하나요?

NoSQL 인젝션은 악용합니다. 공격자는 애플리케이션이 사용자 입력에서 기대하는 값과 실제로 받는 값 사이의 간극을 SQL 인젝션은 범용 쿼리 언어를 공격하지만 NoSQL 인젝션의 방식은 데이터베이스마다 다릅니다. MongoDB는 BSON/JSON 쿼리 연산자를, Redis는 Redis Serialization Protocol(RESP) 유선 프로토콜을 사용하며, CouchDB는 HTTP REST API를 제공합니다. 각 데이터베이스는 서로 다른 공격 표면, 하지만 핵심 원리는 같습니다. 사용자 입력 데이터가 적절한 검증 없이 쿼리에 들어가 쿼리의 논리를 바꿉니다.

연산자 인젝션: 가장 흔한 패턴

MongoDB를 사용하는 일반적인 Node.js 애플리케이션에서는 로그인 엔드포인트가 다음과 같은 쿼리를 구성할 수 있습니다.

정상적인 요청은 {"username":"admin","password":"secret"}를 보냅니다. 하지만 공격자는 다음을 제출할 수 있습니다.

이 $ne (같지 않음) 연산자는 사용자 이름과 비밀번호가 "invalid"와 같지 않은 모든 사용자를 반환하도록 MongoDB에 지시합니다. 모든 유효한 계정이 조건에 부합합니다. 무차별 대입 없이 단 한 번의 요청으로 인증을 우회합니다.

JavaScript 인젝션 발생 지점: $where

애플리케이션이 사용자 입력을 MongoDB의 $where 연산자나 mapReduce, $accumulator, 또는 $function 같은 함수에 전달하면 데이터베이스가 이를 서버 측 JavaScript로 평가합니다. 공격자가 무한 루프 페이로드를 주입하면 MongoDB 인스턴스가 멈춰 서비스 거부가 발생할 수 있습니다. 데이터 접근을 넘어, 임의의 JavaScript 실행은 데이터베이스 서버에서 원격 코드 실행 위험까지 초래할 수 있습니다.

블라인드 데이터 추출

애플리케이션이 쿼리 결과를 직접 반환하지 않으면 공격자는 불리언 기반 또는 시간 기반 기법으로 데이터를 한 글자씩 추출합니다. password[$regex]=^a 같은 정규식 패턴을 제출하고 응답이 거짓으로 알려진 조건의 응답과 다른지 관찰합니다. 이를 통해 비밀번호, 토큰 및 기타 기밀 정보를 복원할 수 있으며, 직접적인 데이터 유출은 확인되지 않습니다.

CRLF를 이용한 Redis 명령 인젝션

RESP에서는 캐리지 리턴과 줄 바꿈(CRLF) 시퀀스(\r\n)로 명령을 구분합니다. 애플리케이션이 사용자 입력을 정제하지 않고 Redis 프로토콜 수준의 명령에 이어 붙이면, 공격자는 CRLF 시퀀스를 주입해 현재 명령을 끝내고 같은 연결에서 승인되지 않은 명령을 추가로 실행할 수 있습니다.

Redis는 데이터를 키-값 쌍으로 저장합니다. SET, GET, CONFIG 같은 명령을 주입하면 민감한 데이터를 읽거나 키를 덮어쓰고 서버 설정까지 바꿀 수 있습니다. 이 기법은 흔히 서버 측 요청 위조 (SSRF)와 함께 사용됩니다. 공격자는 SSRF 취약점으로 외부 인터넷에 노출되지 않은 내부 Redis 인스턴스에 접근한 뒤, SSRF 경로로 추가 명령을 주입합니다.

CouchDB의 HTTP API 인젝션

CouchDB는 REST/HTTP API를 제공하므로 모든 데이터베이스 작업이 JSON 페이로드를 담은 표준 HTTP 요청을 통해 이루어집니다. 애플리케이션이 정제되지 않은 사용자 입력을 CouchDB 쿼리 매개변수, 뷰 정의 또는 Mango 선택자 객체에 전달할 때 인젝션이 발생합니다.

CouchDB는 JavaScript로 작성된 MapReduce 뷰를 사용하므로 MongoDB의 $where 연산자와 유사한 서버 측 실행 위험이 있습니다. 공격자가 MapReduce 뷰에서 실행되는 JavaScript에 영향을 줄 수 있다면 데이터베이스 서버에서 임의의 코드를 실행할 수 있습니다. 조작된 HTTP 요청으로 CouchDB의 복제 기능을 악용해 내부 서비스에 대한 SSRF를 유발할 수도 있습니다.

MongoDB의 BSON 연산자, Redis의 프로토콜 수준 CRLF 인젝션, CouchDB의 REST 기반 API는 각각 고유한 공격 표면을 형성합니다. NoSQL 인젝션 방어는 각 데이터베이스의 쿼리 인터페이스에 맞춰야 합니다.

이러한 기법은 콘텐츠 유형, 전송 계층, 프레임워크 전반에서 작동합니다. 근본 원인은 반복되며, 바로 그 반복에서 방어자는 대응의 실마리를 얻습니다.

NoSQL 인젝션의 원인

NoSQL 인젝션은 단 하나의 코딩 실수로 발생하지 않습니다. 아키텍처의 가정, 프레임워크의 동작, 누락된 검증 계층이 런타임에 맞물리면서 발생합니다.

부적절한 입력 검증과 유형 검사 부재

애플리케이션은 password 같은 필드가 항상 문자열로 전달된다고 가정할 수 있습니다. 하지만 HTTP 요청 본문, JSON 페이로드, URL 인코딩 매개변수에는 객체와 배열이 포함될 수 있습니다. Express.js body-parser가 password[$ne]=x를 받으면 애플리케이션 코드가 처리하기도 전에 자동으로 { password: { $ne: "x" } }로 역직렬화합니다. 이는 MongoDB 연산자 객체입니다.

동적 쿼리 구성

구조화된 쿼리 객체 대신 문자열 연결이나 보간으로 쿼리를 구성하면 공격자가 쿼리 구문을 깨고 새로운 로직을 삽입할 수 있습니다. 이를 MongoDB 포럼에서도 확인할 수 있습니다: "대부분의 외부 인젝션은 쿼리를 만들 때 문자열을 안전하지 않게 연결한 결과로 발생합니다."

활성화된 서버 측 JavaScript

MongoDB는 $where, mapReduce, $accumulator, $function을 통해 JavaScript 실행을 지원합니다. MongoDB 체크리스트에서는 이러한 작업을 사용하지 않는 경우 --noscripting으로 서버 측 스크립팅을 비활성화할 것을 명시적으로 권고합니다. 활성화된 상태로 두면 임의 코드 실행의 공격 표면이 생깁니다.

프레임워크 수준의 유형 변환

PHP는 username[$ne]=toto를 자동으로 ['username' => ['$ne' => 'toto']]로 변환합니다. Express.js body-parser도 URL 인코딩된 양식 데이터에서 같은 방식으로 작동하며, password[$ne]=x를 { password: { $ne: "x" } }로 역직렬화합니다. 요청이 애플리케이션 코드에 도달하기도 전에 MongoDB 연산자 객체가 되는 것입니다. 이러한 프레임워크 동작은 개발자의 별도 조치 없이도 무해해 보이는 HTTP 매개변수를 데이터베이스 연산자로 바꿉니다.

ORM 계층의 취약점

MongoDB 자체를 강화하더라도 애플리케이션의 객체 관계 매핑(ORM) 라이브러리에서 인젝션 공격 표면이 생길 수 있습니다. CVE-2024-53900은 Mongoose의 $where 연산자가 사용자 제어 입력을 통해 악용될 수 있음을 보여주었습니다. 첫 번째 취약점에 대한 수정이 불완전했음을 보여준 CVE-2025-23061은 $where를 여전히 다음 항목 아래에 중첩해 우회할 수 있음을 보여주었습니다: $or를 Mongoose의 populate().match 기능에서 사용해 서버 수준의 보호 조치를 완전히 우회합니다.

비활성화된 와이어 프로토콜 검증

MongoDB는 net.wireObjectCheck 설정을 통해 와이어 프로토콜 수준에서 수신 문서를 검증합니다. 이 설정을 비활성화하면 형식이 잘못된 BSON이 쿼리 엔진에 도달하지 못하도록 막는 구조적 안전장치가 사라집니다.

이러한 원인은 공격 표면을 HTTP 파싱부터 데이터베이스 실행까지 확장하며, 이는 곧 비즈니스 리스크로 이어집니다.

영향과 리스크

NoSQL 인젝션은 기밀성, 무결성, 가용성 (CIA) 3요소를 모두 위협합니다, 종종 동시에 위협합니다.

• 기밀성: 공격자는 임의의 문서를 읽고, 필드 이름을 열거하며, 블라인드 인젝션 기법으로 자격 증명을 한 글자씩 추출할 수 있습니다. 실제로 CVE-2021-22911에서는 연구진이 Rocket.Chat 인스턴스에서 관리자 비밀번호 해시와 비밀번호 재설정 토큰을 유출했습니다.
• 무결성: 연산자 인젝션과 원시 쿼리 악용을 통해 공격자는 문서를 수정, 교체 또는 삭제할 수 있습니다. 추가로 실행되는 쿼리는 완전히 새로운 레코드를 삽입하거나 기존 필드 값을 덮어쓸 수 있습니다.
• 가용성: 하나의 $where 무한 루프 페이로드만으로도 MongoDB 인스턴스의 리소스를 점유해, 네트워크 수준의 대량 트래픽 없이 사실상 데이터베이스를 중단시킬 수 있습니다.
• 인증 우회는 가장 빈번하게 보고되는 영향 중 하나입니다. 따라서 NoSQL 인젝션은 인터넷에 노출된 애플리케이션에 대한 초기 접근 경로가 됩니다.
• 공급망과 다운스트림 리스크는 플랫폼 제품에서 NoSQL 인젝션의 피해 범위를 확대합니다. 취약점으로 Rocket. Chat이나 Parse Server 같은 플랫폼이 침해되면 해당 플랫폼의 테넌트와 다운스트림 사용자까지 영향을 받습니다. 서비스형 백엔드 제품의 인젝션 취약점 하나가 그 플랫폼을 기반으로 구축된 여러 애플리케이션을 노출시켜, 하나의 취약점이 여러 환경의 침해로 이어질 수 있습니다.
• 규제 및 컴플라이언스 관련 결과는 기밀성 침해에서 직접 비롯됩니다. NoSQL 인젝션으로 개인 식별 정보, 자격 증명 또는 고객 커뮤니케이션이 유출되면 조직은 GDPR, HIPAA, PCI DSS 및 주 단위 개인정보 보호법에 따른 침해 통지 의무를 이행해야 합니다. 블라인드 인젝션 공격에 사용되는 한 글자씩 추출하는 기법은 장기간에 걸쳐 민감한 데이터를 은밀히 유출할 수 있습니다. 이렇게 조금씩 이어지는 유출은 놓치기 쉬우므로 조기 탐지가 중요합니다.

• 원격 코드 실행은 서버 측 JavaScript 평가를 통해 확인되었습니다. OWASP WSTG는 "JavaScript는 모든 기능을 갖춘 언어이므로 공격자는 데이터를 조작할 뿐 아니라 임의의 코드도 실행할 수 있다"고 설명합니다. 2025년 국제 디지털 포렌식 및 보안 심포지엄(ISDFS)의 논문은 이 리스크를 직설적으로 표현합니다. "JavaScript는 강력하므로 이러한 취약점을 노출하는 것은 최상급 범죄자에게 기관총을 건네는 것과 같다."

공격자의 수법을 아는 방어자는 모든 단계에서 공격을 차단할 수 있습니다. 그 수법을 살펴보겠습니다.

공격자가 NoSQL 인젝션을 악용하는 방법

공격자는 정찰부터 데이터 유출 또는 코드 실행까지 체계적인 절차에 따라 NoSQL 인젝션을 찾아 악용합니다.

1단계: 입력 경로 탐색

공격자는 NoSQL 백엔드로 전달되는 매개변수인 URL 매개변수, JSON POST 본문, HTTP 헤더, WebSocket 메시지를 찾아냅니다. 그런 다음 퍼징 문자를 제출합니다 (' " \ ; { }) 그리고 데이터베이스와의 상호작용을 드러내는 오류 메시지나 동작 변화를 관찰합니다.

2단계: 연산자 인젝션 확인

공격자는 로그인 엔드포인트에서 일반적인 자격 증명 문자열을 $ne 연산자로 바꿉니다:

애플리케이션이 다른 사용자 계정으로 로그인에 성공하면 연산자 인젝션이 확인됩니다. 공격자는 $gt (초과) 연산자로도 이를 확인할 수 있습니다:

이 $gt 연산자를 빈 문자열과 함께 사용하면 비어 있지 않은 모든 비밀번호 값과 일치합니다. 유효한 비밀번호 없이 관리자 계정으로 로그인에 성공하면 연산자 인젝션이 다시 한번 확인됩니다.

3단계: 인증 우회

공격자는 두 필드 모두에 연산자를 주입해 공격을 확대합니다:

이 공격은 특권 계정을 특정해, 사용자 이름이 목록과 일치하고 비밀번호가 비어 있지 않은 첫 번째 사용자를 반환합니다.

4단계: 데이터 유출

공격자는 $where JavaScript 인젝션을 사용해 필드 존재 여부를 확인합니다:

응답이 유효한 것으로 알려진 패턴과 일치하면 resetToken 필드가 존재합니다. 그런 다음 공격자는 불리언 기반 블라인드 인젝션으로 해당 값을 한 글자씩 추출합니다. 이 기법은 다음과 같은 정규식 패턴을 제출하고 {"resetToken":{"$regex":"^A"}} HTTP 응답을 관찰합니다. 성공 상태 코드나 특정 응답 본문은 문자가 일치한다는 뜻이고, 다른 응답은 일치하지 않는다는 뜻입니다. 공격자는 각 문자 위치에서 가능한 모든 문자를 테스트하며 이 과정을 반복합니다. CVE-2024-37405에 기록된 것처럼, 이러한 추출은 반복적인 차등 요청으로 수행할 수 있습니다. 따라서 블라인드 인젝션은 이론적 우려가 아닌 실질적인 공격입니다.

5단계: 권한 상승 및 내부 이동

추출한 자격 증명이나 재설정 토큰으로 공격자는 관리자 권한을 얻습니다. 이후 백엔드 시스템으로 침투하거나, $lookup 또는 $unionWith (PortSwigger가 선정한 주요 웹 해킹 기법)을 이용한 집계 파이프라인 인젝션으로 다른 컬렉션에 접근하거나, 서버 측 코드 실행으로 지속성을 확보할 수 있습니다. $lookup을 이용한 집계 파이프라인 인젝션은 영향력이 큰 기법입니다. 애플리케이션 쿼리가 원래 접근해서는 안 되는 컬렉션의 데이터를 읽어 컬렉션 수준의 접근 경계를 무너뜨리고 데이터베이스 전체의 데이터를 노출할 수 있기 때문입니다.

Content-Type 전환

공격자는 application/x-www-form-urlencoded와 application/json을 번갈아 사용하며 한 가지 콘텐츠 유형에만 존재하는 인젝션 지점을 찾는 경우가 많습니다. 이 기법은 여러 형식을 처리하는 REST API에 특히 효과적입니다.

이러한 공격 기법은 NoSQL 데이터베이스가 사용자 입력을 받는 모든 곳에 적용됩니다. 일부 애플리케이션은 다른 애플리케이션보다 공격에 훨씬 더 직접적으로 노출됩니다.

어떤 대상이 영향을 받나요?

사용자가 제어하는 입력을 적절한 유형 검사 없이 NoSQL 데이터베이스에 전달하는 모든 애플리케이션은 NoSQL 인젝션의 영향을 받습니다. 확인된 CVE 사례를 기준으로 가장 많이 노출된 애플리케이션 범주는 다음과 같습니다:

• 인증 시스템: 로그인 엔드포인트는 모든 주요 자료에 기록된 대표적인 공격 표면입니다.
• 팀 협업 플랫폼: Rocket.Chat에서는 인증 전 취약점(CVE-2021-22911)을 포함해 여러 해에 걸쳐 다수의 NoSQL 인젝션 CVE가 확인되었습니다.
• Mongoose를 사용하는 Node.js/Express 애플리케이션: 객체 문서 매퍼(ODM)인 Mongoose는 MongoDB 자체의 제어 기능과 별개로 ORM 계층에 인젝션 공격 표면을 만듭니다.
• 서비스형 플랫폼 백엔드: Parse Server(CVE-2022-24815, CVE-2026-30941)와 Steedos Platform(CVE-2020-35666)은 서비스형 백엔드 제품의 노출 위험을 보여줍니다.
• IoT 및 네트워크 관리: Ubiquiti의 UniFi Network Application에서 권한 상승을 가능하게 하는 NoSQL 인젝션 CVE가 벤더에 의해 확인되었습니다.
• 전자상거래 플랫폼: AquilaCMS는 비밀번호 재설정 기능의 NoSQL 인젝션 취약점에 대해 CRITICAL 등급을 받았습니다(CVE-2024-48573).
• GraphQL API: 검증되지 않은 GraphQL 필터 인수가 MongoDB 쿼리에 직접 전달되면 흔히 간과되는 인젝션 공격 표면이 생깁니다.

MongoDB는 널리 사용되며, Node.js/Express도 백엔드 개발에 널리 채택되고 있습니다. 두 기술의 결합은 광범위한 공격 표면을 만듭니다. NIST IR 8504는 NoSQL 인젝션을 미국 정부 시스템의 공식적인 위험 범주로 문서화했습니다. 이는 스타트업이나 SaaS 환경뿐 아니라 엔터프라이즈에도 해당하는 위험임을 강조합니다.

GraphQL API는 점점 더 흔한 공격 경로입니다. 필터 인수가 명시적인 허용 목록 없이 MongoDB 쿼리에 직접 전달되는 경우가 많고, 이러한 패턴은 기존의 기존 웹 애플리케이션 방화벽(WAF) 규칙으로 충분히 탐지되지 않기 때문입니다. 해당 규칙은 SQL 방식의 페이로드에 초점을 맞춥니다.

공통점은 산업이 아니라 기술 스택입니다. 사용자 입력을 받는 애플리케이션에서 MongoDB, Redis, CouchDB 또는 Elasticsearch를 사용한다면 잠재적인 공격 대상입니다. 자동 형 변환을 수행하는 JavaScript 프레임워크를 기반으로 구축했다면 특히 그렇습니다. 다음의 확인된 사례는 실제 환경에서 공격이 어떻게 이루어지는지 보여줍니다.

실제 사례

확인된 CVE와 공개된 공격 체인은 협업 플랫폼, 전자상거래, 서비스형 백엔드 제품, 네트워크 인프라의 운영 환경에서 NoSQL 인젝션이 어떻게 발생하는지 보여줍니다.

Rocket.Chat: 인증 전 관리자 계정 탈취(CVE-2021-22911)

SonarSource의 연구에 따르면 Rocket.Chat의 getPasswordPolicy() 메서드는 인증 없이 호출할 수 있었습니다. 공격자는 MongoDB의 $regex 연산자를 비밀번호 재설정 토큰 매개변수에 삽입한 뒤 {"$regex":"^A"}를 전송하고 응답의 차이를 관찰해 토큰을 한 글자씩 추출할 수 있었습니다.

확인된 HackerOne 보고서는 관리자 사용자 이름, 이메일 주소, 비밀번호 해시, 재설정 토큰을 유출해 최종적으로 관리자 계정을 완전히 탈취하는 공격 체인을 보여줬습니다.

@feathersjs/mongodb: WebSocket 객체 인젝션(CVE-2026-29793)

Socket.IO 클라이언트는 모든 Feathers 서비스 메서드의 id 인수로 임의의 JavaScript 객체를 전송할 수 있었습니다. 전송 계층은 형식을 검사하지 않았습니다. {$ne: null}을 id로 전송하면 컬렉션의 모든 문서가 일치했습니다. 이 취약점의 식별자는 CVE-2026-29793입니다.

Ubiquiti UniFi: 인증된 사용자의 권한 상승(CVE-2026-22557)

Ubiquiti의 자체 보안 권고문은 UniFi Network Application에서 인증된 사용자가 권한을 상승시킬 수 있는 NoSQL 인젝션 취약점을 확인했습니다. 인증된 사용자는 누구나 이 취약점을 악용해 상위 권한을 얻고, 낮은 권한의 계정으로 네트워크 인프라에 대한 완전한 관리자 제어 권한을 확보할 수 있었습니다.

Rocket.Chat Livechat: 연쇄 인젝션(CVE-2024-37405)

서로 다른 두 NoSQL 인젝션 지점이 연결되었습니다: 방문자 토큰을 $regex 블라인드 인젝션으로 추출한 뒤, rid 매개변수에 두 번째 인젝션을 수행해 모든 Livechat 메시지를 추출했습니다. 이 인증 전 공격으로 고객 대상 커뮤니케이션 데이터가 노출되었습니다.

AquilaCMS: 비밀번호 재설정 과정의 치명적 인젝션 취약점 (CVE-2024-48573)

AquilaCMS, 오픈 소스 전자상거래 플랫폼으로, 비밀번호 재설정 기능의 NoSQL 인젝션 취약점에 CRITICAL (9.8) 등급을 받았습니다. 인증되지 않은 공격자는 재설정 토큰 매개변수에 MongoDB 연산자를 삽입해 비밀번호 재설정 절차를 조작하고, 의도된 검증 로직을 완전히 우회할 수 있었습니다. AquilaCMS가 전자상거래 쇼핑몰을 구동하는 만큼, 취약점 악용에 성공하면 고객 계정 데이터, 결제 정보, 주문 내역이 위험에 노출될 수 있었습니다. 이 취약점은 인증 없이 표준 HTTP 요청으로 원격에서 악용할 수 있어, 쇼핑몰에 네트워크로 접근할 수 있는 모든 공격자에게 열려 있었습니다.

Parse Server: 반복적으로 발생한 인젝션 취약점 (CVE-2022-24815, CVE-2026-30941)

Parse Server는 널리 사용되는 오픈 소스 서비스형 백엔드 플랫폼으로, 여러 해에 걸쳐 NoSQL 인젝션 취약점이 반복적으로 발생했습니다. CVE-2022-24815는 프로토타입 오염과 NoSQL 인젝션이 결합된 사례입니다. JavaScript 계층의 취약점과 데이터베이스 인젝션이 맞물려, 어느 한 취약점만으로는 불가능한 공격 경로가 형성될 수 있음을 보여줍니다. 몇 년 후, CVE-2026-30941을 통해 토큰 값이 유형 검증 없이 데이터베이스 쿼리에 전달되는 인젝션 취약 지점이 플랫폼에 여전히 존재한다는 사실이 드러났습니다. 서비스형 백엔드 제품은 단일 취약점이 해당 플랫폼으로 구축된 모든 애플리케이션에 영향을 미치므로 공격자에게 가치가 높은 표적입니다. Parse Server가 침해되면 이를 사용하는 모바일 앱, 웹 애플리케이션, IoT 백엔드도 동일한 위험에 노출될 수 있습니다.

이러한 사고는 여러 해에 걸쳐 다양한 기술 스택에서 발생했습니다. NoSQL 인젝션은 실제 운영 시스템에서 계속 재발하고 있으며, 연대기는 이 패턴이 얼마나 오래 지속되었는지 보여줍니다.

NoSQL 인젝션 연대기

2026년에 집중적으로 발표된 CVE는 Node.js/MongoDB 스택에 대한 연구자들의 관심이 커지고 있음을 보여줍니다. NoSQL 인젝션이 잊히기는커녕 다시 주목받고 있을 가능성도 시사합니다. 따라서 탐지가 우선입니다. 다행히 탐지 신호는 잘 알려져 있습니다.

NoSQL 인젝션 탐지 방법

NoSQL 인젝션을 찾으려면 정적 코드 분석, 실제 엔드포인트에 대한 동적 테스트, 다른 보안 통제가 놓친 공격을 포착하는 런타임 동작 모니터링을 결합해야 합니다.

정적 분석 및 코드 검토

코드베이스에서 고위험 패턴을 검토하세요. 모든 Mongoose .find(), .findOne(), 또는 .populate() 호출에서 req.body, req.query, 또는 req.params를 타입 검증 없이 직접 전달하는지 확인하세요. 사용자 제어 입력과 함께 사용하는 $where의 모든 사례, 사용자 제어 필터 객체를 포함하는 집계 파이프라인, 클라이언트의 원시 JSON 쿼리 객체를 허용하는 엔드포인트를 찾으세요. 또한 eval(), Function(), 또는 사용자 입력을 쿼리 문자열에 연결하는 템플릿 리터럴의 사용 사례도 표시하세요. 집계 파이프라인에서 $lookup 또는 $unionWith를 사용자 제어 컬렉션 이름 또는 파이프라인 단계와 함께 사용하는 경우 특히 주의 깊게 살펴보세요. 컬렉션 수준의 접근 제어 경계가 무너질 수 있습니다.

동적 테스트

다음 OWASP WSTG-INPV-05.6 방법론을 따르세요:

1. 퍼징 문자열 '"\{ ;$Foo} $Foo \xYZ`을 제출해 구문 인젝션 지점을 확인하세요.
2. 특수 문자 ' " \ ; { }를 제출해 연산자 인젝션 지점을 확인하세요.
3. HTTP 매개변수 오염 기법으로 $where 매개변수를 삽입하고 MongoDB 오류 응답을 관찰하세요.
4. 참인 조건과 거짓인 조건에서 나타나는 응답 차이를 테스트해 블라인드 인젝션을 찾아내세요.

WebSocket 채널도 별도로 테스트하세요. CVE-2026-29793은 Socket.IO 클라이언트가 HTTP 계층의 모든 검사를 우회해 임의의 JavaScript 객체를 서비스 메서드의 인수로 전송할 수 있음을 보여주었습니다. 많은 스캐너는 HTTP 엔드포인트에만 집중해 WebSocket 인젝션 지점을 완전히 놓칩니다. 수동 또는 전문 WebSocket 테스트를 통해 실시간 통신 프레임워크 기반 애플리케이션의 이러한 사각지대를 해소하세요.

런타임 동작 모니터링

인프라에서 공격 성공을 나타내는 동작 지표를 모니터링하세요:

• 데이터베이스 서비스 프로세스(mongod, redis-server)가 예기치 않은 자식 프로세스나 셸을 생성하는 현상
• MongoDB 연산자 구문이 포함된 비정상적인 쿼리 패턴 ($where, $regex, $ne, $gt)가 애플리케이션 로그에 나타남
• 정상적인 쿼리 부하 증가 없이 발생하는 MongoDB 서버의 CPU 사용량 급증
• 비밀번호 재설정 엔드포인트의 토큰 필드에 문자열 대신 객체가 전달됨
• 시간 기반 블라인드 인젝션을 시사하는 외부 공개 엔드포인트의 응답 시간 차이

침투 테스트 도구

전용 도구를 사용해 평가 중 NoSQL 인젝션을 검사할 수 있습니다:

• NoSQLMap: NoSQL 인젝션 테스트와 악용을 위해 특별히 제작된 오픈 소스 도구
• nosqli: NoSQL 인젝션 자동 탐지를 위한 명령줄 도구
• Burp Suite: Repeater와 Intruder 모듈을 통한 수동 테스트 및 확장 기능을 통한 NoSQL 페이로드 자동 테스트
• OWASP ZAP: NoSQL 엔드포인트에 적용할 수 있는 활성 스캔 규칙

어디를 살펴봐야 하는지 아는 것이 과제의 절반입니다. 나머지 절반은 처음부터 악용을 막는 방어 체계를 구축하는 것입니다.

NoSQL 인젝션 예방 방법

NoSQL 인젝션을 차단하려면 모든 사용자 입력이 데이터베이스 계층에 도달하기 전에 엄격한 타입 검사를 적용해야 합니다. 아래의 방어 조치는 앞서 확인한 프레임워크 수준의 타입 강제 변환부터 ORM 계층 우회까지 각 근본 원인을 해결합니다.

쿼리 생성 전 타입 검사 적용

스칼라 값(문자열, 숫자, 불리언)이 아닌 입력 필드는 ORM이나 데이터베이스 드라이버에 도달하기 전에 거부하세요. 명시적 타입 변환은 가장 효과적인 단일 방어 조치입니다:

MongoDB 연산자 키를 제거하거나 거부하세요

다음 항목의 모든 키를 검사하세요: req.body, req.query, req.params에서 $ 접두사가 있는 키를 데이터베이스 계층에 도달하기 전에 거부하세요. key.startsWith('$')로 검사하세요. 정규식에는 CVE-2021-22910에 문서화된 우회 방법이 있습니다.

서버 측 JavaScript 비활성화

MongoDB 설정에서 --noscripting 또는 set security.javascriptEnabled: false를 사용하세요. 이를 통해 $where 공격 표면을 완전히 제거합니다. 조건부 로직에는 $expr와 타입이 지정된 쿼리 빌더를 사용하세요.

스키마 검증 프레임워크 사용

Joi, Ajv, Zod 같은 라이브러리로 요청 처리 초기에 데이터 유형을 검증하세요. 스칼라 값이 필요한 곳에 배열이나 객체가 들어오면 거부해, 연산자 인젝션이 데이터베이스에 도달하기 전에 차단합니다.

Mongoose 및 ORM 버전 고정, 보안 권고 모니터링

ORM 계층의 취약점은 애플리케이션과 데이터베이스 수준의 통제를 모두 우회할 수 있습니다. CVE-2024-53900 및 CVE-2025-23061 두 취약점은 Mongoose의 populate().match 기능이 MongoDB 서버 측 JavaScript를 비활성화해도 악용될 수 있음을 보여줍니다. CVE-2025-23061은 CVE-2024-53900을 완전히 수정하지 못한 사례로, 패치도 불충분할 수 있으며 별도 검증이 필요함을 보여줍니다.

Mongoose와 기타 ODM/ORM 라이브러리의 보안 권고를 구독하고, 종속성 버전을 명시적으로 고정하세요. 보안 패치마다 문서화된 취약점이 완전히 해결됐는지 확인한 후에 수정 티켓을 종료하세요.

클라이언트의 원시 JSON 쿼리를 허용하지 마세요

해당 OWASP 치트 시트에는 "클라이언트의 원시 JSON 쿼리를 허용하지 마세요"라고 명시되어 있습니다. { "$where": "this.balance > 0" } 같은 페이로드가 클라이언트에서 제출되면 원격 코드 실행이나 CPU 리소스 고갈로 이어질 수 있습니다.

최소 권한 원칙에 따른 데이터베이스 구성

최소한의 권한만 부여한 전용 애플리케이션 데이터베이스 계정을 사용하세요. root 또는 admin 자격 증명으로 접속하지 마세요. 데이터베이스 포트나 관리 콘솔을 공개 인터넷에 노출하지 마세요.

Wire Object Check 활성 상태 유지

MongoDB의 net.wireObjectCheck 설정은 와이어 프로토콜 수준에서 모든 문서를 검증합니다. 기본적으로 활성화되어 있습니다. 비활성화하지 마세요.

GraphQL 필터 보호

GraphQL 필터 인수는 명시적인 허용 목록을 거쳐 변환하세요. 신뢰할 수 없는 객체를 MongoDB 또는 Mongoose 쿼리 필터에 직접 펼쳐 넣지 마세요.

강력한 애플리케이션 수준의 통제는 공격 표면을 줄입니다. 하지만 완전히 없애지는 못합니다. 여러 계층의 탐지와 대응으로 통제를 빠져나간 위협까지 포착하세요.

탐지 및 예방 도구

NoSQL 인젝션에 대한 다계층 방어는 애플리케이션 수준의 통제, 테스트 도구, 런타임 모니터링을 결합합니다.

• 애플리케이션 계층 방어에는 입력 검증 라이브러리(Joi, Ajv, Zod), ORM 수준의 보호 기능(Mongoose 스키마 검증, 명시적 유형 변환), MongoDB의 내장 보안 통제((--noscripting, wireObjectCheck, 역할 기반 액세스)가 포함됩니다.
• 테스트 도구인 NoSQLMap, nosqli, Burp Suite, OWASP ZAP은 개발 및 침투 테스트 과정에서 NoSQL 인젝션 여부를 검사합니다.
• WAFs는 알려진 인젝션 패턴을 차단하는 경계 방어 계층을 제공합니다. 하지만 WAFs는 시그니처 기반 규칙으로 작동하므로 새로운 페이로드, 난독화된 연산자, WebSocket 채널을 통한 인젝션은 차단하지 못합니다.
• 런타임 행동 모니터링은 WAFs의 방어 공백을 메웁니다. 새로운 페이로드, Mongoose의 populate().match 문제와 같은 ORM 계층 취약점, WAFs가 검사하지 않는 WebSocket 채널을 통해 애플리케이션 계층 통제를 우회할 수 있습니다. 런타임 모니터링은 페이로드 전달 경로와 관계없이 성공한 인젝션의 결과를 관찰합니다. 여기에는 데이터베이스 프로세스가 예기치 않은 셸을 실행하거나, 비정상적인 JavaScript 실행 패턴 또는 쿼리량이 나타나는 현상이 포함됩니다. 인젝션 페이로드가 시그니처 기반 검사를 피해 데이터베이스에 도달했다면, 그에 따른 비정상적인 행동이 침해를 가장 확실하게 알려줍니다.

SentinelOne은 어떻게 대응하나요?

페이로드 검사는 WAF의 역할입니다. SentinelOne은 그다음에 일어나는 일을 감시합니다. 애플리케이션 계층 통제가 놓치는 프로세스 이상 징후, 측면 이동, 공격 후 활동 등 성공한 NoSQL 인젝션의 행동상 결과를 찾아 차단합니다.

SentinelOne의 Singularity™ Platform에는 Singularity AI SIEM, 단일 데이터 레이크에서 엔드포인트, 클라우드 워크로드, ID 시스템 및 타사 소스의 텔레메트리를 연계합니다. 2024년 MITRE ATT&CK 평가에서 Singularity Platform은 지연 없이 100% 탐지율을 달성하면서 중앙값보다 88% 적은 알림을 생성했습니다. 불필요한 알림이 줄어들면 보안 팀은 확인된 위협에 집중할 수 있습니다. NoSQL 인젝션 공격이 웹 애플리케이션에서 데이터베이스 서버를 거쳐 자격 증명 탈취로 이어지면, AI SIEM은 수동 연계 없이 각 공격 표면의 이벤트를 연결합니다.

Singularity Endpoint 내에서 Storyline 기술은 보호되는 각 엔드포인트의 프로세스 생성 이벤트, 네트워크 연결, 파일 변경 및 자격 증명 사용을 지속적으로 연결해 일관된 활동 추적 체계를 구축합니다. $where 기반 서버 측 JavaScript 실행 공격이 발생하면 Storyline은 악성 요청을 받은 웹 서버 프로세스, 비정상적으로 동작하는 데이터베이스 서비스, 생성된 인터프리터 프로세스 및 모든 자식 셸을 하나의 Storyline ID로 자율적으로 연결합니다. Storyline Active Response (STAR) 사용자 지정 규칙은 mongod 또는 redis-server 같은 데이터베이스 프로세스가 예상치 못한 자식 프로세스를 생성하면 작동합니다. 이는 명령어 삽입 성공을 보여주는 신뢰도 높은 행동 지표입니다.

Purple AI™ 자연어 쿼리로 조사를 가속합니다. IDC에 따르면 Purple AI 고객은 위협을 63% 더 빠르게 식별하고 평균 조치 시간(MTTR)을 55% 단축합니다. "지난 24시간 동안 mongod가 생성한 모든 프로세스를 보여줘"라고 요청하거나 T1190(외부 공개 애플리케이션 악용), T1059(명령 및 스크립트 인터프리터) 같은 MITRE ATT&CK 기법을 직접 참조할 수 있습니다. Purple AI의 Auto Investigation 기능은 스택 전반의 증거를 자율적으로 수집하고 위협 데이터를 종합해 전체 공격 타임라인을 구성합니다. 몇 시간씩 걸리던 조사를 몇 분으로 단축합니다.

클라우드 워크로드 보안은 클라우드 호스팅 NoSQL 데이터베이스를 런타임에 보호합니다. 워크로드 동작을 실시간으로 모니터링하고 Verified Exploit Paths를 사용해 증거에 기반한 분석 결과를 제시합니다. 클라우드 호스팅 MongoDB 또는 Redis 인스턴스에 대한 NoSQL 삽입이 공격 이후 활동으로 이어지는 시점을 확인할 수 있습니다.

NoSQL 데이터베이스를 대규모로 운영하는 조직은 이러한 기능으로 애플리케이션 수준의 예방과 공격 이후 활동에 대한 가시성 사이의 격차를 해소합니다. 

SentinelOne 데모를 요청하세요 이러한 기능이 실제로 작동하는 모습을 확인해 보세요.

관련 취약점

NoSQL 삽입은 다음과 같은 관련 취약점 유형과 근본 원인 및 공격 패턴을 공유합니다:

• SQL 삽입(CWE-89): 관계형 데이터베이스에서 발생하는 유사한 취약점입니다. 둘 다 데이터베이스 쿼리에서 사용자 입력을 적절히 무해화하지 않아 발생하지만, NoSQL 삽입은 절차적 언어 실행 기능을 통해 데이터 조작을 넘어 임의 코드 실행까지 영향을 미칩니다.
• 서버 측 요청 위조(SSRF): Redis CRLF 삽입은 SSRF와 연계되는 경우가 많습니다. 공격자는 SSRF를 이용해 내부 Redis 인스턴스에 접근한 다음 CRLF 시퀀스를 통해 추가 명령어를 삽입합니다.
• 명령어 삽입(CWE-78): NoSQL 삽입이 $where를 통해 서버 측 JavaScript 실행에 성공하면, 그 결과로 얻는 실행 능력은 OS 명령어 삽입과 매우 유사합니다.
• 프로토타입 오염: CVE-2022-24815는 Parse Server에서 프로토타입 오염과 NoSQL 삽입이 결합된 사례로, JavaScript 계층의 취약점이 데이터베이스 삽입과 결합해 피해를 키울 수 있음을 보여줍니다.
• 크로스 사이트 스크립팅 (XSS): XSS와 NoSQL 삽입은 모두 불충분한 입력 검증에서 비롯됩니다. 한쪽에 취약한 조직은 다른 쪽에도 노출되는 구조적인 검증 문제를 안고 있는 경우가 많습니다.

이러한 연관성을 이해하면 각 취약점을 개별적으로 다루는 대신 관련 취약점 유형 전반에서 테스트와 수정의 우선순위를 정할 수 있습니다. 다음 표에는 참고용으로 확인된 NoSQL 삽입 CVE가 나와 있습니다.