Bırakın da sadece birkaç rakam gireyim

 (gendignoux.com/blog)
1 puan yazan GN⁺ 3 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • İsviçre hükümetinin giriş sistemi AGOV’un 6 haneli e-posta doğrulama giriş alanı, Fransız AZERTY klavyelerde sayı girişini işleyemediği için hesap kaydı tamamen engellendi
  • Giriş alanındaki JavaScript, tuş vuruşlarını yakalayıp doğrulama kodunu ayrı bir değişkende saklarken Shift tuşunu yok saydı; bu da sayı girmek için Shift gerektiren AZERTY düzenini fiilen devre dışı bıraktı
  • Firefox·Chromium·Chrome·Safari ile Linux·macOS’un çeşitli kombinasyonlarında aynı hata oluştu; ancak QWERTY klavyede normal çalıştığı için sorun, tarayıcı ya da işletim sistemi yerine klavye düzeni sorunu olarak daraltıldı
  • Resmî desteği kullanmak için de aynı e-posta doğrulamasından geçmek gerekiyordu ve e-posta·telefon gibi alternatif kanallar yoktu; bu yüzden giriş yapamayan kullanıcılar giriş hatasını bildiremiyordu
  • Yerel giriş alanları yerine karmaşık tuş işleme mantığı kullanmak ve ürünü destek kanallarıyla aynı kimlik doğrulama sürecine bağlamak, erişilebilirliği ve arıza müdahalesini birlikte çökertir; bu nedenle basit DOM tabanlı giriş ve bağımsız destek kanalları gerekir

Dijital kimlik altyapısına dönüşen AGOV

Kayıt, e-posta doğrulama adımında takıldı

  • AGOV kayıt süreci, e-posta adresinin gönderilmesinden sonra 6 haneli doğrulama kodunun girilmesiyle başlıyor
  • Doğrulama kodu arayüzü, her rakam için bir tane olmak üzere toplam 6 giriş kutusundan oluşuyor
    • Rakam girildiğinde odak bir sonraki kutuya geçmiyor
    • Mevcut kutuda rakamlar birikmeye devam ediyor ve kırmızı hata durumuna dönüyor
    • Tek tek manuel geçiş yaparak girildiğinde bile en sonunda field required hatası oluşuyor
  • Geliştirici araçlarında DOM değerlerini doğrudan değiştirmeye çalışıldı, ancak göze çarpan bir form değeri yoktu ve web konsoluna da hata kaydedilmedi
  • Farklı e-posta adresleri ya da test@example.com gibi sahte adresler kullanıldığında da sonuç aynıydı
    • example.com, RFC 6761 uyarınca ayrılmış bir alan adıdır

Tarayıcı ve işletim sistemi ihtimali elendi

  • Başta Firefox ve Linux kombinasyonunun desteklenmediğinden ya da CAPTCHA’nın başarısız olduğundan şüphelenildi
    • Doğrulama kodu formu görünmeden hemen önce eu-api.friendlycaptcha.eu adresine bağlanıyordu
    • Resmî gereksinimler belgesi, desteklenen işletim sistemleri olarak yalnızca Windows ve macOS’u listeliyor
    • Buna karşılık güvenlik anahtarı kılavuzunda, Linux ve Firefox’un da desteklendiği yazıyor
  • Aşağıdaki 6 ortam kombinasyonunun tamamında aynı hata oluştu
    • Linux’ta Firefox, Chromium, Chrome
    • macOS’ta Firefox, Safari, Chrome
  • İş dizüstü bilgisayarında girişten sonra otomatik olarak bir sonraki kutuya geçiliyor ve boş kod yerine yanlış kod anlamına gelen Code entered is incorrect hatası da normal şekilde gösteriliyordu
  • Bir arkadaşın macOS bilgisayarında da üç tarayıcının tamamı doğrulama kodunu kabul etti
  • Kamu hizmetleriyle uzun vadede etkileşim kurmak için işverenin verdiği bilgisayara güvenilemezdi; ayrıca iş bilgisayarında kayıt olunsa bile kişisel dizüstü bilgisayarda giriş yapamama ihtimali sürüyordu

