보안 고려 사항: 국가별 기능
이 항목에서는 국제 지원 기능과 관련된 보안 고려 사항에 대한 정보를 제공합니다. 이를 시작점으로 사용한 다음 기술별 보안 고려 사항에 대해 관심 있는 국제 기술에 대한 설명서를 참조할 수 있습니다.
이 항목에는 다음과 같은 섹션이 포함되어 있습니다.
- 문자 변환 함수에 대한 보안 고려 사항
- 비교 함수에 대한 보안 고려 사항
- 파일 이름의 문자 집합에 대한 보안 고려 사항
- 국제화된 도메인 이름에 대한 보안 고려 사항
- 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 이상). 애플리케이션 제공 로캘에서 문자열 비교를 수행합니다. CompareStringEx 는 CompareString과 비슷하지만 로캘 식별자 대신 로캘 이름으로 로 캘을 식별합니다. 이러한 함수는 사용자가 선택한 로캘 대신 특정 로캘에서 작동한다는 점을 제외하고 lstrcmpi 및 lstrcmp 와 유사합니다.
- CompareStringOrdinal (Windows Vista 이상). 두 유니코드 문자열을 비교하여 이진 동등성을 테스트합니다. 대/소문자를 구분하지 않는 옵션을 제외하고 이 함수는 이진이 아닌 모든 동등성을 무시하고 언어 정렬 체계에 가중치가 부여되지 않은 코드 포인트를 포함하여 모든 코드 포인트가 같은지 테스트합니다. 이 항목에 언급된 다른 비교 함수는 모든 코드 포인트가 같은지 테스트하지는 않습니다.
- FindNLSString, FindNLSStringEx (Windows Vista 이상). 다른 유니코드 문자열에서 유니코드 문자열을 찾습니다. FindNLSStringEx 는 로캘 식별자 대신 로캘 이름으로 로캘을 식별한다는 점을 제외하고 FindNLSString과 유사합니다.
- FindStringOrdinal (Windows 7 이상). 다른 유니코드 문자열에서 하나의 유니코드 문자열을 찾습니다. 애플리케이션은 모든 비언어적 비교에 FindNLSString 대신 이 함수를 사용해야 합니다.
lstrcmpi 및 lstrcmp와 마찬가지로 CompareString은 문자열 문자를 문자별로 평가합니다. 그러나 많은 언어에는 여러 문자 요소(예: 전통적인 스페인어의 두 문자 요소 "CH")가 있습니다. CompareString은 애플리케이션에서 제공하는 로캘을 사용하여 여러 문자 요소를 식별하고 lstrcmpi 및 lstrcmp는 스레드 로캘을 사용하므로 동일한 문자열이 같지 않을 수 있습니다.
CompareString 은 정의되지 않은 문자를 무시하므로 매우 고유한 많은 문자열 쌍에 대해 0(동일한 문자열을 나타낸)을 반환합니다. 문자열은 문자에 매핑되지 않는 값을 포함하거나 URL의 컨트롤 문자와 같이 애플리케이션의 도메인 외부에 의미 체계가 있는 문자를 포함할 수 있습니다. 이 함수를 사용하는 애플리케이션은 오류 처리기와 테스트 문자열을 제공하여 사용하기 전에 유효한지 확인해야 합니다.
참고
Windows Vista 이상에서는 CompareStringEx 가 CompareString과 비슷합니다. 보안 문제는 이러한 함수에 대해 동일합니다.
암시적 비교를 하는 FindNLSString과 같은 함수에도 유사한 보안 문제가 적용됩니다. 설정된 플래그에 따라 FindNLSString 을 호출하여 다른 문자열 내에서 하나의 문자열을 검색하는 결과는 상당히 다를 수 있습니다.
참고
Windows Vista 이상에서는 FindNLSStringEx 가 FindNLSString과 유사합니다. 보안 문제는 이러한 함수에 대해 동일합니다.
파일 이름의 문자 집합에 대한 보안 고려 사항
일본어 시스템에서 사용되는 Windows 코드 페이지 및 OEM 문자 집합에는 백슬래시(\) 대신 Yen 기호(\)가 포함됩니다. 따라서 엔 문자는 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("Документ"은 "documents"용 러시아어)과 같은 스크립트가 혼합된 합리적인 IDN의 몇 가지 예를 제공합니다.
스푸핑 공격은 IDN으로 제한되지 않습니다. 예를 들어 "rnicrosoft.com"은 "microsoft.com"처럼 보이지만 ASCII 이름입니다. 또한 이름의 손상으로 스푸핑 공격을 수행할 수 있습니다. 잘 알려진 브랜드 이름 다음에 레이블을 추가하거나 보안으로 레이블이 지정된 URL 경로에 브랜드 이름을 포함하면 IDN 사용에 관계없이 초보 사용자를 혼동할 수 있습니다. 일부 로캘의 경우 IDN이 필요하며 이름이 횡설수설처럼 보이기 때문에 이러한 이름의 Punycode 형식은 허용되지 않습니다.
여기에 언급된 보안 문제와 IDNA와 관련된 많은 기타 문제에 대한 자세한 내용은 기술 보고서 #36: 유니코드 보안 고려 사항을 참조하세요. 이 보고서는 IDNA 관련 보안 문제에 대한 자세한 논의와 함께 애플리케이션에서 의심스러운 IDN을 처리하기 위한 제안을 제공합니다.
ANSI 함수에 대한 보안 고려 사항
참고
가능한 경우 세계화된 애플리케이션, 특히 새로운 애플리케이션에서 유니코드를 사용하는 것이 좋습니다. 유니코드를 사용하지 않는 이유(예: 유니코드를 지원하지 않는 이전 프로토콜 준수)를 재정의하는 이유가 있는 경우에만 ANSI 함수를 사용해야 합니다.
GetLocaleInfo 및 GetCalendarInfo와 같은 많은 NLS(국가 언어 지원) 함수에는 각각 특정 ANSI 버전(이 경우 GetLocaleInfoA 및 GetCalendarInfoA)이 있습니다. 애플리케이션이 유니코드 기반 운영 체제(예: 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+0077 U+0073 (c:\windows) 형식 KC 정규화. 애플리케이션이 정규화를 구현하기 전에 콜론 및 백슬래시 문자가 있는지 테스트하는 경우 결과는 의도하지 않은 파일 액세스일 수 있습니다.
유니코드 정규화는 운영 체제를 안전하게 만드는 요소이지만 정규화는 포괄적인 보안 정책을 대체하는 것이 아니라는 점을 기억하세요.
관련 항목