Nosql은 유연한 스키마와 수평적 확장성을 지원하기 위해 최신 애플리케이션에서 널리 사용되는 광범위한 비관계형 데이터베이스 기술을 포괄합니다. 이러한 장점에도 불구하고 NoSQL 시스템은 설계상 본질적으로 안전하지 않으므로 개발자는 다음 사항을 이해해야 합니다. NoSQL 인젝션 취약점공격자가 이를 악용하는 방법과 이를 체계적으로 방어하는 방법에 대해 설명합니다. 이 문서에서는 실제 위협 시나리오, 예방 전략, 코드 예제 및 영향력이 큰 CVE에 대한 참조를 포함하여 보안 엔지니어를 위한 심층적인 기술 탐색을 제공합니다.
NoSQL이란 무엇이며 보안에 중요한 이유
NoSQL("Not Only SQL" 또는 "비관계형 SQL"의 약자) 데이터베이스는 기존의 관계형 모델을 버리고 키-값 저장소, 문서 저장소, 열 패밀리 및 그래프 데이터베이스와 같은 유연한 데이터 모델을 선호합니다. 널리 사용되는 구현은 다음과 같습니다. MongoDB, CouchDB, Redis, 카산드라및 Neo4j. 이러한 시스템은 확장성과 스키마 민첩성을 제공하지만, 다음과 같은 문제도 발생합니다. 새로운 쿼리 의미론 및 보안 함정 SQL 시스템에 익숙한 엔지니어에게는 생소할 수 있습니다. vaadata.com
SQL과 달리, 각 NoSQL 시스템에는 고유한 쿼리 언어(예: MongoDB의 JSON 기반 쿼리)와 서로 다른 연산자 의미가 있습니다. 이러한 다양성은 유연성을 향상시키지만, 다음과 같은 결과도 초래합니다. 고유한 인젝션 공격 벡터 사용자 입력이 적절한 위생 처리 없이 데이터베이스 쿼리에 보간되는 경우가 많기 때문입니다. vaadata.com
NoSQL 인젝션: 정의 및 발생 시기
핵심적으로, 공격자가 다음을 전송할 때 NoSQL 인젝션이 발생합니다. 제작 입력 을 사용하여 데이터베이스 쿼리의 의도된 구조를 변경합니다. SQL 인젝션의 기존 텍스트 기반 문법과 달리, NoSQL 인젝션은 종종 JSON 페이로드 또는 쿼리 연산자 다음과 같은 $ne, $gt, $lt, $regex또는 1TP4위치 를 사용하여 로직을 조작할 수 있습니다. vaadata.com
실제 사례 및 시나리오
개발자가 클라이언트 입력을 직접 사용하여 자격 증명을 쿼리하는 일반적인 Node.js + MongoDB 인증 스니펫을 예로 들어보겠습니다:
자바스크립트
// 취약한 인증
db.users.find({
이메일: req.body.email,
비밀번호: req.body.password
});
공격자는 다음과 같은 값을 제공할 수 있습니다:
json
{ "이메일": { "$ne": null }, "password": { "$ne": null } }
이 쿼리는 이메일이 있는 문서를 반환합니다. not null이고 암호는 not null로 설정하여 유효한 자격 증명을 몰라도 효과적으로 인증을 우회할 수 있습니다. vaadata.com
일반적인 NoSQL 데이터베이스 및 주입이 발생하는 위치
| 데이터베이스 유형 | 예제 | 주입 위험 |
|---|---|---|
| 문서 저장소 | MongoDB, CouchDB | High-JSON 쿼리 및 JS 실행 |
| 키-값 | Redis, DynamoDB | 중간 스크립트 평가 또는 복잡한 작업은 신중하게 사용해야 합니다. |
| 열-가족 | 카산드라, HBase | 중간 쿼리 보간 위험 |
| 그래프 | Neo4j | Cypher와 같이 쿼리 빈도가 높은 언어를 조작할 수 있습니다. |
각 모델은 쿼리 언어 차이로 인해 서로 다른 위험 프로필을 가지고 있습니다. 예를 들어 MongoDB 와 같은 연산자를 사용한 쿼리를 허용합니다. 1TP4위치 임의의 자바스크립트를 실행하여 공격 표면을 증가시킵니다. InfoQ
NoSQL 인젝션과 관련된 영향력이 큰 CVE 예시
NoSQL 인젝션은 SQL 인젝션에 비해 덜 보고되는 경향이 있지만, 문서화된 보안 문제는 매우 실제적인 것으로 나타났습니다. 예를 들어
- CVE-2024-48573: 사용자가 제공한 필터가 위생 처리되지 않아 공격자가 계정 비밀번호를 재설정할 수 있는 Aquila CMS의 NoSQL 인젝션으로 인해 악의적인 운영자 인젝션이 가능해졌습니다. vaadata.com
기타 보고된 버그(예: 다음과 같은 문제) 1TP4위치 ODM에서의 오용)는 인젝션 벡터가 애플리케이션 코드뿐만 아니라 다음에서도 발생할 수 있음을 강조합니다. 안전하지 않은 라이브러리 또는 스키마 처리. 밝은 보안
NoSQL 인젝션을 악용하는 방법
NoSQL 인젝션 공격은 데이터베이스와 보안 상태에 따라 그 영향이 달라집니다. 익숙해질 수 있습니다:
- 인증 로직 우회
- 민감한 기록 추출
- 중요 데이터 수정 또는 삭제
- 권한 높이기
- 2차 애플리케이션 취약성 유발(예: 자바스크립트 실행을 통한 RCE)
예시: 인증 우회
자바스크립트
// 공격자 페이로드가 쿼리 로직을 수정합니다.
db.users.find({
이메일: { $regex: ".*" },*
*비밀번호: { $regex: ".*" }
});
이는 다음과 같은 이유로 모든 자격 증명과 일치합니다. .* 는 모든 것을 일치시키는 정규식으로, 로그인 확인을 효과적으로 우회합니다. vaadata.com
NoSQL 인젝션 탐지
NoSQL 주입 테스트에는 다음이 포함됩니다:
- 사용자 입력이 데이터베이스 쿼리에 직접 전달되는 지점 식별하기
- 다음과 같은 연산자 키를 사용하여 사용자 매개 변수를 퍼징합니다.
$ne,$gt,$lt - 애플리케이션 동작 변화 관찰(예: 인증 우회, 쿼리 결과 차이)
- 자동화된 스캐너와 수동 펜테스팅 기법을 통한 테스트 Indusface
엔지니어는 악성 페이로드를 시뮬레이션하기 위해 수동 프로브와 자동화된 툴을 모두 사용하는 경우가 많습니다.
방어 전략: 입력 유효성 검사 및 쿼리 강화
NoSQL 인젝션 방어의 핵심은 다음과 같이 처리하는 것입니다. 모든 사용자 입력을 신뢰할 수 없는 것으로 설정 를 사용하여 해당 입력이 쿼리 구조를 변경할 기회를 제거합니다.
모범 사례
- 입력 유효성 검사 및 화이트리스트 예상되는 필드와 데이터 유형만 허용합니다. 쿼리 논리를 변경할 수 있는 특수 문자 및 JSON 연산자를 거부하거나 살균합니다. Indusface
- 매개 변수화/준비된 쿼리 NoSQL에는 범용적으로 준비된 문이 없지만, 많은 드라이버가 문자열 연결을 피하는 더 안전한 쿼리 빌더를 지원합니다.
- 스키마 유효성 검사 문서 스키마 또는 모델 유효성 검사(예: 몽구스 스키마)를 사용하여 예상 입력 형식을 적용하세요.
- 위험 작업자 비활성화하기 평가 비활성화
1TP4위치,$eval또는 데이터베이스 구성에서 자바스크립트를 실행합니다. Indusface - 최소 권한 정책 데이터베이스 사용자 권한을 제한하여 인젝션이 발생하더라도 작업(읽기/쓰기)의 폭발 반경이 제한되도록 합니다.
- 로깅 및 모니터링 비정상적인 쿼리 패턴을 기록하여 인젝션 시도를 감지하고 경고를 트리거하세요.
코드 예시: 공격 대 방어 패턴
다음은 익스플로잇과 완화 방법을 모두 보여주는 실제 코드 스니펫입니다.
몽고DB 인증 우회 공격
자바스크립트
// 안전하지 않음: 쿼리에서 사용자 직접 입력
db.users.find({
사용자 이름: req.body.user,
비밀번호: req.body.pass
});
방어 패턴: 화이트리스트 및 캐스트 입력
자바스크립트
const userInput = {
user: String(req.body.user || ""),
pass: String(req.body.pass || "")
};
db.users.find({ 사용자명: userInput.user, 비밀번호: userInput.pass });
쿼리 내 정규식 남용
공격 페이로드:
json
{ "name": { "$regex": ".*" } }
방어(정규식 허용 안 함):
자바스크립트
if (!/^[A-Za-z0-9_]+$/.test(req.body.name)) {
새로운 에러("잘못된 문자")를 던집니다;
}
MongoDB에서 자바스크립트 실행 방지
안전하지 않습니다:
자바스크립트
db.users.find({ $here: "this.age > 25" });
안전한 구성:
bash
# mongod.conf
setParameter:
자바스크립트 사용: false
매개변수화된 쿼리 시뮬레이션
안전하지 않습니다:
자바스크립트
collection.find({ filter: JSON.parse(req.body.filter) });
위생 처리 라이브러리를 사용한 안전한 구문 분석
자바스크립트
const sanitize = require('mongo-sanitize');
const filter = sanitize(req.body.filter);
collection.find(filter);
REST API 입력 필터링
취약한:
자바스크립트
app.post("/검색", (req, res) =>)
db.collection("items").find(req.body).toArray()
);
강화:
자바스크립트
const allowedFields = ["category", "price"];
const query = {};
allowedFields.forEach(f => {
if (req.body[f]) query[f] = req.body[f];
});
db.collection("items").find(query).toArray();
철저하고 자동화된 NoSQL 보안 테스트
복잡한 애플리케이션에서는 API, 동적 입력, 마이크로서비스 전반에 걸쳐 모든 인젝션 벡터를 수동으로 식별하는 것이 불가능할 때가 많습니다. 펜리전트는 AI 기반 모의 침투 테스트 플랫폼으로 보안 팀을 지원합니다:
- 취약점을 조사하기 위해 제작된 NoSQL 페이로드를 자동으로 생성 및 주입합니다.
- 쿼리 패턴과 고위험 행동의 상관관계 파악하기
- CI/CD 파이프라인과 통합하여 회귀를 조기에 포착하기
- OWASP 및 CWE 분류에 따라 우선순위가 지정된 보고서 생성
이 접근 방식은 다음과 같이 기존 SAST/DAST를 보완합니다. 컨텍스트 인식 분석는 정적 규칙만으로는 불충분할 수 있는 동적 NoSQL 쿼리 언어에 특히 유용합니다.
결론: NoSQL은 안전한 설계가 아닙니다.
NoSQL 데이터베이스는 확장성과 유연성을 제공하지만 단순히 다른 구문을 사용한다는 이유로 인젝션 위험에서 자유롭지 않습니다. NoSQL의 인젝션 결함은 다음과 같은 경우 인증을 우회하거나, 데이터를 노출하거나, 무단 작업을 허용할 수 있습니다. 입력이 부적절하게 처리됨. 엔지니어는 강력한 입력 유효성 검사, 스키마 적용, 안전한 드라이버 사용, 자동화된 테스트(펜리전트 같은 AI 지원 플랫폼 포함)를 결합하여 nosql 인젝션 공격에 대한 노출을 크게 줄일 수 있습니다.
Korean 
English 
German 
French 
Spanish 
Portuguese 
Japanese 
Hindi 
Arabic 
Turkish 
Hebrew