Sorun bildirimini bile engelleyen destek yapısı

  • Resmî destek yalnızca web formuyla sunuluyordu ve bu form da önce e-posta doğrulama kodu girmeyi gerektiriyordu
  • SSS, katılımcı kurum desteğinin mesai saatleri içinde yalnızca çevrimiçi bilet oluşturma yoluyla sağlandığını belirtiyor
  • Swiss Federal Chancellery’nin posta adresi dışında e-posta ya da telefon numarası yoktu
  • AGOV’a övgü, eleştiri veya talep bırakmaya yarayan geri bildirim işlevi de AGOV veya eşdeğer bir hesapla giriş yapılmasını gerektiriyordu
  • E-posta doğrulamasında başarısız olan kullanıcılar, aynı doğrulama süreci yüzünden sorunu bildiremedikleri bir döngüsel bağımlılığa düşüyordu

  • AGOV Access ve desteklenen cihazlar

    • AGOV Access Android uygulamasının puanı 1,4’tü, ancak Google Play yorumlarında aynı doğrulama kodu sorununa rastlanmadı
    • Yorumlarda güvenlik ve gizlilik odaklı Android türevi işletim sistemi GrapheneOS için birçok destek talebi vardı
    • Resmî SSS’ye göre, izinsiz değişiklikleri önlemeye yönelik güçlendirilmiş çerçeve GrapheneOS ile uyumlu olmadığı için uygulama çalışmıyor
    • Federal Chancellery, tedarikçiye uyumluluğun sağlanması talimatını verdi
    • Şu anda kayıt ve giriş için ikinci doğrulama yöntemi, izin verilen standart iOS·Android akıllı telefonlar veya güvenlik anahtarıdır; her iki durumda da önce e-posta doğrulamasından geçmek gerekir

JavaScript’te bulunan neden

  • Sayfanın yüklediği kaynaklar azdı; ancak karartılmamış, küçültülmüş durumdaki ana JavaScript dosyası 2,4 MB’tı ve açıldığında 100 binden fazla satıra ulaşıyordu
  • field required dizesi aranarak doğrulama kodu durumunu belirleyen mantık bulundu
    • Doğrulama kodu değişkeni yoksa durum REQUIRED olarak ayarlanıyor
    • Uzunluk, istenen kod uzunluğundan farklıysa WRONG olarak işleniyor
    • Uzunluk doğruysa sunucunun e-posta doğrulama sonucuna göre VALID ya da hata durumu kullanılıyor
  • verificationCodeEntered fonksiyonu, tuş vuruşlarını yakalayıp doğrulama kodunu JavaScript değişkeninde topluyor
    • Enter, doğrulama geri çağrısını çalıştırıyor
    • Backspace, mevcut değeri siliyor
    • Yön tuşları ve Tab, giriş kutuları arasında hareket ediyor
    • Normal tuşlar Number(S.key) ile sayıya dönüştürülüp koda kaydediliyor
    • Control, Meta, Shift, v, r gibi tuşlar işlenmeden geri dönülüyor
  • Form gönderilirken DOM değerleri okunmadığı için geliştirici araçları veya tarayıcı eklentileriyle giriş kutuları değiştirilse de bu, JavaScript’in ayrı yönettiği duruma yansımıyor

Rakamların yalnızca AZERTY’de engellenmesinin nedeni

  • Fransız standart AZERTY düzeninde rakam girmek için Shift tuşu gerekir
  • Kod Shift girişini yok saydığı için AZERTY’de rakamın kendisi doğrulama kodu olarak kaydedilemiyordu
  • İş bilgisayarı İngilizce QWERTY düzene sahipti ve sorunu doğrulayan kişiler arasında Fransız yoktu
    • Bunun sonucunda test edilen cihazlar arasında yalnızca iki kişisel dizüstü bilgisayar bozukmuş gibi görünüyordu
  • İşletim sisteminde klavye düzeni başka bir düzene değiştirildiğinde kişisel dizüstü bilgisayarda da giriş normale döndü
    • Tersine, normal çalışan cihaz Fransız düzenine geçirildiğinde aynı hata yeniden üretildi
  • İsviçre’nin standart Fransızca klavyesi, Orta Avrupa’da yaygın olan QWERTZ ailesindendir
    • Fransızca ve Almanca verimli yazılabilir ve rakam girişi için Shift gerekmediğinden aynı hata ortaya çıkmaz
  • Swiss Federal Statistical Office’e göre İsviçre’de Fransız vatandaşı yaklaşık 171.000 kişi yaşıyor; İsviçre devletiyle işlem yapmak zorunda olan sınır ötesi çalışanlar bu sayıya dâhil değil

