Unicode Normalization
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
This is a summary of: https://appcheck-ng.com/unicode-normalization-vulnerabilities-the-special-k-polyglot/. Check a look for further details (images taken form there).
유니코드 정규화는 문자의 서로 다른 이진 표현이 동일한 이진 값으로 표준화되도록 하는 과정입니다. 이 과정은 프로그래밍 및 데이터 처리에서 문자열을 다룰 때 매우 중요합니다. 유니코드 표준은 두 가지 유형의 문자 동등성을 정의합니다:
정규 동등성: 문자가 인쇄되거나 표시될 때 동일한 모양과 의미를 가지면 정규 동등한 것으로 간주됩니다.
호환 동등성: 문자가 동일한 추상 문자를 나타낼 수 있지만 다르게 표시될 수 있는 약한 형태의 동등성입니다.
네 가지 유니코드 정규화 알고리즘이 있습니다: NFC, NFD, NFKC, NFKD. 각 알고리즘은 정규 및 호환 정규화 기술을 다르게 적용합니다. 더 깊이 있는 이해를 원하시면 Unicode.org에서 이러한 기술을 탐색할 수 있습니다.
유니코드 인코딩을 이해하는 것은 특히 서로 다른 시스템이나 언어 간의 상호 운용성 문제를 다룰 때 중요합니다. 주요 사항은 다음과 같습니다:
코드 포인트와 문자: 유니코드에서 각 문자 또는 기호는 "코드 포인트"라고 하는 숫자 값이 할당됩니다.
바이트 표현: 코드 포인트(또는 문자)는 메모리에서 하나 이상의 바이트로 표현됩니다. 예를 들어, LATIN-1 문자는(영어 사용 국가에서 일반적) 하나의 바이트를 사용하여 표현됩니다. 그러나 더 많은 문자 집합을 가진 언어는 표현을 위해 더 많은 바이트가 필요합니다.
인코딩: 이 용어는 문자가 바이트 시리즈로 변환되는 방식을 나타냅니다. UTF-8은 ASCII 문자가 하나의 바이트로 표현되고, 다른 문자는 최대 네 개의 바이트로 표현되는 일반적인 인코딩 표준입니다.
데이터 처리: 데이터를 처리하는 시스템은 바이트 스트림을 문자로 올바르게 변환하기 위해 사용된 인코딩을 인식해야 합니다.
UTF의 변형: UTF-8 외에도 최소 2바이트(최대 4바이트)를 사용하는 UTF-16 및 모든 문자에 대해 4바이트를 사용하는 UTF-32와 같은 다른 인코딩 표준이 있습니다.
이러한 개념을 이해하는 것은 유니코드의 복잡성과 다양한 인코딩 방법에서 발생할 수 있는 잠재적인 문제를 효과적으로 처리하고 완화하는 데 중요합니다.
유니코드가 동일한 문자를 나타내는 두 개의 다른 바이트를 어떻게 정규화하는지에 대한 예:
유니코드 동등 문자 목록은 여기에서 찾을 수 있습니다: https://appcheck-ng.com/wp-content/uploads/unicode_normalization.html 및 https://0xacb.com/normalization_table
웹앱에서 반환되는 값을 찾을 수 있다면, **‘KELVIN SIGN’ (U+0212A)**을 보내보세요. 이는 "K"로 정규화됩니다 (이를 %e2%84%aa로 보낼 수 있습니다). "K"가 반환된다면, 어떤 종류의 유니코드 정규화가 수행되고 있는 것입니다.
다른 예시: %F0%9D%95%83%E2%85%87%F0%9D%99%A4%F0%9D%93%83%E2%85%88%F0%9D%94%B0%F0%9D%94%A5%F0%9D%99%96%F0%9D%93%83는 유니코드 후에 Leonishan입니다.
사용자 입력으로 SQL 쿼리를 생성하는 데 문자 '를 사용하는 웹 페이지를 상상해 보세요. 이 웹은 보안 조치로 사용자 입력에서 문자 **'**의 모든 발생을 삭제하지만, 그 삭제 후와 쿼리 생성 전에 사용자 입력을 유니코드로 정규화합니다.
그렇다면, 악의적인 사용자는 ' (0x27)에 해당하는 다른 유니코드 문자 %ef%bc%87을 삽입할 수 있습니다. 입력이 정규화되면 단일 인용부호가 생성되고 SQLInjection 취약점이 발생합니다:
흥미로운 유니코드 문자들
o -- %e1%b4%bc
r -- %e1%b4%bf
1 -- %c2%b9
= -- %e2%81%bc
/ -- %ef%bc%8f
--- %ef%b9%a3
#-- %ef%b9%9f
*-- %ef%b9%a1
' -- %ef%bc%87
" -- %ef%bc%82
| -- %ef%bd%9c
다음 문자 중 하나를 사용하여 웹앱을 속이고 XSS를 악용할 수 있습니다:
예를 들어, 제안된 첫 번째 유니코드 문자는 %e2%89%ae 또는 %u226e로 전송될 수 있습니다.
백엔드가 정규 표현식으로 사용자 입력을 확인할 때, 입력이 정규 표현식에 대해 정규화되지만 사용되는 곳에 대해서는 정규화되지 않을 수 있습니다. 예를 들어, Open Redirect 또는 SSRF에서 정규 표현식이 전송된 URL을 정규화할 수 있지만, 그 후 있는 그대로 접근할 수 있습니다.
도구 recollapse ****는 백엔드를 퍼징하기 위해 입력의 변형을 생성할 수 있게 해줍니다. 더 많은 정보는 github와 이 게시물을 확인하세요.
AWS 해킹 배우기 및 연습하기:HackTricks Training AWS Red Team Expert (ARTE) GCP 해킹 배우기 및 연습하기: HackTricks Training GCP Red Team Expert (GRTE)
