Değişiklik Günlüğü: OWASP İlk 10 Projesi

Web uygulamaları son on yılda karmaşıklık içinde patladı. İletişim formları ve anketler için basit kaplardan tam gelişmiş uygulamalara dönüştüler. Bunları hem boyut hem de performans olarak ağır masaüstü uygulamalarıyla karşılaştırabiliriz. Karmaşıklıktaki hızlı artış ve zengin özelliklere sahip uygulamaların sayısındaki artışla birlikte, tüm uygulama bileşenlerini olabildiğince güvenli hale getirmek için çok fazla zaman ve özen harcamak bir zorunluluk haline geldi. İnternet kullanıcılarının muazzam yükselişi, verileri ve uygulama kullanıcılarını koruma sorununu çözmeyi daha da önemli hale getirdi. İçeri sızmaya çalışan ve dahil olan herkesin şiddetli baş ağrısına neden olan geniş bir tehdit havuzu var.

2001 yılında yeni bir organizasyon devreye girdi. Amacı, web sitelerini ve uygulamaları etkileyen güvenlik sorunlarıyla mücadele etmekti. Uygun şekilde Açık Web Uygulaması Güvenlik Projesi (OWASP) olarak adlandırıldı. Günümüzde kaynaklar yayınlıyor, konferanslar düzenliyor ve web ve uygulama güvenliği konusunda standartlar öneriyor. Web uygulaması güvenliği için fiili bir standart, OWASP İlk On Projesidir. En yaygın on güvenlik tehdidini listeler. Neyin gireceğine karar vermede etkili faktörler, geniş miktarda veri ve topluluk geri bildirimiydi. 2017 yılının sonlarında, projede bir güncelleme yapıldı. Pek çok modern web uygulaması için kritik öneme sahip birkaç yeni konu yerini alırken, bazıları listeden çıktı.

Bu makale, orijinal listeyi tamamlar ve listede yapılan en son değişiklikleri gösterir. Tehditleri tanımlar, daha kolay anlaşılması için açık örnekler sağlamaya çalışır ve güvenlik tehditleriyle mücadele yollarını önerir.

OWASP İlk 10 Listesinden Kaldırılan Sorunlar

2017 güncellemesinden önce, 2013'teki liste en sonuncusuydu. Web uygulamalarının oluşturulma ve tüketilme şekillerindeki değişiklikler göz önüne alındığında, yalnızca kapsamlı bir revizyon yapmak mantıklıydı. Mikro hizmetler pastadan paylarını alıyor ve yeni havalı ve parlak çerçeveler vanilya kodlu savaş teçhizatının yerini alıyor. Bu gerçekler, daha önce sıralanan tehditlerin bir kısmının kaldırıldığı ve bazılarının yerini yenilerinin aldığı anlamına geliyor.

Bu yazıda uzun süredir unutulan konulara dair hafızamızı tazelemenin yanı sıra yeni kötü kurtları tanıtacağız. Tarih hakkında bilgi edinmek, aynı hataları tekrarlamamanın tek kesin yoludur.

Siteler Arası İstek Sahteciliği

Siteler arası istek sahteciliği (CSRF), projenin son yinelemesinde "kaybedenler"den biridir. Birçok modern web çerçevesinin CSRF savunma mekanizmalarını içermesi nedeniyle ortadan kalktı. Böylece uygulamalarınızın tehdide maruz kalma olasılığı hızla azalır.

CSRF'nin listeden çıkmasından bağımsız olarak, hafızamızı tazelemek yine de iyidir. Her zamankinden daha güçlü bir şekilde geri gelmeyeceğinden emin olalım.

Özünde, CSRF bir duman bombası hisseden bir istismardır. Saldırgan, şüpheli olmayan bir kullanıcıyı bir web uygulaması içinde istenmeyen bir istek veya eylem yürütmesi için kandırır. Basitçe söylemek gerekirse, bir saldırgan kurbanını üçüncü taraf bir uygulamaya istek göndermeye zorlar ve kurban gönderilen isteğin farkında değildir. İstek, bir kaynağı almak için bir HTTP GET isteği veya daha da kötüsü, kurbanın kontrolü altındaki bir kaynağı değiştiren bir HTTP POST isteği olabilir. Saldırı sırasında kurban, çoğu zaman arka planda bir şeyler olduğunu fark etmeden her şeyin yolunda olduğunu düşünür. Hava temizlendikten sonra hasar meydana gelir veya bir şeyler eksiktir ve kimse ne olduğunu bilmez.

Hedef uygulamada başarılı önceki kullanıcı kimlik doğrulaması, tuzağın etkili olmasını sağlayan şeydir. Kullanıcı, saldırıdan önce bir noktada bir uygulamada oturum açmıştı. Uygulama, kurbana onları hatırlaması için bir çerez gönderdi. Web tarayıcısı kötü amaçlı bir istek gönderdiğinde, tanımlama bilgisi herhangi bir potansiyel yük ile birlikte otomatik olarak gönderilir ve uygulama, isteği zaten tanıdığı bir kullanıcıya sunmaya itiraz etmez.

