본 블로그는 학습용입니다. 명시적 동의 없는 시스템 접근·정보수집은 불법이며 형사·민사 책임이 따릅니다.
실습은 격리된 테스트 환경에서만 허용됩니다. (형법·정보통신망법·정보통신기반보호법 등)
1. 주제
주제: NoSQL Injection을 이용한 웹 애플리케이션 인증 우회
핵심 요약: NoSQL Injection은 MongoDB와 같은 비관계형(NoSQL) 데이터베이스를 사용하는 웹 애플리케이션의 인증 로직에 특수 연산자를 주입해서 데이터베이스 쿼리의 논리 구조를 변경하고 관리자 계정으로 무단 접근하는 심각한 취약점입니다
2. 정의 및 작동 원리
2.1. 상세 정의
NoSQL Injection은 주로 사용자 입력(아이디, 비밀번호 등)이 JSON 또는 BSON 형태의 데이터베이스 쿼리에 안전한 처리 과정 없이 문자열 그대로 삽입될 때 발생합니다. 공격자는 데이터베이스에서 특정 조건(예: 비밀번호 일치)을 검사하는 대신, 항상 참이 되는 조건을 강제로 삽입하여 인증 로직을 무력화합니다.
2.2. 흐름
이 공격 핵심은 MongoDB에서 특정 필드 값이 "null과 같지 않다"는 조건인 $ne (Not Equal) 연산자를 사용하는 것입니다.
취약한 서버 측 예시 로그인 쿼리
db.users.findOne({
username: request.body.username, //공격자 입력: '{ "$ne": null }'
password: request.body.password //공격자 입력: '{ "$ne": null }'
})
공격자가 ID와 비밀번호 입력 필드에 모두 { "$ne": null }을 주입하면 데이터베이스는 사용자 이름 필드와 비밀번호 필드가 모두 존재하는 첫 번째 레코드를 반환하게 됩니다. 일반적으로 관리자 계정이 데이터베이스에 먼저 존재하거나 시스템상 첫 번째로 조회되어 인증이 우회되고 관리자 페이지로 접근됩니다.
3. 시나리오 및 실습 환경
3.1. 목표
PicoCTF의 'No SQL Injection' 웹 페이지에서 NoSQL Injection 취약점을 이용하여 관리자 계정으로 인증을 우회하고, 최종적으로 로그인 성공한다.
3.2. 실습 환경
Target: PicoCTF - No SQL Injection
Tool(s): 웹 브라우저
Account: 인증 우회를 통해 접근 시도
4. 분석 및 공격 절차
4.1. [1단계: 정보 수집 및 분석]
No SQL Injection을 통해 타겟 애플리케이션이 NoSQL 데이터베이스를 사용하고, 인증 로직에 취약점이 있을 것을 예상됩니다.
목표 계정은 일반적으로 최고 권한을 가진 admin으로 설정하고 공격을 시도합니다.

4.2. [2단계: 취약점 발견 및 테스트]
MongoDB 쿼리 구조를 우회하기 위한 특수 연산자 주입을 시도합니다.
핵심 페이로드
- Username: { "$ne": null } (사용자 이름 검증 로직 무력화)
- Password: { "$ne": null } (비밀번호 검증 로직 무력화)
이 페이로드는 서버 측 쿼리에서 { username: { "$ne": null }, password: { "$ne": null } }와 같이 해석되어, 사용자 이름과 비밀번호 값이 모두 null이 아닌 모든 사용자를 찾게 됩니다. 관리자 계정이 이 조건을 충족하고 데이터베이스에서 첫 번째로 조회되어 인증이 성공하게 됩니다.
4.3. [3단계: 공격 수행 및 목표 달성]
| 필드 | 입력 값 |
| Username | { "$ne": null } |
| Password | { "$ne": null } |
브라우저의 로그인 입력 필드에 위 페이로드를 입력한 후 로그인 버튼을 클릭합니다.

결과
로그인 성공 후 "Admin Page"로 접근되었으며, Cyber Security Concepts 목록과 함께 플래그 획득을 위한 단서가 포함된 페이지가 나타납니다.

5. 핵심 코드 및 결과
5.1. 주요 페이로드
최종적으로 인증을 우회하는 데 사용된 핵심 입력 값은 다음과 같습니다.
#ID 필드에 입력
{ "$ne": null }
#비밀번호 필드에 입력
{ "$ne": null }
5.2. 최종 결과
Admin Page 진입에 성공했습니다. 페이지에 나타난 정보를 조합하거나, 다른 메뉴를 탐색하여 최종 Flag를 획득할 수 있습니다.
결과 메시지 확인: "Admin Page" 및 "Concept Details" 섹션 접근 성공.
6. 대응 방안 및 결론
6.1. 보안 대책
- 입력 검증 및 소독: 사용자 입력에서 $, {, }, (, ) 등의 NoSQL 연산자 및 예약어를 포함하는 문자를 서버 측에서 엄격하게 필터링하거나 이스케이프해야 합니다.
- Parameterized Queries 사용: 입력 값이 데이터베이스 쿼리 구조의 일부가 아닌, 단순한 데이터로만 취급되도록 매개 변수화된 쿼리를 사용하여 쿼리 구조와 사용자 데이터를 완벽하게 분리해야 합니다. 사용자 입력을 쿼리 문자열에 직접 연결하는 방식(String Concatenation)은 절대 금지됩니다.
- 최소 권한 원칙: 데이터베이스 연결 계정은 애플리케이션이 필요로 하는 최소한의 권한(읽기/쓰기)만 부여받아야 합니다.
6.2. 결론
이번 실습을 통해 우리는 NoSQL Injection이 MongoDB 환경에서 얼마나 쉽게 인증 로직을 무력화시킬 수 있는지 확인했습니다. 이 취약점의 핵심 원인은 사용자 입력을 데이터가 아닌 쿼리 로직의 일부로 처리하도록 허용한 서버 측의 구현 오류에 있습니다. 실무에서는 개발자들이 NoSQL 환경의 특성을 이해하고, 안전한 API를 사용하여 입력 데이터와 쿼리 구조를 분리하는 것이 안전한 시스템 구축의 가장 중요한 대응 방안입니다.
참고 자료 (References)
'해킹&보안 > 웹' 카테고리의 다른 글
| Command-injection (0) | 2025.10.19 |
|---|---|
| [Writeup] Forbidden Paths (0) | 2025.10.12 |
| [Writeup] SQL Injection (0) | 2025.10.01 |
| CSRF 취약점 A to Z (0) | 2025.09.30 |
| 세션 기반 인증과 JWT 토큰 기반 인증 (0) | 2025.09.27 |