Zephyrnet Logosu

Perde Arkası: Kullanıcı Girişlerine Asla Güvenmeyin

Tarih:

Bu makale, son 8 yıldır çeşitli SaaS ürünlerini ve web sitelerini çalıştırmak hakkında yazdığım bir dizi yazının ilkidir. Ele aldığım bazı konuları, çıkardığım dersleri, yaptığım hataları ve belki de yolunda giden birkaç şeyi paylaşacağım. Bana haber ver ne düşündüğünü!

2019 veya 2020'de arka ucun tamamını yeniden yazmaya karar vermiştim. Göndericiyi engelle, diğer özelliklerin yanı sıra kullanıcıların daha iyi e-posta blokları oluşturmasına yardımcı olan bir SaaS uygulamasıdır. Bu süreçte birkaç yeni özellik ekledim ve çok daha modern teknolojilere geçtim. Testleri yaptım, kodu dağıttım, üretimdeki her şeyi manuel olarak test ettim ve birkaç rastgele ihtimal dışında her şey harika çalışıyor gibi görünüyordu. Keşke bu hikayenin sonu olsaydı ama...

Birkaç hafta sonra, bir müşteri bana hizmetin çalışmadığını ve gelen kutularına engellenmesi gereken çok sayıda e-posta geldiğini bildirdi (ki bu başlı başına utanç vericiydi), bu yüzden araştırdım. Çoğu zaman bu sorun, Google'ın hizmetimizden kullanıcının hesabına olan bağlantıyı kaldırmasından kaynaklanmaktadır; sistem, kullanıcıyı e-posta yoluyla bilgilendirerek ve yeniden bağlanmasını isteyerek bunu yönetir, ancak bu sefer sorun başka bir şeydi.

E-postaları kullanıcı bloklarına göre kontrol eden arka uç çalışanının her 5-10 dakikada bir çökmeye devam ettiği görülüyordu. En tuhaf kısım, günlüklerde hata yoktu, bellek iyiydi, ancak CPU zaman zaman görünüşte rastgele zamanlarda artış gösteriyordu. Yani sonraki 24 saat boyunca (3 saatlik uyku molası ile - kusura bakmayın müşteriler 😬), her çöktüğünde işçiyi manuel olarak yeniden başlatmak zorunda kaldım. Bazı nedenlerden dolayı Elastic Beanstalk hizmeti yeniden başlatmak için çok uzun süre bekliyordu, bu yüzden bunu manuel olarak yapmak zorunda kaldım.

Üretimde hata ayıklama sorunları her zaman bir sıkıntıdır, özellikle de sorunu yerel olarak yeniden oluşturamadığım için, neyin sebep olduğunu bulmak şöyle dursun. Her "iyi" geliştirici gibi ben de kayıt yapmaya yeni başladım her şey ve sunucunun tekrar çökmesini bekledim. CPU periyodik olarak yükseldiğinden, bunun makro bir sorun olmadığını (örneğin belleğinizin bitmesi gibi) ve muhtemelen belirli bir e-posta veya kullanıcıdan kaynaklandığını düşündüm. Bu yüzden onu daraltmaya çalıştım:

  • Belirli bir e-posta kimliği veya türünde mi kilitleniyordu?
  • Belirli bir müşteri için çöküyor muydu?
  • Düzenli aralıklarla mı çöküyordu?

Saatlerce bununla uğraştıktan ve kayıtlara istediğimden daha uzun süre baktıktan sonra, sonunda konuyu belirli bir müşteriye daraltmayı başardım. Bundan sonra arama alanı biraz daraldı; büyük olasılıkla bir engelleme kuralı ya da sunucumuzun tekrar denediği belirli bir e-postaydı. Şans eseri benim için birincisiydi; gizlilik odaklı bir şirket olduğumuz ve herhangi bir e-posta verisini saklamadığımız veya görüntülemediğimiz göz önüne alındığında, hata ayıklaması çok daha kolay bir sorun.

Soruna tam olarak girmeden önce Block Sender'ın özelliklerinden birinden bahsedelim. O zamanlar pek çok müşterim joker karakter engellemeyi talep ediyordu; bu, aynı modeli izleyen belirli türdeki e-posta adreslerini engellemelerine olanak tanıyordu. Örneğin, pazarlama e-posta adreslerinden gelen tüm e-postaları engellemek istiyorsanız joker karakteri kullanabilirsiniz. marketing@* ve ile başlayan herhangi bir adresten gelen tüm e-postaları engeller. marketing@.