En ünlü örneklerden biri, bir kullanıcıyı hesabından saldırganın kontrol ettiği hesaba para transfer etmesi için kandırmaktır. Bir kullanıcı, hesap bakiyesini kontrol etmek için bir e-bankacılık sisteminde oturum açar. Bundan sonra, yeni bir cep telefonunun incelemelerini kontrol etmek için çevrimiçi bir forumu ziyaret ederler. Dinamitle balık tutan bir saldırgan, görünüşte bozuk bir resim köprüsüne sahip bir resim içeren bir inceleme yayınlıyor. Saldırgan, gerçek bir köprü yerine, e-bankacılık sisteminin A hesabından B hesabına para aktarmak için dahili olarak kullandığı bir köprü kullanır: https://payments.dummybank.com?receiver=attacker&amount=100 . Bankacılık sistemi, kimliği doğrulanmış kullanıcıyı gönderici ve “alıcı” parametresinden gelen değeri fonların alıcısı yapar. Saldırgan, elbette, alıcı olarak offshore hesabını belirtir.

Tarayıcı, sayfayı oluştururken görüntüleri otomatik olarak yüklediğinden, istek arka planda gerçekleşir. Bankanın ödeme sistemi bir HTTP GET isteği kullanarak para transferleri uygularsa, felaketin gerçekleşmesini hiçbir şey durduramaz. Örneğin basit olduğunu ve büyük olasılıkla aktarımların HTTP GET aracılığıyla gerçekleştirilmediğini unutmayın. Ancak saldırgan, sadece biraz daha zorlukla, forumun HTML mesaj gönderme formundaki "eylem" niteliğini değiştirmeyi başarabilir. Tarayıcı daha sonra talebi forumun arka ucu yerine bankanın ödeme sistemine gönderir.

Para çalmak, oradaki birçok örnekten sadece biri. Kullanıcıların e-posta adreslerini değiştirmek veya istenmeyen satın almalar yapmak da bu kategoriye girer. Sıklıkla olduğu gibi, sosyal mühendislik ve bazı teknik bilgiler, bir yazılım mühendisliği hatasına karşı etkili bir kaldıraçtır.

Sistemlerinizi tasarlarken aşağıdakileri aklınızda bulundurun:

• Bir kaynağı değiştiren eylemleri kapsüllemek için HTTP GET isteklerini kullanmayın . Bu istekleri yalnızca bilgi almak için kullanmalısınız. Unutmayın, temel kural, GET isteklerini önemsiz kılmaktır.
• Do , HTTP POST isteklerini kullanarak dahili olarak veri aktarırken, verileri bir sorgu dizesi olarak kodlamanın dışında JSON, XML veya başka bir biçimde gönderme eğiliminde olun. Önemsiz bir veri biçimi kullanmak, birinin verileri hizmetinize gönderecek sahte bir HTML formu oluşturma tehlikesini azaltır.
• Benzersiz ve öngörülemeyen bir belirteç oluşturduğunuzdan ve HTML formlarınıza eklediğinizden emin olun. Bu belirteçler ayrıca her istek için benzersiz olmalıdır. Bu tür belirteçlerin varlığını ve doğruluğunu kontrol etmek, meydana gelen tehdit risklerini azaltacaktır. Belirteci bulmak ve sahte isteklerinde kullanmak için, saldırganların sisteminize erişmesi ve doğrudan oradan bir belirteç alması gerekir. Belirteçler yalnızca bir kerelik olduğundan, onları kötü amaçlı kodda yeniden kullanamazlar.

Bu güvenlik açığı, siteler arası komut dosyası çalıştırma (XSS) ile birleştiğinde daha da kötü bir etkiye sahiptir. Bir saldırgan, favori bir web sitesine veya uygulamaya kötü amaçlı kod enjekte edebilirse, saldırının kapsamı çok daha önemli ve tehlikeli hale gelir. Daha da önemlisi, saldırganlar, XSS saldırıları mümkünse CSRF'ye karşı koruma mekanizmalarından bazılarını atlatabilir.

CSRF'nin ortadan kalkmadığını, eskisi kadar yaygın olmadığını unutmayın.

Doğrulanmamış Yönlendirmeler ve Yönlendirmeler

