Deneme yan\u0131lma ile login bilgilerine eri\u015filmesi<\/h3>\n
Yani eminim herkes bu sald\u0131r\u0131lar\u0131na kar\u015f\u0131 \u00f6nlem alm\u0131\u015ft\u0131r. Ama ben yine de yazmak istedim :) \u00c7\u00fcnk\u00fc buralardan sald\u0131r\u0131 alan projelere \u00e7ok\u00e7a rastlad\u0131m. Sald\u0131rganlar\u0131n elinde genelde bir e-posta\/parola listesi oluyor ve t\u00fcm listeyi sizin \u00fczerinizde deniyorlar. Tek bir kullan\u0131c\u0131 i\u00e7in birden fazla parola denemesi de yap\u0131labilir, birden fazla kullan\u0131c\u0131 bilgisi de denenebilir.
\n"X sitesinin 100.000 kullan\u0131c\u0131s\u0131n parolalar\u0131 ele ge\u00e7irildi" haberlerini mutlaka duymu\u015fsunuzdur. \u0130\u015fte bu parolalar\u0131 \u00e7e\u015fitli sitelerde deniyorlar ve m\u00fc\u015fteri ayn\u0131 parolay\u0131 kulland\u0131ysa ve sald\u0131rgan login olabildiyse; kay\u0131tl\u0131 kartlar\u0131, sadakat puanlar\u0131n\u0131 ya da hesab\u0131 kullanabiliyorlar. Hesap kullan\u0131m\u0131 \u00e7ok enteresan bir konu, bir doland\u0131c\u0131l\u0131k hikayesinin akt\u00f6r\u00fc olabiliyorsunuz.<\/p>\n
- \n
- M\u00fc\u015fterilerinizin hesaplar\u0131 hacklenebilir ve kullan\u0131labilir. M\u00fc\u015fteriniz zarara u\u011frayabilir. <\/li>\n
- Sitenizi kullanarak brute-force\/rainbow table sald\u0131r\u0131lar\u0131 ile m\u00fc\u015fterilerin parolalar\u0131 ele ge\u00e7irilebilir ve o haberlere konu olabilirsiniz.<\/li>\n<\/ol>\n
Not: En \u00e7ok mobile \u00f6zel login endpointleri (captcha vs olmad\u0131\u011f\u0131 i\u00e7in) sald\u0131r\u0131ya a\u00e7\u0131k halde oluyorlar.<\/p>\n
Sitenizdeki hassas verilerin temin edilebilmesi<\/h3>\n
En hassas veri san\u0131yorum ki kullan\u0131c\u0131 bilgileridir. Yine parolam\u0131 unuttum \u00fczerinden yola \u00e7\u0131karsak, bir kullan\u0131c\u0131n\u0131n sitenizde kay\u0131tl\u0131 olup olmad\u0131\u011f\u0131, d\u00f6nd\u00fc\u011f\u00fcn\u00fcz response \u00fczerinden anla\u015f\u0131l\u0131yor olabilir. Bir e-posta forma girildi\u011finde "bu e-posta hesab\u0131 sistemimizde kay\u0131tl\u0131 de\u011fildir" diyorsan\u0131z bir problemimiz var demektir.
\nTabi \u00f6ncelikle bu yan\u0131t\u0131 d\u00fczeltmemiz gerekiyor ve sald\u0131rgana s\u0131r vermememiz gerekiyor. Ama \u00f6ncesinde buraya uygulayaca\u011f\u0131m\u0131z bir rate-limit, sald\u0131rgan\u0131 ba\u015f\u0131m\u0131zdan uzakla\u015ft\u0131rabilir. <\/p>\n- \n
- M\u00fc\u015fterilerinizin var olup olmad\u0131\u011f\u0131 tespit edilebilir. Bu bilgiler sonraki sald\u0131r\u0131larda ya da m\u00fc\u015fterilere y\u00f6nelik yap\u0131lacak ba\u015fka sald\u0131r\u0131larda kullan\u0131labilir. Telefonla polis gibi aray\u0131p "X sitesinde hesab\u0131n\u0131z tespit edildi, para verin" diyebilirler :)<\/li>\n
- Hediye kodu vb. kodlar brute force ile denenebilir ve ge\u00e7erli olanlar s\u0131zd\u0131r\u0131labilir.<\/li>\n<\/ol>\n
3.parti entegrasyonlar\u0131n etkilenmesi<\/h3>\n
En az e-posta sunucusunu me\u015fgul etmemiz kadar \u00f6nemli bir konu buras\u0131. Art\u0131k 3.parti sistemlerle \u00e7al\u0131\u015fmayan websitesi yok. Algolia, Intercom, Segment ve daha bir s\u00fcr\u00fc site ile \u00e7al\u0131\u015f\u0131yoruz. Kendi i\u00e7imizde de cache yap\u0131yoruz, invalidation yap\u0131yoruz. Baz\u0131 i\u015flemlerin s\u00fcrekli tekrarlanmas\u0131, 3. parti sistemleri yorabilir ve bize istenmeyen faturalar \u00e7\u0131kartabilir. \u00d6rne\u011fin Algolia, yap\u0131lan istek say\u0131s\u0131na g\u00f6re fatura kesebiliyor. Belli bir rakam\u0131n \u00fcst\u00fcne \u00e7\u0131k\u0131nca fiyatlar inan\u0131lmaz art\u0131yor.
\nKullan\u0131c\u0131n\u0131z\u0131n bir aksiyonu s\u00fcrekli tekrarlad\u0131\u011f\u0131n\u0131 ve her tekrarlad\u0131\u011f\u0131nda 3. partilere request att\u0131\u011f\u0131m\u0131z\u0131 d\u00fc\u015f\u00fcnelim. Bu durumda bir ddos ile milyonlarca istek gidebilir. <\/p>\n- \n
- 3.parti sistemlere \u00e7ok say\u0131da ve gereksiz istek g\u00f6nderebilir, bunun sonucunda faturalara maruz kalabiliriz. <\/li>\n
- Baz\u0131 istatistiklerimiz etkilenebilir ve bizi yan\u0131ltabilir. <\/li>\n
- Cache invalidation veya veritaban\u0131 i\u015flemleri sunucular\u0131m\u0131z\u0131 me\u015fgul edebilir. <\/li>\n<\/ol>\n
\u00c7\u00f6z\u00fcm \u00f6nerileri<\/h2>\n
Loglay\u0131n ve takip edin<\/h3>\n
Yap\u0131lan i\u015flemleri loglamak ve takip etmek en \u00f6nemli konular\u0131n ba\u015f\u0131nda geliyor. Elbette neyi loglayaca\u011f\u0131n\u0131z\u0131, raporlayaca\u011f\u0131n\u0131z\u0131 ve takip edece\u011finizi i\u015fin en ba\u015f\u0131nda bilemeyebilirsiniz. Alarm mekanizmalar\u0131 her zaman kurtar\u0131c\u0131n\u0131z olacakt\u0131r. <\/p>\n
Basit\u00e7e, istek yap\u0131lan sayfalar\u0131n\u0131z\u0131\/servislerinizi loglayabilir ve belli bir s\u00fcre sonra ortalama say\u0131lar\u0131 \u00e7\u0131kartabilirsiniz. Bu noktada bir alarm olu\u015fturup, belli bir oran\u0131n \u00fczerinde istek geldi\u011finde incelemeye alabilirsiniz. Verdi\u011fim \u00f6rneklerden yola \u00e7\u0131karsak, parola s\u0131f\u0131rlama endpointine saatte ortalama X istek geliyor ve bir anda bu say\u0131 3X olarak raporlara yans\u0131yorsa, burada bir anomali var diyebiliriz ve kontrol edebiliriz. Bir s\u00fcre sonra bu s\u00fcreci daha da otomatikle\u015ftirebilirsiniz. <\/p>\n
\u0130stek say\u0131lar\u0131n\u0131 limitleyin<\/h3>\n
Benim s\u0131kl\u0131kla uygulad\u0131\u011f\u0131m y\u00f6ntemlerden ba\u015f\u0131nda gelir. Kullan\u0131c\u0131lara yapacaklar\u0131 i\u015flemler i\u00e7in belli limitler veririm.
\n\u00d6rne\u011fin, bir IP adresi, 1 dakika i\u00e7erisinde maximum 3 kez login olmay\u0131 deneyebilir. 5 dakika i\u00e7erisinde 6 kez deneyebilir.
\nBu kullan\u0131m\u0131 biraz daha geni\u015fletmek gerekiyor tabi. Sadece bir IP adresi baz\u0131nda bakmak yerine, bir kullan\u0131c\u0131 baz\u0131nda da bakabilirsiniz. \u00d6rne\u011fin bir e-mail adresi ile yap\u0131lan denemeleri limitleyebilirsiniz ve belli bir denemeden sonra, o hesap ile giri\u015f yap\u0131lmas\u0131n\u0131 ge\u00e7ici olarak devre d\u0131\u015f\u0131 b\u0131rakabilirsiniz. Hesab\u0131n\u0131n kilitlenmesi elbette sizin kullan\u0131c\u0131lar\u0131n\u0131z\u0131 mutsuz edebilir. Bu noktada da IP kontrol\u00fc veya yapaca\u011f\u0131n\u0131z di\u011fer kontroller devreye girmeli.<\/p>\nE\u011fer bir API servis ediyorsan\u0131z, bu noktada da bir rate-limit uygulaman\u0131z\u0131 \u015fiddetle \u00f6neririm. Belli bir s\u00fcre i\u00e7erisinde belli bir say\u0131da istek atabilirsiniz. Bu noktada sevmeyeni olmayan Stripe d\u00f6k\u00fcman\u0131ndan bir par\u00e7a b\u0131rak\u0131yorum: https:\/\/stripe.com\/docs\/rate-limits<\/a><\/p>\n
![\"\"](\"https:\/\/guven.atbakan.com\/blog\/wp-content\/uploads\/2022\/03\/Screenshot-from-2022-03-24-15-21-19.png\")
<\/p>\nRate-limit belirleme konusunda sizi en \u00e7ok zorlayacak \u015fey, hangi noktalarda rate-limit uygulanaca\u011f\u0131 ve bunun ne olaca\u011f\u0131.Bunun bir form\u00fcl\u00fc yok maalesef. Log k\u0131sm\u0131nda da bahsetti\u011fim gibi, bunu \u00f6l\u00e7meniz ve kendinize uyarlaman\u0131z gerekiyor. Bir de rate limite tak\u0131lan i\u015flemleri de loglarsan\u0131z, insanlar\u0131n ne s\u0131kl\u0131kla rate-limite tak\u0131ld\u0131\u011f\u0131n\u0131 g\u00f6rebilirsiniz. <\/p>\n