Pertimbangan Keamanan: Fitur Internasional

  • Artikel

Topik ini menyediakan informasi tentang pertimbangan keamanan yang terkait dengan fitur Dukungan Internasional. Anda dapat menggunakannya sebagai titik awal dan kemudian melihat dokumentasi untuk teknologi internasional yang menarik untuk pertimbangan keamanan khusus teknologi.

Topik ini berisi bagian berikut.

Pertimbangan Keamanan untuk Fungsi Konversi Karakter

MultiByteToWideChar dan WideCharToMultiByte adalah fungsi Unicode dan set karakter yang paling sering digunakan untuk mengonversi karakter antara ANSI dan Unicode. Fungsi-fungsi ini memiliki potensi menyebabkan risiko keamanan karena menghitung elemen buffer input dan output secara berbeda. Misalnya, MultiByteToWideChar mengambil buffer input yang dihitung dalam byte dan menempatkan karakter yang dikonversi menjadi ukuran buffer dalam karakter Unicode. Ketika aplikasi Anda menggunakan fungsi ini, aplikasi harus mengukur buffer dengan benar untuk menghindari overrun buffer.

WideCharToMultiByte default ke pemetaan "paling cocok" untuk halaman kode, seperti 1252. Namun, jenis pemetaan ini memungkinkan beberapa representasi string yang sama, berpotensi membuat aplikasi Anda rentan terhadap serangan. Misalnya, huruf latin kapital A dengan dieresis ("Ä") dapat memetakan ke huruf latin kapital A ("A"); karakter Unicode dalam bahasa Asia mungkin memetakan ke garis miring ("/"). Penggunaan bendera WC_NO_BEST_FIT_CHARS lebih disukai dari perspektif keamanan.

Beberapa halaman kode, misalnya, halaman kode 5022x (iso-2022-x), secara inheren tidak aman karena memungkinkan beberapa representasi dari string yang sama. Kode yang ditulis dengan benar melakukan pemeriksaan keamanan dalam formulir Unicode, tetapi jenis halaman kode ini memperluas kerentanan serangan aplikasi Anda dan harus dihindari jika memungkinkan.

Pertimbangan Keamanan untuk Fungsi Perbandingan

Perbandingan string berpotensi menghadirkan masalah keamanan. Karena semua fungsi perbandingan sedikit berbeda, satu fungsi mungkin melaporkan dua string sama, sementara fungsi lain mungkin menganggapnya berbeda. Berikut ini adalah beberapa fungsi yang dapat digunakan aplikasi Anda untuk membandingkan string:

  • lstrcmpi. Membandingkan dua string karakter sesuai dengan aturan lokal, tanpa sensitivitas huruf besar/kecil. Fungsi membandingkan string dengan memeriksa karakter pertama satu sama lain, karakter kedua satu sama lain, dan sebagainya, sampai menemukan ketidaksamaan atau mencapai akhir string.
  • lstrcmp. Membandingkan string menggunakan teknik yang mirip dengan lstrcmpi. Satu-satunya perbedaan adalah bahwa lstrcmp melakukan perbandingan string peka huruf besar/kecil.
  • CompareString, CompareStringEx (Windows Vista dan yang lebih baru). Lakukan perbandingan string pada lokal yang disediakan aplikasi. CompareStringEx mirip dengan CompareString, tetapi mengidentifikasi lokal dengan nama lokal alih-alih pengidentifikasi lokal. Fungsi-fungsi ini mirip dengan lstrcmpi dan lstrcmp kecuali bahwa mereka beroperasi pada lokal tertentu alih-alih lokal yang dipilih pengguna.
  • CompareStringOrdinal (Windows Vista dan yang lebih baru). Membandingkan dua string Unicode dengan menguji kesetaraan biner. Kecuali untuk opsi tidak peka huruf besar/kecil, fungsi ini mengabaikan semua kesetaraan non-biner, dan menguji semua titik kode untuk kesetaraan, termasuk titik kode yang tidak diberi bobot apa pun dalam skema pengurutan linguistik. Perhatikan bahwa fungsi perbandingan lain yang disebutkan dalam topik ini tidak menguji semua titik kode untuk kesetaraan.
  • FindNLSString, FindNLSStringEx (Windows Vista dan yang lebih baru). Temukan string Unicode di string Unicode lain. FindNLSStringEx mirip dengan FindNLSString, kecuali bahwa ia mengidentifikasi lokal dengan nama lokal alih-alih pengidentifikasi lokal.
  • FindStringOrdinal (Windows 7 dan yang lebih baru). Menemukan satu string Unicode di string Unicode lainnya. Aplikasi harus menggunakan fungsi ini alih-alih FindNLSString untuk semua perbandingan non-linguistik.