Birçok uygulama, bir eylemi bitirdikten sonra, bir kullanıcıyı aynı uygulamanın başka bir bölümüne, hatta başka bir uygulamaya yönlendirir veya yönlendirir. Örneğin, bir uygulamada başarılı bir şekilde oturum açmak, ana sayfaya veya kullanıcının ilk ziyaret ettiği sayfaya bir yönlendirmeyi tetikler. Çoğu zaman hedef, formun eyleminin veya bağlantı adresinin bir parçasıdır. Yönlendirmeyi veya yönlendirmeyi işleyen bileşen, hedef adresin gerçekten uygulama tarafından oluşturulan adres olduğundan emin olmazsa, potansiyel bir tehdit ortaya çıkar. Bu, "doğrulanmamış yönlendirmeler ve yönlendirmeler" adı verilen bir güvenlik açığıdır.

Doğrulanmamış yönlendirmelerin ve yönlendirmelerin tehlikeli olarak görülmesinin iki ana nedeni, kimlik avı ve kimlik bilgilerinin ele geçirilmesidir. Saldırgan, yeniden yönlendirme/iletme hedef konumunu değiştirmeyi ve kullanıcıyı orijinalinden neredeyse ayırt edilemeyen kötü amaçlı bir uygulamaya göndermeyi başarabilir. Şüphelenmeyen bir kullanıcı, kimlik bilgilerini ve gizli bilgilerini kötü niyetli bir üçüncü tarafa ifşa eder. Ne olduğunu anlamadan, zaten çok geçtir.

Örnek olarak, web uygulamaları sıklıkla son ziyaret edilen sayfaya yönlendirme desteğiyle oturum açmayı uygular. Bunu kolayca yapabilmek için, bir HTML formunun action niteliği http://myapp.example.com/signin?url=http://myapp.example.com/puppies gibi görünebilir. Yavru köpeklerin büyük bir hayranısınız, bu nedenle web sitesi favicon'larını en sevdiğiniz köpek yavrularının küçük resimleriyle değiştiren bir tarayıcı uzantısı yüklemek mantıklıydı. Ne yazık ki, bu bir köpek-yemek-köpek dünyası. Tarayıcı uzantısının yazarı, koşulsuz sevginizden faydalanmaya ve ek bir "özellik" sunmaya karar verdi. En sevdiğiniz köpek hayran sitesini her ziyaret ettiğinizde, formun action özelliğindeki "url" parametresini kendi sitesine bir bağlantıyla değiştirir. Site tıpatıp aynı göründüğü için yavru oyun kartları almak için kredi kartı bilgilerinizi verdiğinizde aslında hobinizi değil kötü niyetli bir saldırganı finanse ediyorsunuz.

Güvenlik açığının çözülmesi, hedeflenen konum olduğundan emin olarak hedef konumun kontrol edilmesini içerir. Bir çerçeve veya kitaplık tam yönlendirme veya iletme mantığını yapıyorsa, uygulamayı kontrol etmek ve gerekirse kodu güncellemek faydalıdır. Aksi takdirde, saldırıya karşı korunmak için manuel kontroller yapmanız gerekir.

Yapabileceğiniz birkaç tür kontrol vardır. En iyi koruma için, bunlardan yalnızca birine bağlı kalmak yerine birkaç yaklaşımın bir kombinasyonunu kullanın.

• Giden URL'yi, kontrol ettiğiniz etki alanını gösterdiğinden emin olarak doğrulayın.
• Açık adresler kullanmak yerine, bunları ön uçta kodlayın ve ardından arka uçta kodlarını çözerek doğrulayın.
• Güvenilir URL'lerden oluşan bir beyaz liste hazırlayın. Yalnızca beyaz listedeki konumlara yönlendirmeye ve yönlendirmeye izin verir. Bir kara listeyi sürdürmek için bu yaklaşımı tercih edin. Kara listeler genellikle yalnızca kötü bir şey olduğunda yeni öğelerle doldurulur. Beyaz listeler daha kısıtlayıcıdır.
• LinkedIn ve diğer bazı uygulamalar tarafından kullanılan bir yaklaşım kullanın: Kullanıcılarınıza bir yönlendirme/iletme onaylamalarını isteyen ve uygulamanızdan ayrıldıklarını açıkça belirten bir sayfa sunun.

Birleştirilmiş Sorunlar

Listedeki sorunların çoğu, ya bilgi eksikliğinden ya da potansiyel tehditlerin yeterince derinlemesine araştırılmasından dolayı uygulamadaki kusurlar olarak etiketlenebilir. Bu nedenlerin her ikisi de deneyim eksikliğine atfedilebilir ve bunları gelecekte dikkate almanın çözümü kolaydır - daha fazlasını öğrendiğinizden ve daha kapsamlı olduğunuzdan emin olun. Özellikle zor olanı, karmaşık bilgisayar sistemleri geliştirme ve sürdürmenin zorluğuyla birlikte çok fazla varsayımda bulunmanın tehlikeli (ama çok insani) özelliğinin bir kombinasyonuna dayanır. Bu kategoriye uyan bir güvenlik açığı "bozuk erişim denetimi"dir.