Kaynak kodu yayımlanana kadarki araştırma kısıtları

  • AGOV SSS’ye göre AGOV kaynak kodu, yasal gereklilikleri karşılamak için Aralık 2026’da yayımlanacak
  • EMBAG Madde 9, federal kurumların görevlerini yerine getirmek için doğrudan geliştirdiği veya geliştirilmesini sağladığı yazılımların kaynak kodunu yayımlamasını gerektiriyor
    • Üçüncü taraf hakları veya güvenlik gerekçeleri yayımı engellediğinde ya da sınırladığında istisna uygulanıyor
  • Yayın kapsamı, AGOV e-ID Verifier dâhil proje hedeflerine ulaşmış AGOV sürümünü içeriyor; sonraki sürümler ise yayımdan sonra hazırlanan sürüm notlarıyla yayımlanacak
  • Bazı hizmetler AGOV’u hâlihazırda zorunlu giriş yöntemi olarak kullansa da kaynak kodu henüz yayımlanmadığı için kullanıcıların geliştiricilere doğrudan hata bildirmesi veya geçici çözümleri paylaşması zordu

Kayıt sonrası doğrulanan kimlik doğrulama kapsamı

  • Klavye düzeni değiştirildikten sonra e-posta adresi doğrulandı ve kayıt güvenlik anahtarıyla tamamlandı
  • Kayıt sırasında ad, telefon numarası ve doğum tarihi girildi; ancak bu bilgiler doğrulanmadı
  • Temel kayıt aşamasında doğrulanan yalnızca iki şey vardı
    • E-posta adresinin gerçekten var olduğu
    • İkinci doğrulama yönteminin izin verilen modelde bir güvenlik anahtarı olduğu veya izin verilen Android·iOS cihazlarda çalışan AGOV Access uygulaması olduğu
  • AGOV, uzaktan kimlik avıyla hesap ele geçirmeye karşı sağlamdır; ancak başka birinin, bir başkasının adı ve kimlik bilgileriyle hesap oluşturmasını temel kayıt aşamasında engellemez
  • Ek doğrulamaya göre, hassas olarak sınıflandırılan hizmetlere erişirken kimlik doğrulaması gerekir
    • Kayıttan hemen sonra henüz böyle bir hizmete erişilmemişti
  • Destek formuyla hata bildirildi, ancak yanıt alınmadı

Tasarımdan çıkarılan dersler

  • Sağlam olmayan giriş ve destek tasarımı

    • 6 giriş alanı ve karmaşık JavaScript mantığıyla gösterişli bir UI yapmak sağlam bir yaklaşım değil
    • Tek bir yerel tarayıcı giriş alanı kullanıp yalnızca görsel biçimi CSS ile süslemek daha iyi
    • Form mantığını DOM’dan tamamen ayırırsanız, gönderim sırasında DOM değerleri okunamaz; ileri düzey kullanıcılar veya tarayıcı eklentileri de giriş değerini değiştiremez
    • Yalnızca tek destek kanalı varsa, o kanalın kendisi bozulduğunda iletişim kurmanın yolu kalmaz; bu yüzden e-posta veya telefon gibi ikinci bir kanal gerekir
    • Ana ürün ve destek kanalına aynı giriş mantığını uygulamak, giriş yapamayan kullanıcıların hata bildirimlerinin kaçırılmasına yol açar
    • Birçok internet hizmetinin durum sayfasını ayrı alan adında tutmasının nedeni de budur
    • Destek talebini e-posta doğrulamasının arkasına koymak spam’i azaltabilir, ancak gerçek kullanıcıların arıza bildirimlerini de azaltır
    • Bazı sistemlerde kullanım zorunlu hâle getirildikten sonra kaynak kodunu yayımlamak, kullanıcıların sorun çözmesini ve hata ya da geçici çözüm paylaşmasını sınırlar
    • Yasal kaynak kodu yayımı, basit bir uyum maddesinin ötesinde gerçek arıza araştırmalarında da yararlıdır

  • Araştırmaya yardımcı olan açık web

    • İlgili JavaScript mantığı karartılmadığı için birkaç dize aramasıyla neden bulunabildi
    • Gelişmiş decompiler’lara veya pahalı LLM’lere gerek kalmadı
    • Kod karartılmış ya da WebAssembly’ye derlenmiş olsaydı nedeni anlamak çok daha fazla zaman alırdı
    • Kod yalnızca onaylı kapalı işletim sistemlerine dağıtılmayıp açık web üzerinden sunulduğu için küçültülmüş hâliyle bile indirip incelenebildi

  • Nedenin belirlenmesini mümkün kılan koşullar

    • Farklı klavye düzenleri kullanan birden fazla dizüstü bilgisayarı karşılaştırmak, tarayıcıya özgü sorun veya ağ sorunu ihtimalini erken azaltmayı sağladı
    • Ancak bunun kullanıcı hatası olmadığını kanıtlamak için her tarayıcı kombinasyonunun ekranını sistematik biçimde yakalamak gerektiğinden, ilk kanıt toplama süreci zaman aldı