Seperti lstrcmpi dan lstrcmp, CompareString mengevaluasi karakter menurut karakter. Namun, banyak bahasa memiliki elemen beberapa karakter, misalnya, elemen dua karakter "CH" dalam bahasa Spanyol tradisional. Karena CompareString menggunakan lokal yang dilengkapi oleh aplikasi untuk mengidentifikasi elemen multi-karakter dan lstrcmpi dan lstrcmp menggunakan lokal utas, string identik mungkin tidak sama.

CompareString mengabaikan karakter yang tidak terdefinisi, dan dengan demikian mengembalikan nol (menunjukkan string yang sama) untuk banyak pasangan string yang cukup berbeda. String mungkin berisi nilai yang tidak dipetakan ke karakter apa pun atau mungkin berisi karakter dengan semantik di luar domain aplikasi, seperti karakter kontrol dalam URL. Aplikasi yang menggunakan fungsi ini harus menyediakan penangan kesalahan dan string pengujian untuk memastikan bahwa string tersebut valid sebelum menggunakannya.

Catatan

Untuk Windows Vista dan yang lebih baru, CompareStringEx mirip dengan CompareString. Masalah keamanan identik untuk fungsi-fungsi ini.

 

Masalah keamanan serupa berlaku untuk fungsi, seperti FindNLSString, yang membuat perbandingan implisit. Bergantung pada bendera yang diatur, hasil pemanggilan FindNLSString untuk mencari satu string dalam string lain dapat sangat berbeda.

Catatan

Untuk Windows Vista dan yang lebih baru, FindNLSStringEx mirip dengan FindNLSString. Masalah keamanan identik untuk fungsi-fungsi ini.

 

Pertimbangan Keamanan untuk Kumpulan Karakter dalam Nama File

Halaman kode Windows dan set karakter OEM yang digunakan pada sistem bahasa Jepang berisi simbol Yen (¥) alih-alih garis miring terbelakang (\). Dengan demikian, karakter Yen adalah karakter yang dilarang untuk sistem file NTFS dan FAT. Saat memetakan Unicode ke halaman kode bahasa Jepang, fungsi konversi memetakan garis miring terbalik (U+005C) dan simbol Yen Unicode normal (U+00A5) ke karakter yang sama ini. Untuk alasan keamanan, aplikasi Anda biasanya tidak boleh mengizinkan karakter U+00A5 dalam string Unicode yang mungkin dikonversi untuk digunakan sebagai nama file FAT.

Pertimbangan Keamanan untuk Nama Domain Internasional

Nama Domain Internasional (IDN) ditentukan oleh Network Working Group RFC 3490: Internationalizing Domain Names in Applications (IDNA). Standar memperkenalkan sejumlah masalah keamanan.

Glyph yang mewakili karakter tertentu dari skrip yang berbeda mungkin tampak serupa atau bahkan identik. Misalnya, dalam banyak font, huruf kecil Sirilik A ("a") tidak dapat dibedakan dari huruf kecil Latin A ("a"). Tidak ada cara untuk mengetahui secara visual bahwa "example.com" dan "example.com" adalah dua nama domain yang berbeda, satu dengan huruf kecil Latin A dalam namanya, yang lain dengan huruf kecil Sirilik A. Situs host yang tidak berani dapat menggunakan ambiguitas visual ini untuk berpura-pura menjadi situs lain dalam serangan spoofing.

Set karakter yang diperluas yang idna memungkinkan IDN juga memiliki potensi spoofing dalam skrip tertentu. Misalnya, ada kemiripan yang kuat di antara tanda hubung-minus ("-" U+002D), tanda hubung ("—" U+2010), tanda hubung yang tidak melanggar ("-" U+2011), garis putus gambar ("\u2012" U+2012), garis putus-putus ("–" U+2013), dan tanda minus ("−" U+2212).