Bozuk Erişim Kontrolü

Güvenlik açığı, uygulamanın belirli bölümleri için yetkilendirme ve erişim denetiminin yetersiz veya tam olmamasından kaynaklanır. OWASP İlk On Projesinin önceki yinelemelerinde iki sorun vardı: güvenli olmayan doğrudan nesne başvuruları ve eksik işlev düzeyinde erişim denetimi. Şimdi benzerliklerinden dolayı birleştirildiler.

Doğrudan Nesne Referansları

Doğrudan nesne referansları, üzerinde çalıştırılan kaynakları tanımlamak için genellikle URL'lerde kullanılır. Örneğin, bir kullanıcı oturum açtığında, profil tanımlayıcısını içeren bir bağlantıya tıklayarak profilini ziyaret edebilir. Aynı tanımlayıcı veritabanında depolanıyorsa ve profil bilgilerini almak için kullanılıyorsa ve uygulama, kişilerin profil sayfasına yalnızca bir oturum açma sayfası aracılığıyla ulaşabileceğini varsayarsa, URL'deki profil tanımlayıcısının değiştirilmesi, başka bir kullanıcının profil bilgilerini ortaya çıkarır.

http://myapp.example.com/users/15/delete silme profili formunun URL'sini ayarlayan bir uygulama, uygulamada en az 14 başka kullanıcı olduğunu açıkça belirtir. Bu durumda diğer kullanıcıların silme formuna nasıl ulaşılacağını bulmak roket bilimi değildir.

Bu sorunun çözümü, uygulamanın bazı bölümlerine ulaşmak için yalnızca belirli yolların alınabileceğini varsaymadan her kaynak için yetki kontrolleri yapmaktır. Ayrıca, doğrudan referansları kaldırmak ve dolaylı olanları kullanmak, kötü niyetli kullanıcıların referansın nasıl oluşturulduğunu anlamasını zorlaştırdığı için ileriye doğru atılan bir diğer adımdır.

Geliştirme sırasında önlem olarak basit bir durum makine diyagramı yazın. Durumların, uygulamanızdaki farklı sayfaları ve kullanıcıların gerçekleştirebileceği işlemleri geçişleri temsil etmesine izin verin. Bu, özel dikkat gerektiren tüm geçişleri ve sayfaları listelemeyi kolaylaştırır.

İşlev Düzeyinde Erişim Kontrolü Eksik

Eksik işlev düzeyinde erişim denetimi, güvenli olmayan doğrudan nesne başvurularına çok benzer. Bu durumda, kullanıcılar uygulamanın korumalı bölümlerine erişmeye çalışmak için URL'yi veya başka bir parametreyi değiştirir. Erişim düzeylerini inceleyen uygun bir erişim kontrolü yoksa, bir kullanıcı uygulama kaynaklarına ayrıcalıklı erişim veya en azından bunların varlığına dair bir miktar bilgi edinebilir.

Doğrudan nesne referansları için örnekten ödünç alma, Eğer bir uygulama, silme formunu ziyaret eden bir kullanıcının, herhangi bir yetkilendirme yapmadan, sadece süper kullanıcılar silme formunun bağlantısını görebildiği için bir süper kullanıcı olduğunu varsayarsa, büyük bir güvenlik açığı açılır. Bazı UI öğelerinin kullanılabilirliğine güvenmek uygun erişim kontrolü değildir.

Sorun, her zaman uygulamanızın tüm katmanlarında kontroller yaptığınızdan emin olarak çözülür. Ön uç arayüzü, kötü niyetli kullanıcıların etki alanı katmanınıza erişmesinin tek yolu olmayabilir. Ayrıca, erişim düzeyleri hakkında kullanıcılardan aktarılan bilgilere güvenmeyin. Uygun oturum kontrolünü gerçekleştirin ve alınan verileri her zaman iki kez kontrol edin. İstek gövdesinin kullanıcının yönetici olduğunu söylemesi, gerçekten öyle oldukları anlamına gelmez.

Bozuk erişim denetimi artık, dosya sisteminin yanlış yapılandırılması gibi, uygulama düzeyinde veya sistem düzeyinde, yetersiz erişim denetimiyle ilgili tüm sorunları bir araya getiriyor.

OWASP İlk 10 Listesindeki Yeni Sorunlar

Yeni ön uç çerçevelerin ortaya çıkışı ve yeni yazılım geliştirme uygulamalarının benimsenmesi, güvenlik endişelerini tamamen yeni konulara kaydırdı. Yeni teknolojiler, daha önce manuel olarak uğraştığımız bazı yaygın sorunları da çözmeyi başardı. Bu nedenle listeyi revize etmek ve modern trendlere göre ayarlamak faydalı oldu.

XML Dış Varlıkları

