---
kind: REFERENCE
slug: prefix-matching-fits-signatures-not-sniffing
title: 접두사 시작 매칭은 시그니처에는 맞고 스니핑 패턴에는 맞지 않는다
topic: fileserver-state-and-fencing
project: clean-architecture-backend-template
status: 게시 전
sourceRevision: 21234e38cdb9a926cbc92bb97a2aee2e4a7d2916
rootTreeNode: reference:prefix-matching-fits-signatures-not-sniffing
verifiedOn:            # 이 기록은 이번 회차에 실행 확인을 하지 않았다
---

# 접두사 시작 매칭은 시그니처에는 맞고 스니핑 패턴에는 맞지 않는다

## 목적

파일 형식 시그니처를 찾는 방법으로 브라우저 스니핑 대상을 찾아, 앞에 바이트를 붙이는 것만으로 우회되는 것을 막는다.

## 규칙

1. 두 문제를 구별한다
   형식 시그니처는 정의상 시작 바이트다. 브라우저 스니핑은 관용적 해석이므로 시작이 아니어도 된다.

2. 스니핑 대상은 포함으로 찾는다
   앞의 일정 구간 안에 마커가 있으면 탐지한다. 시작이어야 한다는 조건을 걸지 않는다.

3. 앞에 붙는 것들을 목록으로 갖는다
   바이트 순서 표시와 널 바이트와 공백과 주석이 흔하다.

4. 탐지 대상은 소비자의 관용도에 맞춘다
   무엇을 실행할지 정하는 것은 브라우저다. 우리 파서가 아니다.

5. 같은 함수를 두 목적에 쓰지 않는다
   한쪽에 맞추면 다른 쪽이 틀린다.

## 적용 조건

업로드 콘텐츠 검증

인라인으로 제공될 수 있는 모든 콘텐츠의 분류

## 예외

형식 시그니처를 확인해 파일 타입을 판정하는 목적이면 시작 매칭이 옳다. 그 경우 그 판정이 보안 결정으로 쓰이지 않아야 한다.

## 예시

실행 가능 콘텐츠 정책이 앞의 1024 바이트에서 마커를 찾되 시작 매칭을 쓴다. 바이트 순서 표시나 널 바이트나 주석을 앞에 붙이면 탐지되지 않고, 브라우저는 그런 파일도 실행한다.

## 관계

- **scriptable 콘텐츠 탐지가 BOM과 NUL과 주석으로 우회된다**
  이 규칙을 만든 사례다.
- **sanitize가 아니라 reject가 기본이다**
  탐지된 콘텐츠를 어떻게 다룰지 정한 규칙이다.