개발자 도구 · URL 인코더 및 디코더
URL 인코딩은 삭제되지 않습니다. 디코딩된 매개변수는 여전히 이스케이프가 필요합니다.
· 그것이 중요한 이유
URL 인코딩 보안 xss
퍼센트 인코딩은 HTML, SQL 또는 셸이 아닌 URL 구조를 보호합니다. 이 게시물에서는 올바르게 인코딩된 값이 디코딩되는 순간 다시 위험해지는 이유와 이스케이프가 어디에 속하는지 설명합니다.
URL 인코딩만으로는 XSS 공격을 막을 수 없는 이유
"안전한" 매개변수는 전송을 위해 인코딩되었지만 렌더링 전에 디코딩된 경우 스크립트를 실행할 수 있습니다. %3Cimg%20src%3Dx%20onerror%3Dalert%281%29%3E로 백분율 인코딩된 onerror 핸들러가 있는 img 태그와 같은 XSS 페이로드를 고려하세요. 이것이 URL로 이동하고 HTML에 삽입되기 전에 애플리케이션 코드로 디코딩되면 브라우저는 원본 마크업을 보고 핸들러를 실행합니다. 백분율 인코딩은 표현 계층입니다. 근본적인 위협은 변경되지 않습니다.
페이로드는 HTTP 또는 URL 파서에 특별한 의미가 없는 인코딩된 문자열인 경우 전송 중에만 안전합니다. 해독하는 순간 원래의 모습으로 돌아가기 때문에 다시 위험해집니다. 모든 다운스트림 컨텍스트는 데이터를 사용하는 방법에 적합한 자체 이스케이프 규칙을 적용해야 합니다. URL 인코딩은 HTML 이스케이프, SQL 매개변수화 또는 셸 인수 처리를 대체하지 않습니다.
퍼센트 인코딩의 용도 — 연결 시 구분 기호를 명확하게 유지하는 것, 그 이상은 아닙니다.
퍼센트 인코딩이 하는 일은 URL 구조를 정확하게 보호하는 것입니다. 앰퍼샌드는 구분 기호로 재해석되지 않고 쿼리 문자열 구문의 일부로 유지됩니다. 슬래시는 경로 구분자가 되지 않습니다. 물음표는 조각을 시작하지 않습니다. 예약된 문자를 %XX로 인코딩하면 파서는 이를 구문이 아닌 데이터로 처리합니다. 이는 하나의 작업에 적용됩니다. 즉, 연결 시 URL 구조를 명확하게 유지하는 것입니다.
디코딩하면 일방통행 도로가 정확히 반전됩니다. 복원된 바이트는 정확히 인코딩된 바이트이며 그 이상도 그 이하도 아닙니다. HTML에 위험한 문자열은 계속 위험하고, SQL 주입 벡터도 위험하며, 셸 명령도 계속 위험합니다. 백분율 인코딩은 입력 유효성 검사, 삭제 및 보안 경계가 아닙니다. 표현 형식일 뿐입니다.
디코딩은 원래 바이트를 복원하므로 모든 다운스트림 컨텍스트는 원시 값을 다시 볼 수 있습니다.
상황별 이스케이프는 실제 보호가 진정으로 존재하는 곳입니다. HTML 컨텍스트에는 엔터티가 필요합니다. 미만은 <, 초과는 >, 따옴표는 ", 앰퍼샌드는 &가 됩니다. SQL 컨텍스트에는 데이터에서 구조를 분리하는 매개변수화된 쿼리가 필요하여 공격자가 침입하는 것을 방지합니다. 쉘 컨텍스트에는 단어 분할 및 글로빙을 완전히 방지하는 인수 배열이 필요합니다.
각 컨텍스트에는 서로 다른 위험한 문자와 서로 다른 이스케이프 규칙이 있습니다. HTML 엔터티는 SQL 쿼리에서는 무해하지만 보호에는 쓸모가 없습니다. 백슬래시는 일부 데이터베이스에서는 SQL 주입을 방지하지만 다른 데이터베이스에서는 방지하지 않습니다. 쉘 이스케이프는 인용 스타일에 따라 다릅니다. 개발자는 데이터 처리 방법을 선택하기 전에 대상을 이해해야 합니다.
컨텍스트별 이스케이프 — 마크업용 HTML 엔터티, SQL용 매개변수화된 쿼리, 셸용 인수 배열
작동 예: 링크에서 로그, 페이지까지 페이로드를 따라가면 인코딩 및 이스케이프가 발생해야 하는 위치가 표시됩니다. 링크에는 쿼리 매개변수로 인코딩된 XSS 페이로드가 포함되어 있습니다. 서버는 HTTP 요청 본문에 여전히 인코딩된 정보를 수신합니다. 애플리케이션은 쿼리 매개변수를 디코딩하여 페이지에 표시합니다. 출력 이스케이프 없이 브라우저는 페이로드를 HTML로 렌더링하고 실행합니다.
동일한 매개변수가 파일에 기록된 경우 로그 항목에는 디코딩된 페이로드가 명확하게 포함됩니다. 두 번째 애플리케이션은 로그를 읽고 다시 디코딩한 후 이스케이프하지 않고 HTML 페이지에 삽입합니다. 페이로드가 두 번째로 실행됩니다. 각 단계에서 상황에 따라 무엇이 안전한지 결정되었습니다. URL 디코딩은 안전했습니다. 파일 저장은 안전했습니다. 그러나 이스케이프 없이 HTML을 출력하는 것은 치명적이었습니다.
작업된 예: 링크에서 로그, 페이지까지 하나의 페이로드를 따라갑니다 — 인코딩된 위치, 디코딩된 위치, 이스케이프되어야 하는 위치
필터 회피 도구로 인코딩하는 것은 공격자가 16진수 대소문자를 이중으로 인코딩하고 혼합하는 이유를 보여줍니다. 방화벽이 img 태그를 찾는 경우 공격자는 %3Cimg를 보내고 애플리케이션이 한 번 디코딩되기를 희망하지만 방화벽은 그렇지 않습니다. 유효성 검사에서 %3Cimg를 거부하지만 다른 대소문자는 허용하는 경우 동일한 바이트가 동일한 페이로드로 디코딩됩니다. 패턴 일치 인코딩된 입력에 따른 보안은 취약합니다.
디코딩은 정확하고 절대적으로 예측 가능해야 합니다. 표준 형식(소문자 16진수, 알려진 인코딩)은 일관된 정책을 허용하지만 근본적인 문제를 해결하지는 않습니다. 신뢰할 수 있는 접근 방식은 필요한 경우 디코딩을 허용하고 사용 직전에 컨텍스트별 출력 이스케이프를 적용하는 것입니다. 디코딩은 결코 안전하지 않습니다. 전송에만 필요합니다.
필터 회피 도구로 인코딩 — 공격자가 16진수 대소문자를 이중 인코딩하고 혼합하는 이유와 디코딩이 정확해야 하는 이유
전체 XSS 방어를 위해서는 데이터 흐름, 각 단계에서 통과하는 컨텍스트, 각 컨텍스트 이스케이프에 필요한 사항을 완전히 이해해야 합니다. URL 인코딩은 하나의 작은 조각으로, 전송 중에만 구조를 유지합니다. 하지만 원피스 자체는 결코 방어가 아닙니다. 많은 개발자는 인코딩과 정리 작업을 혼동합니다. 둘 다 문자 교체를 포함하지만 완전히 다른 중요한 작업을 수행하기 때문입니다.
웹 애플리케이션 방화벽은 요청 페이로드의 패턴을 감지할 수 있지만 인코딩은 간단한 패턴 일치 기술을 쉽게 회피합니다. WAF 튜닝은 복잡하며 URL 인코딩 이상의 작업입니다. 안정적인 방어는 특정 컨텍스트 및 요구 사항에 적합한 입력 유효성 검사와 결합된 애플리케이션 코드의 출력 이스케이프입니다.
여기서 다루지 않는 내용 — 전체 XSS 방어 가이드 또는 웹 애플리케이션 방화벽 조정
전체 XSS 방어를 위해서는 데이터 흐름, 각 단계에서 통과하는 컨텍스트, 애플리케이션 전체에서 각 컨텍스트 이스케이프에 필요한 사항을 완전히 이해해야 합니다. URL 인코딩은 하나의 작은 조각으로, 전송 중에만 구조를 유지합니다. 하지만 원피스 자체는 결코 방어가 아닙니다. 많은 개발자는 인코딩과 정리 작업을 혼동합니다. 둘 다 문자 교체를 포함하지만 개발 전반에 걸쳐 완전히 다른 중요한 작업을 수행하기 때문입니다.
페이로드를 처음부터 끝까지 테스트하여 전체 프로세스에서 인코딩 및 이스케이프 문제가 실제로 발생하는지 확인합니다. %3Cimg%20src%3Dx%20onerror%3Dalert%281%29%3E를 URL 디코더에 붙여넣으면 마크업처럼 보이는 문자열이 됩니다. 그런 다음 결과를 HTML 엔터티 이스케이퍼에 붙여넣어 어떻게 안전한 텍스트가 되는지 확인하세요. 두 가지 도구는 레이어를 명확하게 보여줍니다.
요약: URL을 인코딩하고 출력을 이스케이프합니다. 두 가지 다른 작업을 위해 URL 인코더 및 디코더와 HTML 엔터티 이스케이퍼가 한 제품에 나란히 배치되는 방법
요점은 인코딩과 이스케이프가 완전히 다른 레이어에서 별개의 문제라는 것입니다. URL 인코딩은 전송된 구조만 보호합니다. 출력 이스케이프는 렌더링된 콘텐츠를 보호합니다. 올바르게 인코딩된 값은 HTML에 도달할 때 출력 이스케이프가 필요합니다. 올바르게 이스케이프된 문자열은 URL에 넣지 않으면 URL 인코딩이 필요하지 않습니다.
올바른 레이어에 올바른 방어를 진정으로 적용합니다. XSS 공격을 막기 위해 URL 인코딩에 의존하지 마십시오. URL 구조를 보존하기 위해 HTML 이스케이프에 의존하지 마십시오. 데이터 흐름을 이해하고 각 단계에서 적절한 변환을 적용하세요. URL 인코더는 인코딩이 수행하는 작업을 확인하는 데 도움이 됩니다. 그런 다음 출력 단계에 HTML 엔터티 이스케이퍼를 사용하십시오.