XML standardı, belgenin veri türü tanımının (DTD) bir parçası olan, harici varlık adı verilen az bilinen bir fikir sunar. Belge yazarlarının, daha sonra başvurulabilecek ve ana belgeye dahil edilebilecek dış varlıklara bağlantılar belirtmesine olanak tanır. Çok basit bir örnek olacaktır:

 <?xml version="1.0" encoding="ISO-8859-1"?> <!DOCTYPE foo [ <!ELEMENT foo ANY> <!ENTITY bar "baz"> ]> <foo> &bar; </foo>

Ayrıştırma sırasında bir referans &bar; tanımlanan varlığın içeriğiyle değiştirilir, böylece <foo>baz</foo> elde edilir.

Uygulama, harici girdi alıp, herhangi bir kontrol olmaksızın, doğrudan XML belge tanımına dahil ederse, çok çeşitli veri sızıntıları ve saldırılar mümkün olacaktır.

Büyülü olan şey, varlığın basit bir dize olmak zorunda olmamasıdır - dosya sistemindeki bir dosyaya referans olabilir. XML ayrıştırıcısı, belirtilen dosyanın içeriğini almaktan ve onu oluşturulan yanıta dahil etmekten memnuniyet duyacaktır, bu da potansiyel olarak hassas sistem bilgilerini açığa çıkaracaktır. OWASP tarafından gösterildiği gibi, varlığı şu şekilde tanımlayarak sistem kullanıcıları hakkında bilgi elde etmek çok kolay olacaktır.

 <!ENTITY xxe SYSTEM "file:///etc/passwd" >]>

