이중 인코딩된 쿼리 값 하나를 계층별로 복구하기

문제 상황

이중 인코딩은 계층 문제이지 전체 URL을 반복 디코딩하라는 뜻이 아닙니다. `%252F`는 한 번 처리하면 `%2F`, 한 번 더 처리해야 `/`가 됩니다. 첫 결과가 바깥 프로토콜에 필요한 정확한 표현일 수 있고, 두 번째 처리는 `/`, `?`, `&`, `=`, `#`를 활성화해 routing이나 파라미터 경계를 바꿀 수 있습니다. signed callback과 OAuth state는 signature 검증 전에 어느 계층이라도 달라지면 실패할 수 있습니다. 복구하려면 원시 증거를 보존하고 값 하나를 분리하며 각 계층의 소유자를 증명해야 합니다.

공식 출처와 표준

다음 공식 문서는 이 작업 흐름에서 다루는 형식과 보안 경계의 기준입니다. 도구별 실행 검증은 위에 별도로 기록합니다.

• URL Living Standard

  WHATWG

이럴 때 사용하세요

• 쿼리 값에 `%252F`, `%2520`, `%253A`처럼 `%25` 뒤에 16진수 두 자리가 있습니다.
• callback이나 webhook이 slash 또는 path 대신 리터럴 `%2F` 텍스트를 받습니다.
• proxy, SDK, CDN, form library, template이 이미 퍼센트 인코딩된 값을 다시 인코딩했습니다.
• OAuth, SSO, signed redirect가 여러 전송 계층을 지난 뒤 실패합니다.
• 운영 설정을 바꾸기 전에 통제된 1회 변환 결과를 비교해야 합니다.

단계

1. 1단계

   정확한 원시 증거 수집

   가장 이른 로그에서 전체 URL이나 payload를 브라우저 정규화, 자르기, 반복 디코딩 없이 복사합니다. 비밀 값은 별도의 작업 복사본에서만 가립니다.

2. 2단계

   계층을 소유한 쿼리 값 식별

   바깥 URL을 파싱하고 `%25`가 있는 정확한 key를 찾습니다. 인접 key, 반복 key, fragment를 분리해 그 구분자가 데이터처럼 디코딩되지 않게 합니다.

3. 3단계

   디코딩 전 문법 검사

   모든 `%` 뒤에 16진수 두 자리가 있는지 확인합니다. 잘못된 escape와 유효한 `%HH`가 잘못된 UTF-8을 이루는 경우는 다른 실패이므로 어느 쪽도 조용히 고치지 않습니다.

4. 4단계

   분리한 값을 한 번 디코딩

   값 하나에 RFC 3986 컴포넌트 디코딩을 사용합니다. 도구는 자동으로 다른 계층을 바꾸지 않고 한 번 처리한 뒤 유효한 escape가 남으면 경고합니다.

5. 5단계

   남은 계층의 소유자 확인

   결과를 기대 원본 및 프로토콜 문서와 비교합니다. 남은 `%HH`가 같은 분리 값에 속하고 그 단계에서 수신자가 활성 구분자를 기대할 때만 다시 디코딩합니다.

6. 6단계

   생성 지점 수정 후 재검증

   여분의 encode 호출을 소유한 애플리케이션, SDK, proxy, template에서 제거합니다. 바깥 URL을 한 번 다시 만들고 권한 있는 환경에서 signature, allowlist, routing, 수신 값을 확인합니다.

예시

%252Fdocs%2520v1%252Fapi%253Fpage%253D2

%2Fdocs%20v1%2Fapi%3Fpage%3D2

흔한 실수

자주 묻는 질문