이 항목에서는 국제 지원 기능과 관련된 보안 고려 사항에 대한 정보를 제공합니다. 이를 시작점으로 사용한 다음 기술 관련 보안 고려 사항에 대해 관심 있는 국제 기술에 대한 설명서를 참조할 수 있습니다.
이 항목에는 다음 섹션이 포함되어 있습니다.
- 문자 변환 함수 대한 보안 고려 사항
- 비교 함수 대한 보안 고려 사항
- 파일 이름 문자 집합에 대한 보안 고려 사항
- 국제화된 도메인 이름 대한 보안 고려 사항
- ANSI 함수 대한 보안 고려 사항
- 유니코드 정규화 대한 보안 고려 사항
문자 변환 함수에 대한 보안 고려 사항
MultiByteToWideChar 및 WideCharToMultiByte ANSI와 유니코드 간에 문자를 변환하는 데 가장 일반적으로 사용되는 유니코드 및 문자 집합 함수입니다. 이러한 함수는 입력 및 출력 버퍼의 요소를 다르게 계산하기 때문에 보안 위험을 초래할 가능성이 있습니다. 예를 들어 MultiByteToWideChar 바이트 단위로 계산된 입력 버퍼를 사용하고 변환된 문자를 유니코드 문자 크기의 버퍼에 넣습니다. 애플리케이션이 이 함수를 사용하는 경우 버퍼 오버런을 방지하기 위해 버퍼 크기를 올바르게 조정해야 합니다.
WideCharToMultiByte 기본적으로 1252와 같은 코드 페이지에 대한 "최적" 매핑으로 설정됩니다. 그러나 이러한 유형의 매핑은 동일한 문자열의 여러 표현을 허용하므로 애플리케이션이 공격에 취약할 수 있습니다. 예를 들어 dieresis("Ä")가 있는 라틴어 대문자 A는 라틴어 대문자 A("A")에 매핑될 수 있습니다. 아시아 언어의 유니코드 문자는 슬래시("/")에 매핑될 수 있습니다. 보안 관점에서 WC_NO_BEST_FIT_CHARS 플래그를 사용하는 것이 좋습니다.
일부 코드 페이지(예: 5022x(iso-2022-x) 코드 페이지는 동일한 문자열의 여러 표현을 허용하기 때문에 본질적으로 안전하지 않습니다. 제대로 작성된 코드는 유니코드 형식으로 보안 검사를 수행하지만 이러한 유형의 코드 페이지는 애플리케이션의 공격 감수성을 확장하며 가능하면 피해야 합니다.
비교 함수에 대한 보안 고려 사항
문자열 비교는 잠재적으로 보안 문제를 표시할 수 있습니다. 모든 비교 함수는 약간 다르기 때문에 한 함수는 두 문자열을 동일하게 보고할 수 있고 다른 함수는 서로 다른 것으로 간주할 수 있습니다. 다음은 애플리케이션에서 문자열을 비교하는 데 사용할 수 있는 몇 가지 함수입니다.
- lstrcmpi. 대/소문자를 구분하지 않고 로캘 규칙에 따라 두 문자 문자열을 비교합니다. 이 함수는 같지 않음을 찾거나 문자열의 끝에 도달할 때까지 첫 번째 문자를 서로 비교하고 두 번째 문자를 서로 비교하여 문자열을 비교합니다.
- lstrcmp. lstrcmpi것과 유사한 기술을 사용하여 문자열을 비교합니다. 유일한 차이점은 lstrcmp 대/소문자를 구분하는 문자열 비교를 수행한다는 것입니다.
- CompareString, CompareStringEx(Windows Vista 이상). 애플리케이션 제공 로캘에서 문자열 비교를 수행합니다. CompareStringExCompareString유사하지만 로캘 식별자 대신 로캘 이름 로캘을 식별합니다. 이러한 함수는 사용자가 선택한 로캘 대신 특정 로캘에서 작동한다는 점을 제외하고 lstrcmpi 및 lstrcmp 비슷합니다.
- compareStringOrdinal(Windows Vista 이상). 두 유니코드 문자열을 비교하여 이진 동등성을 테스트합니다. 대/소문자를 구분하지 않는 옵션을 제외하고, 이 함수는 모든 비이진 동등성을 무시하고 언어 정렬 체계에 가중치를 부여하지 않는 코드 요소를 포함하여 모든 코드 포인트가 같은지 테스트합니다. 이 항목에 언급된 다른 비교 함수는 모든 코드 포인트가 같은지 테스트하지는 않습니다.
- FindNLSStringFindNLSStringEx(Windows Vista 이상). 다른 유니코드 문자열에서 유니코드 문자열을 찾습니다. FindNLSStringExFindNLSString비슷합니다. 단, 로캘 식별자 대신 로캘 이름으로 로캘을 식별합니다.
- FindStringOrdinal(Windows 7 이상). 다른 유니코드 문자열에서 하나의 유니코드 문자열을 찾습니다. 애플리케이션은 모든 비언어적 비교에 대해 FindNLSString대신 이 함수를 사용해야 합니다.
lstrcmpi 및 lstrcmp마찬가지로 CompareString 문자열 문자를 문자별로 평가합니다. 그러나 많은 언어에는 여러 문자 요소(예: 전통적인 스페인어의 두 문자 요소 "CH")가 있습니다. CompareString 애플리케이션에서 제공하는 로캘을 사용하여 여러 문자 요소와 lstrcmpi 식별하고 스레드 로캘을 사용할 lstrcmp를 사용하므로 동일한 문자열이 같지 않을 수 있습니다.
CompareString 정의되지 않은 문자를 무시하므로 매우 고유한 많은 문자열 쌍에 대해 0(동일한 문자열을 나타낸)을 반환합니다. 문자열은 문자에 매핑되지 않는 값을 포함하거나 URL의 컨트롤 문자와 같이 애플리케이션의 도메인 외부에 의미 체계가 있는 문자를 포함할 수 있습니다. 이 함수를 사용하는 애플리케이션은 오류 처리기 및 테스트 문자열을 제공하여 사용하기 전에 유효한지 확인해야 합니다.
메모
Windows Vista 이상에서는 CompareStringExCompareString비슷합니다. 보안 문제는 이러한 함수에 대해 동일합니다.
암시적 비교를 만드는 FindNLSString같은 함수에도 유사한 보안 문제가 적용됩니다. 설정된 플래그에 따라 FindNLSString 호출하여 다른 문자열 내에서 한 문자열을 검색한 결과는 상당히 다를 수 있습니다.
메모
Windows Vista 이상에서는 FindNLSStringExFindNLSString비슷합니다. 보안 문제는 이러한 함수에 대해 동일합니다.
파일 이름의 문자 집합에 대한 보안 고려 사항
일본어 시스템에서 사용되는 Windows 코드 페이지 및 OEM 문자 집합에는 백슬래시(\) 대신 엔 기호(\)가 포함됩니다. 따라서 엔 문자는 NTFS 및 FAT 파일 시스템에 금지된 문자입니다. 유니코드를 일본어 코드 페이지에 매핑할 때 변환 함수는 백슬래시(U+005C)와 일반 유니코드 엔 기호(U+00A5)를 동일한 문자에 매핑합니다. 보안상의 이유로 애플리케이션은 일반적으로 FAT 파일 이름으로 사용하기 위해 변환될 수 있는 유니코드 문자열에서 U+00A5 문자를 허용해서는 안 됩니다.
국제화된 도메인 이름에 대한 보안 고려 사항
IDN(국제화된 도메인 이름)은 네트워크 작업 그룹 RFC 3490: IDNA(애플리케이션의 도메인 이름 국제화)지정됩니다. 이 표준에는 여러 가지 보안 문제가 도입되었습니다.
다른 스크립트의 특정 문자를 나타내는 문자 모양은 유사하거나 동일하게 나타날 수 있습니다. 예를 들어 많은 글꼴에서 키릴 자모 소문자 A("a")는 라틴어 소문자 A("a")와 구별할 수 없습니다. "example.com"과 "example.com"는 이름에 라틴어 소문자 A가 있고 다른 하나는 키릴 자모 소문자 A인 두 개의 도메인 이름이라는 것을 시각적으로 알 수 있는 방법은 없습니다. 파렴치한 호스트 사이트는 이 시각적 모호성을 사용하여 스푸핑 공격의 다른 사이트인 척할 수 있습니다.
IDNA에서 IDN에 허용하는 확장 문자 집합에는 특정 스크립트 내에서 스푸핑 가능성이 있습니다. 예를 들어 하이픈-빼기("-" U+002D), 하이픈("—" U+2010), 호환되지 않는 하이픈("-" U+20)이 매우 유사합니다. 11), 그림 대시("\u2012" U+2012), en 대시("–" U+2013) 및 빼기 기호("-" U+2212).
특정 호환성 컴퍼지션에서도 비슷한 문제가 발생합니다. 예를 들어 단일 유니코드 문자 NUMBER TWENTY FULL STOP("20.", U+249B)은 "20"으로 변환됩니다. Punycode로 변환하기 전에 NamePrep 단계의 (U+0032 U+0030 U+002E) 즉, 이 컴퍼지션은 마침표(전체 중지)를 삽입합니다. 이러한 컴퍼지션은 스푸핑 잠재력을 가지고 있습니다.
IDN에서 서로 다른 스크립트를 혼합한다고 해서 스푸핑 또는 기만적인 의도가 반드시 있는 것은 아닙니다. 기술 보고서 #36: 유니코드 보안 고려 사항 XML-Документы.com("Документ"는 "문서"용 러시아어)와 같은 스크립트가 혼합된 합리적인 IDN의 몇 가지 예를 제공합니다.
스푸핑 공격은 IDN으로 제한되지 않습니다. 예를 들어 "rnicrosoft.com"은 "microsoft.com"처럼 보이지만 ASCII 이름입니다. 또한 스푸핑 공격은 이름의 손상으로 인해 발생할 수 있습니다. 잘 알려진 브랜드 이름 다음에 추가 레이블을 추가하거나 보안으로 레이블이 지정된 URL 경로에 브랜드 이름을 포함하면 IDN 사용과 관계없이 초보 사용자를 혼동할 수 있습니다. 일부 로캘의 경우 IDN이 필요하며 이름이 횡설수설처럼 보이게 하므로 이러한 이름의 Punycode 형식은 허용되지 않습니다.
여기에 언급된 보안 문제와 IDNA와 관련된 많은 다른 문제에 대한 자세한 내용은 기술 보고서 #36: 유니코드 보안 고려 사항참조하세요. 이 보고서는 IDNA 관련 보안 문제에 대한 자세한 논의와 함께 애플리케이션에서 의심되는 IDN을 처리하기 위한 제안을 제공합니다.
ANSI 함수에 대한 보안 고려 사항
메모
가능한 경우 세계화된 애플리케이션, 특히 새 애플리케이션에서 유니코드를 사용하는 것이 좋습니다. 유니코드를 사용하지 않는 이유(예: 유니코드를 지원하지 않는 이전 프로토콜 준수)가 재정의된 경우에만 ANSI 함수를 사용해야 합니다.
GetLocaleInfo 및 GetCalendarInfo같은 많은 NLS(국가별 언어 지원) 함수에는 각각 GetLocaleInfoA 및 GetCalendarInfoA 특정 ANSI 버전이 있습니다. 애플리케이션이 Windows NT, Windows 2000, Windows XP 또는 Windows Vista와 같은 유니코드 기반 운영 체제에서 함수의 ANSI 버전을 사용하는 경우 함수가 실패하거나 정의되지 않은 결과를 생성할 수 있습니다. 이러한 운영 체제에서 ANSI 함수를 사용해야 하는 강력한 이유가 있는 경우 애플리케이션에서 전달한 데이터가 ANSI에 유효한지 확인합니다.
유니코드 정규화에 대한 보안 고려 사항
유니코드 정규화는 문자열의 형태를 변경할 수 있으므로 일반적으로 정규화 후에 보안 메커니즘 또는 문자 유효성 검사 알고리즘을 구현해야 합니다. 예를 들어 파일 이름을 허용하지만 경로 이름을 허용하지 않는 웹 인터페이스가 있는 애플리케이션을 고려해 보세요. U+006으로 변경된 전체 너비 U+FF43 U+FF1A U+FF3C U+FF57 U+FF49 U+FF4E U+FF44 U+FF4F U+FF57 U+FF53 (c : \ w i n d o w s) 변경 3 U+001A U+003C U+0077 U+0069 U+006E U+0064 U+006F U+0077 U+0073 (c:\windows) 형식 KC 정규화. 애플리케이션이 정규화를 구현하기 전에 콜론 및 백슬래시 문자가 있는지 테스트하는 경우 결과는 의도하지 않은 파일 액세스일 수 있습니다.
유니코드 정규화는 운영 체제를 안전하게 만드는 요소이지만 정규화는 포괄적인 보안 정책을 대체하는 것은 아닙니다.
관련 항목