Bu güvenlik açığının özellikle zahmetli bir "özelliği", bir hizmet reddi saldırısını kolayca gerçekleştirme olasılığıdır. Bunu yapmanın kolay bir yolu, /dev/random gibi sonsuz bir dosyanın içeriğini listelemek olabilir. Diğeri, her biri bir öncekine birçok kez atıfta bulunan bir dizi varlık yaratmaktır. Bu, son referansı, ayrıştırılması sistem belleğini tüketebilecek potansiyel olarak çok geniş ve derin bir ağacın köküne dönüştürür. Bu saldırı Milyar Gülüşü olarak da bilinir. Wikipedia'da gösterildiği gibi, bir saldırganın nihai belgeye bir milyar lol eklemesi için bir fırsat üreten bir dizi kukla varlık tanımlanır.

 <?xml version="1.0"?> <!DOCTYPE lolz [ <!ENTITY lol "lol"> <!ELEMENT lolz (#PCDATA)> <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;"> <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;"> <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;"> <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;"> <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;"> <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;"> <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;"> <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;"> <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;"> ]> <lolz>&lol9;</lolz>

XML harici varlık istismarlarının önlenmesi, daha az karmaşık bir veri formatı kullanılarak yapılabilir. JSON, olası saldırılar nedeniyle de bazı önlemler alınması şartıyla iyi bir alternatiftir. XML kitaplıklarının güncellenmesi, harici varlık işleme ve DTD'nin devre dışı bırakılmasıyla birlikte bir zorunluluktur. Her zaman olduğu gibi, güvenilir olmayan kaynaklardan gelen verileri kullanmadan veya belgelerinize eklemeden önce doğrulayın ve sterilize edin.

Güvensiz Seriyi Kaldırma

Geliştiriciler kod yazarken, geliştirdikleri sistemleri yazdıkları kodu kullanarak kontrol etme gücüne sahiptir. Çok az kod yazan veya hatta hiç kod yazmayan üçüncü taraf sistemlerin davranışını kontrol etmek ne kadar harika olurdu? İnsanların mükemmel olmadığı ve kütüphanelerin kusurları olduğu için bu kesinlikle mümkün.

Uygulama durumu ve yapılandırması genellikle serileştirilir ve saklanır. Bazen tarayıcılar, serileştirilmiş veriler geçerli kullanıcıyla sıkı bir şekilde bağlantılıysa, depolama motorları görevi görür. Akıllı olmaya ve işlem süresinden tasarruf etmeye çalışan bir uygulama, bir kullanıcının oturum açtığını belirtmek için bir tanımlama bilgisi kullanabilir. Tanımlama bilgisi yalnızca oturum açma başarılı olduktan sonra oluşturulabileceğinden, kullanıcı adını tanımlama bilgisinde saklamak mantıklıdır. Daha sonra bir kullanıcının kimliği doğrulanır ve tanımlama bilgisinin varlığına ve içeriğine göre yetkilendirilir. İnsanlar kötü niyetli olmasaydı, hiçbir şey ters gidemezdi. Dürüst olmak gerekirse, meraklı da olmamalılar.

Meraklı bir kullanıcı, makinesinde bir tanımlama bilgisi bulursa, şöyle bir şey görebilir:

 {"username": "joe.doe", "expires": "2018-06-01 10:28:16"}

JSON'a serileştirilmiş tamamen geçerli bir Python sözlüğü, bu konuda özel bir şey yok. Her zaman meraklı kullanıcı, uygulamanın oturumu kapatmaya zorlamasını önlemek için son kullanma tarihini değiştirebilir. Daha da meraklı bir kullanıcı, kullanıcı adını "jane.doe" olarak değiştirmeyi deneyebilir. Bu kullanıcı adı mevcut olsaydı, artık özel verilere erişimi olan şüphelenmeyen kullanıcı için yepyeni bir dünya açardı.

Verileri JSON'a serileştirmenin ve her şeyi şeffaf tutmanın basit bir örneği, başınıza gelebilecek en kötü şey değildir. Saldırgan bazı serileştirilmiş verileri değiştirmeyi başarırsa, sisteminizi rastgele kod yürütmeye zorlayacak şekilde değiştirebilir.

İnsanların Python'da kendi makine öğrenimi modellerini yazıp hizmetinize yüklemelerine olanak tanıyan bir REST API oluşturduğunuzu varsayalım. Hizmet, yüklenen modelleri değerlendirecek ve veri kümelerinizi kullanarak bunları eğitecektir. Bu, insanların hızlı ve kolay model oluşturma için bilgi işlem kaynaklarınızı ve çok sayıda kullanılabilir veri kümesini kullanmasına olanak tanır.

Hizmet, kodu düz metin biçiminde saklamaz. Kullanıcılar kodlarını seçer, özel anahtarlarını kullanarak şifreler ve eğitim için API'ye gönderir. Hizmetin bir modeli çalıştırması gerektiğinde, kodun şifresini çözer, seçimini kaldırır ve çalıştırır. İşin zor yanı, turşu protokolünün güvensiz olmasıdır. Kod, seri durumdan çıkarma sırasında rastgele kötü amaçlı kodun yürütülmesine izin verecek şekilde oluşturulabilir.

Python'un turşu protokolü, sınıfların, özel bir nesnenin nasıl seri durumdan çıkarılacağı hakkında bilgi döndüren bir __reduce__ yöntemini tanımlamasına izin verir. Desteklenen dönüş değerlerinden biri, iki bağımsız değişkenden oluşan bir demettir: bir çağrılabilir ve çağrılabilir öğeye iletilecek bir dizi bağımsız değişken. ML model eğitim sisteminizin kod yapısında maksimum esneklik sağlamayı amaçladığını göz önünde bulundurarak aşağıdaki kodu yazmak mümkündür:

 class Algo(object): def run(self): pass def __reduce__(self): import itertools return (list, (itertools.count(1), ))

Nesnenin seri durumundan çıkarılması (seçimsiz hale getirilmesi) gerektiğinde, yalnızca bir argümanla bir işlev list çağrılır. İşlev list , Python'da bir liste oluşturucusudur ve itertools.count işlevi, geçirilen parametreden başlayarak sonsuz bir değer yineleyicisi üretir. Sonsuz bir yineleyiciyi sonlu bir listeye dönüştürmek, sisteminizin performansı ve kararlılığı üzerinde feci sonuçlara yol açabilir.

Bu tür güvenlik açığının tek gerçek tedavisi, harici kaynaklardan gelen verileri seri durumdan çıkarmamayı seçmektir. Bunun mümkün olmaması durumunda, kötü niyetli bir kullanıcı tarafından potansiyel olarak değiştirilen verilerin seri durumdan çıkarılmasını önlemek için bir sağlama toplamı veya dijital imza kullanılması önerilir. Ayrıca, ortaya çıkabilecek sorunların etkilerini sınırlamak için ana sisteminizden ayrılmış bir korumalı alan ortamı kurmaya çalışın.

Verileri seri durumdan çıkarmak için örneğin XML veya JSON'dan harici kitaplıklar kullanırken, gerçek bir seri durumdan çıkarma prosedürü yürütülmeden önce nesne türü kontrolleri yapmanıza izin verenleri seçmeye çalışın. Bu, tek amacı sisteminize zarar vermek olan beklenmedik nesne türlerini yakalayabilir.

Uygulamanızın gerçekleştirdiği diğer tüm eylemlerde olduğu gibi, kapsamlı günlük kaydı ve izlemeyi zorunlu kılın. Sık sık gerçekleşen veya normalden daha fazla başarısız olan seri durumdan çıkarmalar, kötü bir şey olduğunun işaretleridir. Sorunları erken yakalayın.

Yetersiz Kayıt ve İzleme

Uygulamanızda meydana gelen tüm uyarıları ve hataları kaydettiğinizden emin olmak için ne kadar zaman harcıyorsunuz? Yalnızca kodda meydana gelen hataları mı saklıyorsunuz yoksa doğrulama hatalarını da günlüğe kaydediyor musunuz? Alan adınızın iş kuralları karşılanmadığında ne olur? Uygulamanızdaki tüm hatalı ve şüpheli etkinliklerin devam ettirilmemesi, bir güvenlik ve veri uzlaşması sunar.

Aşağıdaki senaryoyu hayal edin. Çoğu kişinin yaptığı gibi, uygulamanız bir oturum açma sayfası içerir. Formda, biri e-posta girmek için, diğeri şifre için olmak üzere iki alan vardır. Bir kullanıcı oturum açmaya çalışırsa ve yanlış bir şifre girerse tekrar deneyebilir. Ne yazık ki, hatalı deneme sayısı sınırlı değildir, bu nedenle N başarısız denemeden sonra oturum açma sayfası kilitlenmeyecektir. Saldırgan bu fırsattan yararlanabilir ve bir doğru e-posta verildiğinde, bir kombinasyon sonunda başarılı olana kadar bir gökkuşağı tablosundan parolaları girmeye devam edebilir. Uygulamanızın yeterince güvenli olması ve parolaları bir veritabanına girmeden önce hash etmeniz koşuluyla, bu özel saldırı işe yaramaz. Ancak, izinsiz girişleri tespit etmek için bir mekanizmanız var mı?

Bu girişimin oturum açma sayfanızı kıramaması, başka birinin de açmayacağı anlamına gelmez. Oturum açma sayfası da muhtemelen sahip olduğunuz tek potansiyel arka kapı değildir. Başka bir şey için değilse, birisi bozuk erişim kontrolünü size karşı kullanmayı deneyebilir. Mükemmel hazırlanmış uygulamalar bile, mümkün olmasa bile birisinin onlara saldırmaya çalıştığını bilmelidir. Her zaman öyledir ama.

Kendinizi bu tür saldırılara karşı korumak için elinizden gelenin en iyisini yapmak için aşağıdaki adımları izleyin:

• Kodda atılan istisnalar veya erişim kontrolü, doğrulama ve veri işleme hataları olsun, uygulamada meydana gelen tüm arızaları ve uyarıları günlüğe kaydedin. Depolanan tüm bilgiler, geriye dönük inceleme ve analizin mümkün olabilmesi için yeterince uzun süre çoğaltılmalı ve kalıcı olmalıdır.
• Biçim ve kalıcılık katmanının belirlenmesi önemlidir. Rastgele metin formatına sahip büyük bir dosyaya sahip olmak kolaydır; daha sonra işleme değil. Verileri saklamayı ve okumayı kolaylaştıran bir depolama seçeneği ve kolay ve hızlı (de) serileştirmeye izin veren bir format seçin. JSON'un hızlı erişim sağlayan bir veritabanında saklanması kullanımı kolaylaştırır. Veritabanını düzenli olarak yedekleyerek küçük tutun.
• Önemli ve değerli verilerle uğraşıyorsanız, son durumu denetlemek için izlenebilecek bir eylem izi tutun. Verilerin kurcalanmasını önlemek için bir mekanizma uygulayın.
• Arka plan sistemlerinin günlükleri analiz etmesini ve bir şey olursa sizi uyarmasını sağlayın. Bir kullanıcı uygulamanın korumalı bir bölümüne tekrar tekrar erişmeye çalışırsa test etmek kadar basit olan kontroller yardımcı olur. Yine de sistemi sahte kontrollerle aşırı yüklemeyin. İzleme sistemleri ayrı servisler olarak çalıştırılmalı ve ana sistemin performansını etkilememelidir.

Sorunu çözerken, hata günlüklerini harici kullanıcılara sızdırmamaya özellikle dikkat edin. Bunu yapmamak, sizi hassas bilgilere maruz kalmaya karşı duyarlı hale getirir. Günlüğe kaydetme ve izleme, saldırganların işlerini daha verimli yapmasına değil, sorunları çözmenize yardımcı olmalıdır.

Sonraki adımlar

Web uygulamalarındaki olası tehditlerin ve güvenlik açıklarının farkında olmak önemlidir. Bunları uygulamalarınızda tanımlamaya başlamak ve bunları kaldırmak için yamaları uygulamak daha da önemlidir.

Uygulama güvenliğine dikkat, yazılım geliştirme projesinin tüm adımlarının önemli bir parçasıdır. Yazılım mimarları, geliştiriciler ve test uzmanları, yazılım test prosedürlerini iş akışlarına dahil etmelidir. Güvenlik riskini azaltmak için yazılım geliştirme sürecinin uygun adımlarında güvenlik kontrol listeleri ve otomatik testler kullanmak faydalıdır.

İster mevcut bir uygulamayı analiz ediyor ister yeni bir tane geliştiriyor olun, OWASP Uygulama Güvenliği Doğrulama Standart Projesi'ne (ASVS) bakmalısınız. Projenin amacı, uygulama güvenliği doğrulaması için bir standart geliştirmektir. Standart, güvenli web uygulamaları geliştirmeye yönelik testleri ve gereksinimleri sıralar. Testlere birden üçe kadar seviyeler atanır, burada biri en az miktarda tehlike ve üçü en yüksek potansiyel tehdit anlamına gelir. Sınıflandırma, uygulama yöneticilerinin hangi tehditlerin daha olası ve önemli olduğuna karar vermelerine olanak tanır. Her bir testi her uygulamaya dahil etmek gerekli değildir.

Hem yeni hem de mevcut web uygulama projeleri, özellikle Agile ilkelerini takip edenler, uygulamalarını güvence altına almak için yapılandırılmış çaba planlamasından yararlanır. OWASP Security Knowledge Framework'ü kullanmaya karar verirseniz, OWASP ASVS testlerinin planlanması daha kolaydır. Yaygın güvenlik sorunlarının nasıl çözüleceğine dair bir dizi örnek ve OWASP ASVS'ye dayalı takip edilmesi kolay kontrol listeleri ile birlikte gelen, güvenlik testi odaklı sprintleri yönetmek için bir uygulamadır.

Web uygulaması güvenliğini keşfetmeye yeni başladıysanız ve güvenli bir sanal alan oyun alanına ihtiyacınız varsa, OWASP'ın bir web uygulaması uygulamasını kullanın—WebGoat. Bir web uygulamasının kasıtlı olarak güvenli olmayan bir uygulamasıdır. Uygulama, her bir dersin tek bir güvenlik tehdidine odaklandığı dersler boyunca size rehberlik eder.

Uygulama geliştirme sırasında şunları yaptığınızdan emin olun:

• Tehditleri belirleyin ve önceliklendirin. Hangi tehditlerin gerçekçi bir şekilde gerçekleşebileceğini ve uygulamanız için risk oluşturabileceğini tanımlayın. Tehditlere öncelik verin ve hangilerinin en fazla geliştirme ve test etme çabasını hak ettiğine karar verin. Statik bir blog sunuyorsanız, yetersiz günlük kaydı ve izleme sorununu çözmek için çok çaba sarf etmenin pek bir anlamı yoktur.
• Uygulamanızın mimarisini ve tasarımını değerlendirin. Bazı güvenlik açıklarının, uygulama geliştirmenin sonraki aşamalarında çözülmesi çok zordur. Örneğin, üçüncü taraf kodunu yürütmeyi planlıyorsanız ve bir korumalı alan ortamı kullanma planınız yoksa, güvenli olmayan seri durumdan çıkarma ve enjeksiyon saldırılarına karşı savunmak çok zor olacaktır.
• Yazılım geliştirme sürecini güncelleyin. Web uygulaması tehditlerine karşı test, mümkün olduğunca otomatikleştirilmiş bir süreç olmalıdır. Güvenlik açıklarını bulmaya çalışan otomatik testlerle CI/CD iş akışlarınızı güçlendirmenizde fayda var. Güvenlik testleri geliştirmek ve bunları periyodik olarak çalıştırmak için mevcut birim test sisteminizi bile kullanabilirsiniz.
• Öğrenin ve geliştirin. Sorunların ve güvenlik açıklarının listesi statik değildir ve kesinlikle on veya on beş tehditle sınırlı değildir. Yeni işlevler ve fikirler, yeni saldırı türlerinin kapılarını açar. Güncel kalmak için web uygulaması güvenliği dünyasındaki güncel eğilimleri okumak önemlidir. Öğrendiklerini uygula; aksi takdirde zamanınızı boşa harcarsınız.

Çözüm

Adından da anlaşılacağı gibi, OWASP İlk On Projesi yalnızca on güvenlik açığını listelese de, uygulamalarınızı ve en önemlisi kullanıcılarınızı ve verilerini tehdit eden binlerce olası tuzak ve arka kapı vardır. Tetikte olduğunuzdan ve bilginizi sürekli yenilediğinizden emin olun çünkü teknolojilerdeki değişiklikler ve gelişmelerin hem olumlu hem de olumsuz yanları vardır.

Oh, ve unutma, dünya siyah beyaz değil. Güvenlik açıkları tek başına gelmez; çoğu zaman iç içedirler. Birine maruz kalmak, çoğu zaman diğerlerinin köşelerde olduğu, çirkin kafalarını dikmek için bekledikleri ve bazen, sistem güvenliği geliştiricisi olarak sizin suçunuz olmasa bile, hala boşlukları yamamanız gerektiği anlamına gelir. siber Suç. Bir örnek için, Hacked Kredi Kartı Numaraları Hâlâ Google'a Uygundur başlıklı makaleye bakın.