Düşünmediğim bir şey de joker karakterlerin nasıl çalıştığını herkesin anlamamasıdır. Çoğu insanın bunları benim geliştirici olarak kullandığım şekilde kullanacağını varsaydım. * herhangi bir sayıda karakteri temsil etmek için. Ne yazık ki, bu özel kullanıcı kullanmanız gerektiğini varsaymıştı. eşleştirmek istediğiniz her karakter için bir joker karakter. Onların durumunda, belirli bir alandan gelen tüm e-postaları engellemek istediler (bu, Göndericiyi Engelle'nin yerel bir özelliğidir, ancak bunu fark etmemiş olmalılar ki bu başlı başına bir sorundur). Yani kullanmak yerine *@example.com, kullandılar **********@example.com.

Bakış Açısı: Kullanıcılarınızın uygulamanızı kullanmasını izlemek...
Bakış Açısı: Kullanıcılarınızın uygulamanızı kullanmasını izlemek…

Çalışan sunucumuzdaki joker karakterleri işlemek için Node.js kitaplığını kullanıyoruz eşleştirici, bu, onu normal bir ifadeye dönüştürerek glob eşleştirmesine yardımcı olur. Bu kütüphane daha sonra **********@example.com aşağıdaki regex'e benzer bir şeye:

/[sS]*[sS]*[sS]*[sS]*[sS]*[sS]*[sS]*[sS]*[sS]*[sS]*@example.com/i

Regex ile herhangi bir deneyiminiz varsa, bunların özellikle hesaplama düzeyinde çok hızlı bir şekilde karmaşık hale gelebileceğini bilirsiniz. Yukarıdaki ifadeyi makul uzunluktaki bir metinle eşleştirmek hesaplama açısından çok pahalı hale gelir ve bu da CPU'nun çalışan sunucumuza bağlanmasına neden olur. Sunucunun birkaç dakikada bir çökmesinin nedeni budur; karmaşık bir normal ifadeyi bir e-posta adresiyle eşleştirmeye çalışırken takılıp kalıyordu. Dolayısıyla, bu kullanıcı her e-posta aldığında, geçici arızaları gidermek için yaptığımız tüm yeniden denemelere ek olarak, sunucumuz çökecektir.

Peki bunu nasıl düzelttim? Açıkçası, hızlı düzeltme, birden fazla joker karakter içeren tüm blokları arka arkaya bulmak ve bunları düzeltmekti. Ancak aynı zamanda kullanıcı girdilerini sterilize etme konusunda daha iyi bir iş yapmam gerekiyordu. Herhangi bir kullanıcı bir normal ifadeye girebilir ve tüm sistemi bir ReDoS saldırısı.

En iyi uygulamalar, endüstri tarafından kabul edilen standartlar ve dahil edilen hile sayfası ile Git'i öğrenmek için uygulamalı, pratik kılavuzumuza göz atın. Googling Git komutlarını durdurun ve aslında öğrenmek o!

Bu özel durumu ele almak oldukça basitti; ardışık joker karakterleri kaldırın:

block = block.replace(/*+/g, '*')

Ancak bu durum uygulamayı yine de diğer ReDoS saldırı türlerine açık bırakıyor. Neyse ki bu türlerde de bize yardımcı olacak bir dizi paket/kütüphane var:

Yukarıdaki çözümlerin ve diğer önlemlerin bir kombinasyonunu kullanarak bunun tekrar olmasını engellemeyi başardım. Ancak bu, kullanıcı girişine asla güvenemeyeceğiniz ve uygulamanızda kullanmadan önce her zaman onu dezenfekte etmeniz gerektiği konusunda iyi bir hatırlatmaydı. Benim başıma gelene kadar bunun potansiyel bir sorun olduğunun farkında bile değildim, umarım bu, başka birinin aynı sorundan kaçınmasına yardımcı olur.

Sorularınız, yorumlarınız mı var ya da kendi hikayenizi paylaşmak mı istiyorsunuz? Bize ulaşın Twitter!

spot_img

En Son İstihbarat

spot_img