İlgili okumalar

1 yorum

 
GN⁺ 3 시간 전
Lobste.rs yorumları

  • İnternette özellikle sevmediğim uygulamalardan biri, web sitelerinin tuş girişlerini yakalayıp kendi kafasına göre işlemesi ve tarayıcıya olduğu gibi iletmemesi.
    Parola alanlarında kopyala-yapıştırı yasaklayan siteler çok daha yaygın, ama bu da aynı sınıfa giriyor ve belki daha da ciddi görünüyor.

    • Tarayıcının yalnızca HTML ve CSS ile yerleşik olarak desteklediği bir özelliği JavaScript ile yeniden uygulamanın neden gerekli olduğunu anlamıyorum.
      Çoğu zaman zorlama gerekçelerle yalnızca karmaşıklık artıyor.

  • Her karakter için ayrı bir giriş alanı koyma yöntemi salgın gibi yayıldı.
    Bir şirket havalı göründüğü için bunu benimseyince, artık herkes kendi sürümünü uyguluyor.

    • Bu UI’ın tek kullanımlık kod girme başarı oranını gerçekten artırıyor olmasına şaşırmam.
      Kullanıcı, ayrıntılı okumasa bile bunun parola alanı olmadığını hemen fark edebilir.

  • İlgili bir örnek olarak Medium once had a bug like this which prevented entering the character 'Ś' var.

  • Başka uygulama yöntemleri düşündüm ama sonuçta sıradan bir <input type="text" />ten daha iyi bir yöntem bulamadım.
    Sıradan bir giriş alanından çok farklı görünmesini sağlayacak CSS süslemeleri konusunda bile tereddüt ediyorum. Girilen değeri büyük kutulara kopyalayarak göstermek mümkün olabilir, ama kullanıcı izin verilen uzunluktan fazla girerse ne yapılacağı gibi türlü sorulara yanıt vermek gerekir; buna katlanmaya değecek kadar büyük bir avantaj yok. En fazla giriş alanının yazı tipini ve boyutunu değiştirirdim.

    • OTP’de en yaygın hata, 1234 yerine 1224 gibi tek bir rakamı yanlış girmek.
      İkinci 2ye tıklayıp 3e basmak en hızlı düzeltme yolu, ama yalnızca HTML+CSS ile uygulanamıyor.
    • Bunun çok saçma bir fikir olduğunu kabul ediyorum, ama tek bir <input type="text" pattern="[0-9]+" minlength=6 maxlength=6> üzerine sıra dışı harf aralığı uygulayarak görsel olarak altı kutu gibi gösterip gösteremeyeceğimizi merak ediyorum.
      Daha kolay yol, kullanıcı tek bir metin giriş alanına yazdığında JavaScript’in DOM’un başka bir yerinde altı kutu çizmesi ve her tuşa basıldığında oluşan input olayıyla bunu güncellemesi.
      Hangisinin erişilebilirlik açısından daha iyi olacağından emin olmak zor. Ekran okuyucu açısından sıradan bir <input> ile dekoratif bir <canvas alt="">ı birlikte kullanan ikinci yöntem aslında daha iyi olabilir; klavye kullanımı da tuhaflaşmaz. Ancak ekran okuyucu dışındaki yardımcı araçları kullanan kullanıcılar için <input>u görsel olarak gizlemek erişilebilirlik felaketi olabilir; bu yüzden çok temkinliyim.

  • Pek çok hizmette olduğu gibi e-postada kodu ve etkinleştirme bağlantısını birlikte sunmak da mümkün.

    Kod girişi: XX XX XX

veya bağlantıya tıklayın: <yönlendirme + kod etkinleştirme bağlantısı>

    Bu da aynı sorunu çözebilir.

    • Kullanıcıları e-postadaki bağlantılara tıklamaya alıştırmanın phishing’e karşı savunmayı gerilettiğini düşünüyorum.
    • Web sitesini dizüstü bilgisayarda açıp e-postayı telefonda aldıysanız kopyala-yapıştır pek rahat değildir.
      Bunu istisnai bir durum olarak görebilirsiniz, ama erişilebilirlik dediğimiz şey tam da böyle istisnaları düzgün ele almaktır.

  • Tridactyl’de de tam olarak aynı sorun var: https://github.com/tridactyl/tridactyl/issues/3257
    İlk olarak 2019’da bildirilmişti; belki bu olay vesilesiyle utançtan da olsa düzeltilir.

  • Bu, çalışan bir web sitesi yapmak yerine bozuk ya da yavaş bir web sitesi yapmak için çok daha fazla çaba gerektiğini bir kez daha gösteriyor.