퍼센트 인코딩 입문: `%50`과 `P`가 같은 목적지가 되는 이유

한 문장으로 이해하기

이번 사례에서 %50은 대문자 P를 퍼센트 인코딩한 형태입니다. 이 강좌에서 다루는 예는 이 하나뿐입니다. 강좌를 마치면 세 가지를 할 수 있습니다. 첫째, %50과 P의 관계를 자기 말로 설명하기. 둘째, 이렇게 적힌 주소가 어느 시점에 원래 글자로 해석되는지 말하기. 셋째, 해석 시점이 장치마다 다를 때 어떤 일이 생기는지 설명하기. 미리 알아 둘 것은 웹 주소(URL, 인터넷에서 자료의 위치를 가리키는 문자열)가 /이름/ 형태의 경로를 포함한다는 점, 그리고 서버가 그 경로를 보고 실행할 기능을 정한다는 점뿐입니다.

왜 필요한가

이 개념이 왜 중요한지는 실제 사건에서 드러났습니다. 오라클 피플소프트라는 업무용 소프트웨어에 CVE-2026-35273이라는 취약점이 있었습니다. CVE는 공개적으로 식별된 보안 취약점에 붙는 번호입니다. 이 취약점은 로그인 같은 인증 절차 없이도 공격자가 원격에서 명령을 실행할 수 있게 하는 것이었습니다.

공격자는 취약한 경로인 /PSEMHUB/를 그대로 요청하지 않았습니다. 대신 /%50SEMHUB/를 요청했습니다. 글자 그대로의 경로를 찾던 웹 애플리케이션 방화벽, 즉 웹 요청을 검사해 걸러 주는 장치의 규칙이 이 요청을 걸러내지 못했습니다. 같은 목적지를 가리키는 두 문자열이 서로 다르게 처리된 것입니다.

어떻게 이루어지는가

이번 사례에서 관찰된 처리 과정은 다음 세 단계입니다.

1. 요청하는 쪽이 경로의 첫 글자 P를 %50으로 적어 /%50SEMHUB/라는 주소를 보냅니다.
2. 중간에 있는 웹 애플리케이션 방화벽과 리버스 프록시(요청을 받아 뒤쪽 서버로 전달해 주는 중계 프로그램)는 많은 경우 주소를 원래 글자로 되돌리기 전에 경로를 비교합니다. 이때 /%50SEMHUB/는 /PSEMHUB/와 다른 문자열로 보입니다.
3. 요청이 피플소프트 애플리케이션 서버에 도착하면 서버는 주소를 원래 글자로 되돌립니다. 이 되돌리는 작업을 디코딩이라고 합니다. 디코딩 결과 %50은 P가 되고, 서버는 취약한 서블릿, 즉 요청을 받아 처리하는 서버 쪽 프로그램으로 요청을 연결합니다.

핵심은 2단계와 3단계의 시점 차이입니다. 글자를 바꾼 것이 문제의 전부가 아니라, 어느 시점에 해석했는지가 서로 달랐던 것이 결과를 갈랐습니다.

하나의 예시로 따라가기

위에서 본 단계를 하나의 요청으로 이어서 따라가 보겠습니다. 공격자가 /%50SEMHUB/를 보냅니다. 방화벽은 차단 목록에 적힌 /PSEMHUB/와 이 문자열을 비교합니다. 글자가 다르므로 일치하지 않습니다. 요청은 통과합니다.

요청이 피플소프트 애플리케이션 서버에 닿습니다. 서버는 %50을 P로 디코딩합니다. 이제 경로는 /PSEMHUB/입니다. 서버는 이 경로에 해당하는 취약한 서블릿으로 요청을 연결합니다. 그 결과 CVE-2026-35273 취약점이 사용될 수 있는 상태가 됩니다.

같은 요청 하나가 두 곳에서 다르게 읽혔습니다. 방화벽의 문자 그대로 비교하는 규칙에는 /PSEMHUB/와 일치하지 않는 문자열로 보였고, 서버에게는 /PSEMHUB/였습니다. 이것이 이 강좌의 핵심 메시지가 현실에서 나타난 모습입니다.

언제 쓰고 언제 쓰지 않는가

먼저 조심해야 할 오해 하나를 정리하겠습니다. %50이 들어 있다는 사실 하나만으로 그 요청이 공격이라고 판정할 수는 없습니다. 입력 자료가 보여 주는 것은 이번 사건에서 공격자가 이 표기를 사용했다는 사실이며, 모든 퍼센트 인코딩 요청의 성격을 알려 주지는 않습니다. 반대로 안전하다고 단정할 근거도 입력 자료에는 없습니다.

이번 사례에서 확인된 한계는 분명합니다. 글자 모양만 비교하는 방화벽 규칙은 디코딩 뒤에 같아지는 변형을 놓칠 수 있었습니다. 맨디언트는 방화벽에만 의존하지 말고 최신 보안 업데이트를 설치하라고 권고했습니다. 보안 업데이트를 즉시 설치하거나 환경 관리 허브 기능을 끌 수 없는 조직에는 취약한 /PSEMHUB/* 경로의 외부 접근을 차단하라는 권고가 제시됐습니다. 점검할 때는 웹로직 접근 기록에서 /PSEMHUB/와 퍼센트 인코딩된 변형을 함께 찾으라는 권고도 있었습니다. 구글은 공격자가 %50뿐 아니라 다른 퍼센트 인코딩이나 대소문자를 섞은 변형을 쓸 수 있다고 경고했습니다.

핵심 정리와 확인문제

이번 사례에서 %50은 P를 퍼센트 인코딩한 형태이고, 디코딩하면 P로 돌아옵니다. 검사 장치와 서버가 경로를 해석하는 시점이 다르면 같은 목적지가 서로 다른 문자열처럼 처리될 수 있습니다. 이번 사건은 그 차이가 실제로 어떤 결과를 낳는지 보여 줍니다.

확인문제

1. 이번 사례에서 %50과 대문자 P의 관계를 한 문장으로 설명해 보세요.
2. /%50SEMHUB/가 방화벽을 지나 취약한 기능까지 도달할 수 있었던 이유는 무엇인가요?
3. %50이 포함된 요청을 보면 모두 공격으로 판단해도 될까요?

정답과 해설

1. 정답: %50은 대문자 P를 퍼센트 인코딩한 형태이며, 디코딩하면 P가 됩니다. 해설: 이번 사례에서 확인된 관계는 이 한 쌍입니다.
2. 정답: 해석 시점이 달랐기 때문입니다. 해설: 방화벽은 디코딩 전의 문자열로 /PSEMHUB/와 비교해 일치하지 않는다고 판단했고, 피플소프트 애플리케이션 서버는 요청을 디코딩해 P로 되돌린 뒤 취약한 서블릿으로 연결했습니다.
3. 정답: 아닙니다. 해설: 입력 자료는 이번 사건에서 공격자가 이 표기를 썼다는 사실만 보여 주며, 표기 하나로 모든 요청의 성격을 판정할 근거는 제시하지 않습니다. 점검할 때는 원래 글자 형태와 퍼센트 인코딩된 변형을 함께 살펴보라는 권고가 있었습니다.

참고자료

• 퍼센트 인코딩 입문 참고자료
• 퍼센트 인코딩 입문 참고자료