개발자 도구 · URL 인코더 및 디코더
쿼리 매개변수 내부에 리디렉션 URL을 손상시키지 않고 인코딩
· 작동 방식
URL 인코딩 쿼리 매개변수 보안 인증
하나의 URL을 다른 URL 안에 중첩시키는 것은 퍼센트 인코딩이 잘못되는 가장 일반적인 장소입니다. 이 게시물에서는 내부 URL의 ?, & 및 =를 인코딩해야 하는 이유와 인코딩 방법, 결과 확인 방법을 보여줍니다.
매개변수의 절반을 삭제한 복귀 링크 — 내부 URL 및 외부 쿼리 문자열에 의해 삼켜짐
매개변수의 절반을 삭제한 복귀 링크는 모든 개발자가 접하게 되는 디버깅 패턴입니다. 사용자가 로그인하면 애플리케이션이 ?next=https://example.com/page?id=1&user=alice,로 리디렉션을 시도하고 결국 example.com/page?id=1.에 도달합니다. 내부 URL의 앰퍼샌드는 외부 쿼리 매개변수 사이의 구분 기호로 구문 분석되었습니다. 서로 다른 구분 기호가 있는 두 개의 URL은 내부 URL을 인코딩해야 함을 의미합니다.
하나의 URL을 쿼리 매개변수로 다른 URL 안에 중첩하면 해당 내부 주소는 외부 레이어에 대해 불투명한 데이터가 됩니다. 물음표, 앰퍼샌드 및 등호는 구조적 구분 기호로 읽을 수 없어야 합니다. 백분율 인코딩은 이를 변환합니다. %3F가 되고, &는 %26이 되고, =는 %3D가 됩니다. 그런 다음 외부 파서는 인코딩된 문자열을 하나의 매개변수 값으로 처리합니다.
두 개의 URL, 두 개의 구분 기호 세트 — 내부 URL이 외부 URL에 대한 값일 뿐인 이유
encodeURIComponent는 완전한 보호를 제공합니다. encodeURIComponent("https://example.com/a?b=1&c=2")는 "https%3A%2F%2Fexample.com%2Fa%3Fb%3D1%26c%3D2"를 반환합니다. 모든 구조적 문자는 %XX 표기법이 되므로 외부 파서는 중첩된 구분 기호를 잘못 해석할 수 없습니다. encodeURI와 같은 경쟁 접근 방식은 슬래시와 물음표를 남깁니다. 그대로 유지하고 해당 결과가 쿼리 값이 될 때 모호성을 다시 도입합니다.
서버는 정확히 한 번만 디코딩합니다. 다음 매개변수를 추출한 후 단일 decodeURIComponent 호출은 내부 URL을 원래 형식으로 복원합니다. 결과를 새 쿼리 문자열로 구문 분석하면 올바른 매개변수 구조가 표시됩니다. 동일한 값이 여러 레이어를 통과할 때 이중 디코딩은 위험합니다. %26은(는) 한 번의 디코딩 이후 &가 되고 두 번째 디코딩 이후에는 &를 유지합니다.
전체 내부 URL의 encodeURIComponent - :, / 및 ?를 포함하여 인코딩되는 내용은 무엇입니까?
기본 규칙은 간단합니다. : / ?를 포함하여 URL 구문에서 의미를 갖는 모든 문자입니다. = & #은 쿼리 매개변수 값에 나타날 때 백분율로 인코딩되어야 합니다. 이렇게 하면 외부 파서가 의도한 매개변수 구조만 볼 수 있고 전달하는 값 안에 숨겨진 실수로 구분 기호는 볼 수 없습니다. 이 인코딩을 완전하고 안정적으로 처리하려면 encodeURIComponent를 사용하십시오.
URL 인코더 및 디코더에서 이 인코딩을 테스트합니다. 내부 URL을 붙여넣고 값 모드에서 인코딩한 후 %XX 출력을 관찰합니다. 왕복이 정확하게 일치하는지 확인하려면 디코더 모드를 사용하십시오. 이 도구는 엔드투엔드 인코딩을 보여주므로 결과를 자신 있게 애플리케이션 코드에 직접 복사할 수 있습니다.
작업된 예: ?next=https://example.com/a?b=1&c=2 올바르게 구축 — 서버 측에서 인코딩된 문자열 및 디코드
중요한 보안 경계는 인코딩과 함께 있습니다. 서버는 디코딩된 대상이 실제로 리디렉션하기에 안전한지 확인해야 합니다. 퍼센트 인코딩은 URL 구조를 명확하게 만듭니다. 임의의 URL을 안전하게 만들지는 않습니다. 오픈 리디렉션 취약점은 애플리케이션이 사용자가 제공한 URL을 맹목적으로 따를 때 발생합니다. 검증에는 명시적인 허용 목록, 도메인 확인 또는 사용자 확인이 필요합니다.
인코딩은 구문 분석 문제를 해결합니다. 유효성 검사를 통해 보안 문제가 해결됩니다. 이는 서로 다른 계층에서 별도의 관심사입니다. URL 인코더 및 디코더는 인코딩이 올바르게 수행되었음을 보여줍니다. 서버는 유효성 검사를 추가해야 합니다. 목록을 확인하고 도메인을 확인하거나 확인을 요청하세요. 검증이 없으면 모든 도메인에 대해 올바르게 인코딩된 리디렉션이 악용될 수 있습니다.
오픈 리디렉션 위험 — 서버가 디코딩된 대상을 디코딩하는 것이 아니라 유효성을 검사해야 하는 이유
일반적인 실수가 여기에 누적됩니다. 개발자는 때때로 쿼리 부분만 인코딩하고 슬래시를 그대로 두어 구조를 깨뜨리는 경우가 있습니다. 다른 것들은 ?next=를 포함하여 구성된 전체 매개변수를 인코딩하여 이중 인코딩을 생성합니다. 일부는 디코딩하지 않고 구문 분석하여 인코딩된 구조를 잘못 읽음으로써 유효성을 확인합니다. encodeURIComponent를 사용하여 빌드하면 모든 경우에 일관성과 정확성이 보장됩니다.
또 다른 일반적인 실수는 브라우저가 잘못된 매개변수를 자동으로 수정한다고 신뢰하는 것입니다. URL은 데이터이므로 정확하게 데이터로 취급되어야 합니다. encodeURIComponent는 이 작업의 표준 도구입니다. URL 인코더 및 디코더는 이 프로세스를 로컬로 유지하므로 프로덕션으로 배송하기 전에 정확한 바이트를 확인할 수 있습니다.
일반적인 실수 - 쿼리 부분만 인코딩하거나 브라우저가 이를 수정하도록 신뢰
OAuth 리디렉션_uri 매개변수는 정확히 이와 동일한 패턴을 따릅니다. 인증 서버는 알려진 주소(종종 여러 매개변수가 포함된 완전한 URL)의 클라이언트에 제어권을 전달합니다. 이를 단일 값으로 인코딩하면 매개변수가 전송 후에도 유지되고 클라이언트는 사용하기 전에 한 번 디코딩됩니다. OAuth 흐름에서 잘못 처리된 인코딩으로 인해 토큰 및 콜백 매개변수가 전송 중에 사라집니다.
OAuth의 상태 매개변수는 CSRF 보호를 위해 암호화 서명과 결합된 인코딩을 사용합니다. 조각 식별자는 클라이언트 측에 유지되며 서버로 이동하지 않습니다. URL은 로그, 브라우저 기록 및 리퍼러 헤더에 표시되므로 전달자 토큰은 인코딩에 관계없이 리디렉션 URL에 배치되어서는 안 됩니다.
여기서 다루지 않는 내용 — OAuth 상태 매개변수 및 CSRF 보호 설계
테스트 전략: 실제 매개변수로 내부 URL을 구성하고, 이를 외부 값으로 인코딩하고, 수신 코드에서 디코딩합니다. 디코딩된 결과가 바이트 단위로 원본과 동일한지 확인합니다. 프로덕션 배포 전에 URL 인코더 및 디코더를 사용하세요. 네트워크 트래픽과 로그를 검사하여 올바르게 도착했는지, 인코딩된 데이터가 잘리거나 훼손되지 않았는지 확인하세요.
%2E 대신 %2e와 같은 오타는 올바르게 디코딩될 수 있지만 일관성을 기대하는 보조 시스템에서 왕복 검사에 실패합니다. 다양한 플랫폼에 걸쳐 라이브러리 간의 인코딩 불일치는 드물지만 가능합니다. 전체 왕복 테스트를 통해 생산 문제 및 고객 불만이 발생하기 전에 이를 포착합니다.
요점: 내부 URL을 데이터로 처리합니다. URL 인코더 및 디코더의 단일 값 모드가 이를 완전히 인코딩하고 해당 디코더가 왕복을 확인하는 방법
인코딩 경계는 명확합니다. encodeURIComponent는 입력을 불투명 데이터로 처리하고 예약되지 않은 구두점을 제외한 모든 문자를 이스케이프하여 모든 URL 레이어에 안전하게 중첩되도록 합니다. 검증 경계는 분리되어 있습니다. 디코딩 후 목적지가 사용자가 의도한 곳인지 확인합니다. URL 인코더 및 디코더를 사용하여 인코딩 시연을 끝까지 확인하세요.
내부 URL을 처음부터 데이터로 취급합니다. 단일 쿼리 값으로 인코딩하고 수신 시 정확히 한 번 디코딩한 다음 리디렉션하기 전에 유효성 검사를 적용합니다. URL 인코더 및 디코더는 전체 URL의 백분율 인코딩을 단일 쿼리 값으로 표시하고 로컬에서 왕복을 확인합니다. 인코딩과 유효성 검사는 모두 필수적입니다. 이 도구는 인코딩을 올바르게 처리합니다.