PunyGuard, Chrome 154 Kiril apple.com kopyasını aynı gösterdikten sonra tüm uluslararası alan adlarını engelliyor

Bir geliştirici, Chrome 154'ün apple.com'un tamamen Kiril alfabesiyle yazılmış bir sahtesini gerçek siteyle tamamen aynı şekilde gösterebildiğinin gösterilmesi üzerine, tüm uluslararası alan adlarını (IDN) engelleyen bir Chrome eklentisi yayınladı. Eklentinin yazarının dev.to'daki bir gönderiye göre, adres çubuğu аррӏө.com — beş Kiril harfi — olduğu gibi, yer değişikliğine dair görünür hiçbir ipucu olmadan gösteriyor. Gönderi, gösterimin kaynağı olarak bir Gizmodo makalesine atıf yapıyor.

Sahte alan adı Chrome'u nasıl atlattı

Chrome'un bu homograf hilelerine karşı köklü bir savunması var: bir alan adı başka bir yazı sistemiyle karıştırılabilecek kabul edilen karakterler içerdiğinde, tarayıcı onu ağ üzerinde kullanılan ASCII kodlaması olan Punycode olarak gösteriyor. Kullanıcı, аррӏө.com'un apple.com gibi görünmesi yerine xn--80a6aa68c8d.com görürdü.

Sorun "kabul edilen" kelimesinde. Chrome'un kararı bir benzeyen karakterler listesine dayanıyor ve yazarın açıkladığına göre Kiril harfi ө (U+04E9) bu listede yoktu. Bu tek eksiklikle birlikte beş Kiril harfinin tamamı olduğu gibi görüntülendi ve gerçek alan adıyla tamamen aynı göründü.

Yazar, bunun bir hatadan çok yöntemin yapısal bir sınırı olduğunu savunuyor: karakter sayısı devasa, görünümleri yazı tipine göre değişiyor ve karıştırılabilir karakterlerin her listesi kalıcı olarak eksik. İnsan gözü de daha iyi durumda değil, çünkü tek karakterlik bir fark dikkatli görsel incelemeyi bile alt ediyor. PunyGuard'ın yanıtı, görünüşe göre yargılamayı tamamen bırakmak.

Tek kural, sıfır yargı

Eklenti tek bir özelliği denetliyor: ana makine adının herhangi bir etiketi (noktayla ayrılmış parça), nasıl görüntülendiğinden bağımsız olarak her uluslararası alan adının ağ üzerinde taşıdığı ön ek olan xn-- ile başlıyor mu? Tek bir Chrome declarativeNetRequest kuralı olarak uygulanıyor ve koşulu şu regex:

^https?://(?:[^/?#]*[.@])?xn--

Kuralları Chrome'un kendisi uyguladığı için eklenti, kullanıcının ziyaret ettiği sayfaları hiç incelemek zorunda kalmıyor. Gönderiden ayrıntılar: kural, example.xn--q9jyb4c gibi IDN üst düzey alan adlarını da yakalıyor, ancak bir etiketin ortasındaki ya da yol ve sorgudaki xn-- ifadesini yok sayıyor. Üst düzey gezinmelere ve gömülü iframe'lere uygulanıyor, resim ve script gibi alt kaynaklara değil. Chrome, eşleştirmeden önce ana makine adını Puncode'a çevirdiği için, IDN'in adres çubuğuna yazılan Unicode olarak, tıklanan bir bağlantı olarak, sunucu tarafı bir yönlendirme olarak ya da başka bir uygulamadan devredilen bir URL olarak gelmesi fark etmiyor.

Bilinçli yan hasar

Tasarım kararları bir mimari karar kaydında belgelenmiş. Yazı tabanlı filtreleme — Kiril'i engellerken kanji ve kanaya izin vermek — reddedilmiş, çünkü izin verilen yazı sistemlerinde de karıştırılabilir karakterler var ve bu sorunu yalnızca başka bir yere taşıyor. Görsel benzerlik eşleştirmesi ise, Chrome'un içinde az önce başarısız olan yaklaşımın aynısı olduğu için reddedilmiş.

İzin listesi yok ve "sadece bu seferlik devam et" düğmesi de yok, çünkü oltalama sonuçta insanları uyarıları tıklatmaya ikna etmeye dayanıyor. Bedel açıkça söylenmiş: 日本語.jp gibi meşru alan adları da engelleniyor. Yazar, bunun kendileri için kabul edilebilir olduğu konusunda açık konuşuyor, Japonca alan adlarından hoşlanmadığını belirtiyor ve aracı öncelikle kendisi için yaptığını, bu uyarının da README'nin en üstüne yakın bir yere yerleştirildiğini söylüyor.

Engelleme mekanizmasında bir ödünleşim daha var. Chrome'un declarativeNetRequest'i ya düz bir engelleme sunuyor — bu da kullanıcıları açıklamasız bir ERR_BLOCKED_BY_CLIENT hatasına bakakalmış halde bırakırdı — ya da bir yönlendirme. Yazar, engelleme sebebinin her zaman net olması için eklentiyle birlikte gelen bir uyarı sayfasına yönlendirmeyi seçmiş. Bu seçim geniş iznini gerektiriyor ve eklenti bunu başka hiçbir şey yapmayarak dengeliyor: content script yok, harici istek yok, saklanan veri yok.

Kod GitHub'da mevcut ve gönderi ayrıca, tarayıcıdan bağımsız çalışan ve yazarın görüşüne göre tartışmasız daha güvenli seçenek olan, Unbound DNS çözümleyicisini kullanan riorist tarafından Japonca olarak açıklanan tamamlayıcı bir tekniğe işaret ediyor.

Neden önemli

Bu küçük bir araç, ama gerçek bir boşluğu görünür kılıyor. Tarayıcıların IDN korumaları sezgisel: özenle derlenmiş karıştırılabilir karakter listelerine dayanıyorlar ve tek bir eksik kayıt, güncel bir Chrome sürümünde beş harfli bir sahtenin apple.com'u kusursuzca taklit etmesi için yeterliydi. PunyGuard ters ucu gösteriyor — görüntülemeye değil ağ formatına anahtarlanmış deterministik bir kural, tarayıcının kendi ağ katmanı tarafından tek bir regex ve sayfa görünürlüğü olmadan uygulanıyor. Meşru hedeflerinin tamamı ASCII olan kullanıcılar için yanlış pozitif maliyeti neredeyse sıfır ve homograf oltalamanın entire bir sınıfı ortadan kalkıyor. Diğer herkes içinse en azından ödünleşimi açık hale getiriyor: kolaylık karşısında, ne kadar dikkatli bakılırsa bakılsın güvenilir biçimde yakalanamayan bir saldırı.