Tarayıcıdaki adam saldırısı, kullanıcının tarayıcısına yerleşen zararlı bir bileşenin sayfa içeriğini ve işlemleri kullanıcı farkına varmadan değiştirmesidir. Saldırı şifreleme çözüldükten sonra, yani verinin kullanıcıya gösterildiği katmanda gerçekleşir. Bu nedenle şifreli bağlantı hiçbir koruma sağlamaz. Kullanıcı doğru siteye bağlanmıştır ve adres çubuğunda hiçbir anormallik yoktur.

Saldırının en tehlikeli yanı, gösterilen ile gerçekleşen arasındaki farkın gizlenmesidir. Kullanıcı ekranda kendi girdiği bilgileri görür, ancak sunucuya farklı veriler gider; sunucudan dönen yanıt da kullanıcının beklediği biçimde değiştirilerek gösterilir. Böylece işlem tamamlanana kadar hiçbir şey fark edilmez. Bankacılık dolandırıcılıklarında bu yöntem uzun süredir kullanılmaktadır.

Tarayıcıdaki Adam Nedir?

Tarayıcıdaki adam, kullanıcının tarayıcısına yerleşen zararlı eklenti ya da kod parçasının, sayfa içeriğini ve gönderilen verileri kullanıcıya belli etmeden değiştirdiği saldırı türüdür.

Bileşen bir tarayıcı eklentisi, tarayıcıya enjekte edilen bir kütüphane ya da işletim sistemine yerleşmiş bir zararlı yazılım olabilir. Ortak nokta, tarayıcının işleyişine güvenilir bir konumdan müdahale edebilmesidir. Bankacılık truva atları bu tekniğin en bilinen uygulayıcılarıdır. Aynı teknik kurumsal uygulamalara karşı da kullanılabilir.

Ortadaki Adam Saldırısından Farkı

Ortadaki adam saldırısı ağ üzerinde, iletişim yolunda gerçekleşir; tarayıcıdaki adam ise doğrudan uç noktada, tarayıcının içinde çalışır. Bu fark, savunma yöntemlerini tamamen değiştirir. Ağ tarafındaki şifreleme ve doğrulama önlemleri ikinci saldırıya karşı etkisizdir. Ortadaki adam saldırısı ile karıştırılması bu nedenle yanlış önlem seçimine yol açar.

İkinci fark tespit edilebilirlikle ilgilidir. Ağ katmanındaki müdahaleler trafik analiziyle görülebilirken, tarayıcı içindeki müdahale sunucu tarafında normal bir istek gibi görünür. Sunucu, isteğin gerçek kullanıcıdan geldiğini doğrular; çünkü oturum gerçekten kullanıcının oturumudur. Bu nedenle tespit büyük ölçüde uç nokta ve davranış analizine kalır.

• Yetkisiz ya da aşırı izin isteyen tarayıcı eklentileri
• Zararlı yazılımın tarayıcı süreçlerine kod enjekte etmesi
• Sayfa formlarına ek alanlar ekleyerek bilgi toplama
• İşlem tutarı ya da alıcı bilgisinin arka planda değiştirilmesi
• Ekranda gösterilen bakiye ve onay bilgilerinin sahtelenmesi

Nasıl Bulaşır?

En yaygın bulaşma yolu, kullanıcının kendi kurduğu eklentilerdir. Faydalı görünen bir eklenti, geniş izinler isteyerek ziyaret edilen tüm sayfaların içeriğini okuma ve değiştirme yetkisi kazanır. Eklentinin sahibi değiştiğinde ya da güncellemeyle zararlı kod eklendiğinde, kullanıcı bundan haberdar olmaz. Bu nedenle eklenti izinleri kurulum sırasında dikkatle incelenmelidir.

İkinci yol, sisteme bulaşan bir zararlı yazılımın tarayıcıya müdahale etmesidir. Bu durumda tarayıcı ayarlarında görünür bir değişiklik olmayabilir. Bulaşma genellikle sahte bir güncelleme, korsan yazılım ya da e-posta eki yoluyla gerçekleşir. Zararlı yazılım temizlenmeden tarayıcı davranışı normale dönmez.

Nasıl Tespit Edilir?

Kurumsal ortamda tespitin temeli, kurulu eklentilerin envanterinin çıkarılmasıdır. Onaylı olmayan eklentilerin listelenmesi ve geniş izinli olanların ayrıca incelenmesi ilk adımdır. Tarayıcı yönetim politikalarıyla eklenti kurulumu kısıtlanabilir. Bu kısıtlama, saldırı yüzeyini doğrudan daraltır.

İkinci tespit yolu uç nokta davranış izlemesidir. Tarayıcı süreçlerine yapılan kod enjeksiyonu, olağandışı süreç erişimleri olarak kaydedilir ve uyarı üretebilir. Bu tespit, kayıt kalitesine ve kural setine bağlıdır. Ayrıca tarayıcı adli analizi olay sonrası incelemede belirleyici olur.

Sunucu tarafında ise işlem örüntülerindeki anormallikler değerlendirilir. Alışılmadık alıcı bilgileri, olağandışı tutarlar ve kullanıcı davranışına uymayan işlem sıralamaları risk motorları tarafından işaretlenebilir. Bu yaklaşım, uç noktayı göremeyen kurumlar için önemli bir katmandır.

