Prototype Pollution 공격을 막기 위해 백엔드 코드 레벨에서 가장 효과적으로 적용할 수 있는 방어 로직 패턴 3가지는 1) 위험 키 필터링을 통한 입력값 검증, 2) 프로토타입이 없는 안전한 데이터 구조 사용(Object.create(null), Map), 3) Object.freeze()와 런타임 플래그를 결합한 다층 방어입니다. 이 가이드는 단순한 패치 적용을 넘어, 취약점의 작동 원리부터 코드 레벨에서 방어 로직을 구현하는 아키텍처적 접근을 제시합니다.
🛡️ 1. 공격 원리와 위험성 이해하기
프로토타입 오염(Prototype Pollution)은 JavaScript 객체 모델의 특성상, 공격자가 예상치 못한 방식으로 객체의 프로토타입 체인을 조작하여 애플리케이션의 로직을 우회하거나 민감한 데이터를 탈취하는 취약점입니다. 이는 주로 JSON 파싱이나 사용자 입력 기반의 객체 병합(Merge) 로직에서 발생합니다.
주요 위험:
- 원격 코드 실행 (RCE) 가능성: 경우에 따라 시스템 명령어 실행으로 이어질 수 있습니다.
- 데이터 변조: 애플리케이션의 핵심 로직 변수나 설정값(Configuration)을 변조할 수 있습니다.
🧱 2. 핵심 방어 전략: 방어 깊이(Defense in Depth) 구축
단일한 패치에 의존하는 것은 위험합니다. 우리는 입력 검증, 데이터 구조 제어, 그리고 런타임 검증을 결합하는 다층 방어 전략을 구축해야 합니다.
2.1. 입력값 검증 (Input Validation)
가장 먼저, 외부에서 들어오는 모든 데이터는 신뢰할 수 없다고 가정해야 합니다.
- 스키마 기반 검증: 입력 데이터가 예상하는 스키마(Schema)를 벗어나는 경우, 즉시 거부해야 합니다.
- 화이트리스트 접근: 허용된 키(Key)와 값(Value)만 사용하도록 강제하는 것이 가장 안전합니다.
2.2. 데이터 구조 제어 (Data Structure Control)
객체 병합(Object Merging) 로직을 구현할 때, 프로토타입 오염을 막는 전용 라이브러리나 함수를 사용해야 합니다.
- 안전한 병합 함수 사용: 일반적인
Object.assign()이나 전용 병합 라이브러리 대신, 프로토타입 오염을 방지하도록 설계된 커스텀 병합 함수를 사용해야 합니다.
2.3. 런타임 검증 (Runtime Validation)
실행 시점에 객체가 예상치 못한 속성을 가지는지 확인하는 것이 중요합니다.
hasOwnProperty()사용: 객체의 속성을 조회할 때 항상obj.hasOwnProperty(key)를 사용하여 프로토타입 체인에서 상속된 속성과의 충돌을 방지해야 합니다.
🛠️ 3. 프로그래밍 레벨의 구체적인 방어 기법
실제 코딩 단계에서 적용할 수 있는 구체적인 기법들입니다.
Object.create(null)활용:
새로운 객체를 생성할 때Object.create(null)을 사용하면, 해당 객체는 프로토타입을 가지지 않습니다. 이는 가장 강력하고 확실한 방법 중 하나로, 외부로부터의 프로토타입 조작 시도를 원천 차단합니다.JSON.parse()사용 시 주의:
JSON 파싱 자체는 안전하지만, 파싱된 객체를 다시 로직에 사용하기 전에 구조 검사를 반드시 거쳐야 합니다.- 직렬화/역직렬화 라이브러리 검토:
사용하는 직렬화 라이브러리가 해당 취약점을 패치했는지 최신 버전으로 유지하고, 가능하다면 안전성이 검증된 대안을 사용해야 합니다.
🚀 요약 및 체크리스트
| 단계 | 목표 | 주요 기술/방어책 | 비고 |
| :— | :— | :— | :— |
| 입력 | 데이터의 무결성 보장 | 스키마 검증, 화이트리스트 접근 | 외부 입력은 무조건 의심한다. |
| 구조 | 객체 생성 시 안전성 확보 | Object.create(null) 사용 | 프로토타입 체인 자체를 비활성화한다. |
| 로직 | 속성 접근 시 안전성 확보 | hasOwnProperty() 검사 의무화 | 상속된 속성과의 충돌을 방지한다. |
| 유지보수 | 취약점 대응 능력 유지 | 라이브러리 및 프레임워크 최신화 | 보안 패치는 필수적이다. |