Masalah serupa muncul dari komposisi kompatibilitas tertentu. Misalnya, karakter Unicode tunggal NUMBER TWENTY FULL STOP ("20.", U+249B) dikonversi menjadi "20." (U+0032 U+0030 U+002E) dalam langkah NamePrep, sebelum konversi ke Punycode. Dengan kata lain, komposisi ini menyisipkan titik (berhenti penuh). Komposisi semacam itu memiliki potensi spoofing.

Pencampuran skrip yang berbeda dalam IDN tidak selalu menunjukkan niat spoofing atau penipuan. Laporan Teknis #36: Pertimbangan Keamanan Unicode memberikan beberapa contoh IDN yang wajar yang berisi campuran skrip, seperti XML-Документы.com ("Документы" adalah bahasa Rusia untuk "dokumen").

Serangan spoofing tidak dibatasi untuk IDN. Misalnya, "rnicrosoft.com" terlihat seperti "microsoft.com", namun ini adalah nama ASCII. Selain itu, serangan spoofing dapat dilakukan dengan merusak nama. Menambahkan label tambahan setelah nama merek terkenal, atau menyertakan nama merek di jalur URL berlabel aman, dapat membingungkan pengguna pemula, terlepas dari penggunaan IDN. Untuk beberapa lokal, IDN diperlukan dan bentuk Punycode dari nama-nama ini tidak dapat diterima, karena membuat nama terlihat seperti gibberish.

Untuk informasi selengkapnya tentang masalah keamanan yang disebutkan di sini, ditambah sejumlah besar masalah lain yang relevan dengan IDNA, lihat Laporan Teknis #36: Pertimbangan Keamanan Unicode. Seiring dengan diskusi terperinci tentang masalah keamanan terkait IDNA, laporan ini menawarkan saran untuk menangani IDN tersangka dalam aplikasi Anda.

Pertimbangan Keamanan untuk Fungsi ANSI

Catatan

Anda disarankan untuk menggunakan Unicode dalam aplikasi global Anda, terutama yang baru, jika memungkinkan. Anda harus menggunakan fungsi ANSI hanya jika Anda memiliki alasan penggantian untuk tidak menggunakan Unicode, misalnya, kesuaian dengan protokol lama yang tidak mendukung Unicode.

 

Banyak fungsi Dukungan Bahasa Nasional (NLS), seperti GetLocaleInfo dan GetCalendarInfo, memiliki versi ANSI tertentu, dalam hal ini, GetLocaleInfoA dan GetCalendarInfoA, masing-masing. Ketika aplikasi Anda menggunakan versi ANSI dari fungsi dengan sistem operasi berbasis Unicode, seperti Windows NT, Windows 2000, Windows XP, atau Windows Vista, fungsi dapat gagal atau menghasilkan hasil yang tidak terdefinisi. Jika Anda memiliki alasan kuat untuk menggunakan fungsi ANSI dengan sistem operasi seperti itu, pastikan bahwa data yang diteruskan oleh aplikasi Anda valid untuk ANSI.

Pertimbangan Keamanan untuk Normalisasi Unicode

Karena normalisasi Unicode dapat mengubah bentuk string, mekanisme keamanan, atau algoritma validasi karakter biasanya harus diimplementasikan setelah normalisasi. Misalnya, pertimbangkan aplikasi dengan antarmuka Web yang menerima nama file, tetapi tidak menerima nama jalur. 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) berubah menjadi U+0063 U+001A U+003C U+0077 U+0069 U+006E U+0064 U+006F U+0077 U+0073 (c:\windows) dengan normalisasi KC bentuk. Jika aplikasi menguji keberadaan karakter titik dua dan garis miring terbalik sebelum menerapkan normalisasi, hasilnya dapat menjadi akses file yang tidak disengaja.

Meskipun normalisasi Unicode adalah elemen dalam membuat sistem operasi aman, ingatlah bahwa normalisasi bukanlah pengganti kebijakan keamanan yang komprehensif.

Set Karakter yang Digunakan dalam Nama File

Konvensi untuk Prototipe Fungsi

Menangani Penyortiran di Aplikasi Anda

Menangani Nama Domain Internasional (IDN)

Unicode