Korunma Yöntemleri

En etkili yapısal önlem, kritik işlemlerin tarayıcı dışında doğrulanmasıdır. İşlem özetinin ayrı bir cihazda ya da uygulamada gösterilip onaylanması, tarayıcıdaki değişikliği görünür kılar. Onay ekranında alıcı ve tutar bilgisinin yer alması bu yöntemin özüdür. Yalnızca kod girilen doğrulama akışları bu saldırıya karşı koruma sağlamaz.

İkinci önlem, uç nokta hijyenidir. Kullanıcıların yerel yönetici hakkına sahip olmaması, uygulama kurulumunun denetlenmesi ve güncellemelerin düzenli uygulanması bulaşma olasılığını düşürür. Eklenti beyaz listesi uygulaması da kurumsal ortamda etkili sonuç verir. Bu önlemler birlikte uygulandığında saldırının uygulanabilirliği belirgin biçimde azalır.

Kurumsal Uygulamalara Etkisi

Yöntem yalnızca bankacılık uygulamalarını hedeflemez; kurumsal web uygulamaları da aynı teknikle istismar edilebilir. Bir onay ekranında gösterilen tutarın değiştirilmesi, bir yetki talebine ek kalemler eklenmesi ya da bir raporun içeriğinin farklı gösterilmesi mümkündür. Kullanıcı doğru işlemi yaptığını düşünürken farklı bir işlem gerçekleşir. Bu risk, iç uygulamalarda çoğu zaman hiç değerlendirilmez.

Bulut yönetim panelleri de aynı riski taşır. Yönetici, panelde gördüğü yapılandırmanın gerçek durumu yansıttığını varsayar; tarayıcı katmanında bir müdahale varsa bu varsayım geçersizdir. Kritik yapılandırma değişikliklerinin bağımsız bir kanaldan doğrulanması bu nedenle önerilir. Denetim kayıtlarının ayrı bir sistemde incelenmesi de aynı amaca hizmet eder.

Uygulama tarafında alınabilecek bir önlem, kritik işlemlerin sunucu tarafında yeniden özetlenip kullanıcıya farklı bir kanaldan gösterilmesidir. Böylece tarayıcıdaki gösterim ile sunucunun aldığı istek karşılaştırılabilir hâle gelir. Bu yaklaşım ek geliştirme gerektirir ama yüksek riskli işlemlerde karşılığını verir. Risk temelli uygulanması makuldür.

Eklenti Yönetimi ve İzin Modeli

Tarayıcı eklentileri, kurumsal ortamda en az denetlenen yazılım kategorilerinden biridir. Kullanıcılar eklentiyi kendi kurar, izinleri okumadan onaylar ve güncellemeler otomatik uygulanır. Bir eklentinin sahibi değiştiğinde ya da satıldığında, aynı eklenti bir gün zararlı hâle gelebilir. Bu değişiklik kullanıcı tarafından fark edilmez.

Kurumsal yönetim politikalarıyla eklenti kurulumu kısıtlanabilir. Yalnızca onaylı listedeki eklentilerin kurulmasına izin verilmesi en güvenli yaklaşımdır. Liste dar tutulduğunda yönetim yükü de düşük olur. Kullanıcı taleplerinin değerlendirileceği basit bir süreç, yasağın kabul edilebilirliğini artırır.

Onaylanan eklentilerin izinleri de incelenmelidir. “Tüm sitelerdeki verilerinizi okuyun ve değiştirin” iznini isteyen bir eklenti, tanımı gereği bu saldırıyı gerçekleştirebilecek yetkiye sahiptir. İzin kapsamı dar olan alternatifler tercih edilmelidir. İzinler, eklentinin her güncellemesinde yeniden gözden geçirilir.

Olay Sonrası Adımlar

Şüphe durumunda ilk adım cihazın ağdan ayrılması ve kurumsal erişimlerinin kaldırılmasıdır. Ardından cihazdan girilmiş tüm hesapların parolaları, temiz bir cihaz üzerinden değiştirilir. Aynı cihazda parola değiştirmek, saldırganın yeni parolayı da öğrenmesine yol açar. Bu sıralama kritik önemdedir.

İnceleme aşamasında tarayıcı profili, kurulu eklentiler ve süreç kayıtları toplanır. Bulaşmanın kaynağı belirlenmeden cihazın kullanıma döndürülmesi doğru değildir. Temiz kurulum, çoğu durumda en güvenli seçenektir. Zararlı yazılım analizi bulaşmanın başka cihazlara yayılıp yayılmadığını anlamaya yardımcı olur.

Son olarak işlem geçmişi gözden geçirilir. Cihazdan yapılan işlemlerin beklenen değerlerle uyumlu olup olmadığı, ilgili sistem kayıtları üzerinden doğrulanır. Uyumsuzluk bulunması hâlinde ilgili birimler ve gerekiyorsa banka bilgilendirilir. Bu kontrol, saldırının gerçek etkisini ortaya koyar.

Privia Security olarak uç nokta ve tarayıcı katmanındaki bu tür risklerialtyapı ve mimari gözden geçirme kapsamında değerlendiriyor, işlem doğrulama akışlarındaki zayıflıkları raporluyoruz.