En Yaygın 10 Web Güvenlik Zafiyeti

Pek çok şirket için, bir güvenlik ihlali meydana gelene kadar web güvenliği en iyi uygulamaları bir öncelik haline gelmez. BT Güvenliği uzmanı olarak çalıştığım yıllar boyunca, web geliştirme güvenlik sorunları dünyasının birçok programcı arkadaşım için ne kadar belirsiz olabileceğini tekrar tekrar gördüm.

Web güvenliği tehditlerine etkili bir yaklaşım, tanımı gereği proaktif ve savunmacı olmalıdır. Bu amaçla, bu yazı, okuyucuya sağlıklı bir dozda paranoya enjekte etmeyi umarak bir güvenlik zihniyetini ateşlemeyi amaçlıyor.

Bu kılavuz özellikle, bunların nasıl azaltılabileceğine ilişkin öneriler de dahil olmak üzere, dikkat edilmesi gereken 10 yaygın ve önemli web güvenlik tuzağına odaklanmaktadır. Odak noktası, amacı dünya çapında yazılım güvenliğini iyileştirmek olan uluslararası, kar amacı gütmeyen bir kuruluş olan Open Web Application Security Project (OWASP) tarafından belirlenen İlk 10 Web Güvenlik Açığı'dır.

Başlamadan önce küçük bir siber güvenlik astarı – kimlik doğrulama ve yetkilendirme

Diğer programcılar ve BT uzmanlarıyla konuşurken, yetkilendirme ve kimlik doğrulama arasındaki ayrım konusunda sık sık kafa karışıklığıyla karşılaşıyorum. Ve elbette, auth kısaltmasının sıklıkla her ikisi için de kullanılması, bu yaygın kafa karışıklığını şiddetlendirmeye yardımcı olur. Bu karışıklık o kadar yaygındır ki, belki de bu konu bu yazıda “Common Web Vulnerability Zero” olarak dahil edilmelidir.

Devam etmeden önce, bu iki terim arasındaki farkı netleştirelim:

• Kimlik Doğrulama: Bir kişinin güvenlik kimlik bilgilerini (parola, güvenlik sorularının yanıtları, parmak izi taraması vb.) doğru bir şekilde sağladığı için belirli bir kullanıcı olduğunun (veya en azından öyle göründüğünün) doğrulanması.
• Yetkilendirme: Belirli bir kullanıcının belirli bir kaynağa erişimi olduğunu veya belirli bir eylemi gerçekleştirme izninin verildiğini onaylama.

Başka bir deyişle, kimlik doğrulama , bir varlığın kim olduğunu bilmek, yetkilendirme ise belirli bir varlığın neler yapabileceğini bilmektir. Bunu akılda tutarak, en önemli 10 internet güvenlik sorununa geçelim.

Yaygın Web Güvenliği Hatası #1: Enjeksiyon kusurları

Enjeksiyon kusurları, güvenilmeyen girdileri filtrelemedeki klasik bir başarısızlıktan kaynaklanır. Filtrelenmemiş verileri SQL sunucusuna (SQL enjeksiyonu), tarayıcıya (XSS – bundan daha sonra bahsedeceğiz), LDAP sunucusuna (LDAP enjeksiyonu) veya başka bir yere ilettiğinizde olabilir. Buradaki sorun, saldırganın bu varlıklara komutlar enjekte edebilmesi ve bunun sonucunda veri kaybına ve istemcilerin tarayıcılarının ele geçirilmesine neden olmasıdır.

Uygulamanızın güvenilmeyen kaynaklardan aldığı her şey, tercihen beyaz listeye göre filtrelenmelidir . Neredeyse hiçbir zaman kara liste kullanmamalısınız, çünkü bunu doğru yapmak çok zor ve genellikle atlaması kolaydır. Virüsten koruma yazılım ürünleri tipik olarak başarısız kara listelerin mükemmel örneklerini sağlar. Desen eşleştirme çalışmıyor.

Önleme: İyi haber şu ki, enjeksiyona karşı koruma "basitçe" girdinizi uygun şekilde filtrelemek ve bir girdiye güvenilip güvenilmeyeceğini düşünmek meselesidir. Ancak kötü haber şu ki, şüphesiz güvenilir olmadıkça tüm girdilerin uygun şekilde filtrelenmesi gerekiyor (ancak burada “asla asla deme” sözü akla geliyor).

Örneğin 1000 girişi olan bir sistemde, bunlardan 999 tanesini başarılı bir şekilde filtrelemek yeterli değildir, çünkü bu hala sisteminizi çökertmek için Aşil iyileştirmesi olarak hizmet edebilecek bir alan bırakır. Veritabanına güvenilir olduğu için bir SQL sorgusu sonucunu başka bir sorguya koymanın iyi bir fikir olduğunu düşünebilirsiniz, ancak çevre güvenilir değilse, girdi dolaylı olarak kötü niyetli adamlardan gelir. İlgileniyorsanız buna İkinci Derece SQL Enjeksiyonu denir.

Filtrelemeyi doğru yapmak (kripto gibi) oldukça zor olduğu için, genellikle tavsiye ettiğim şey, çerçevenizin filtreleme işlevlerine güvenmek: çalıştıkları kanıtlanmıştır ve iyice incelenir. Çerçeveleri kullanmıyorsanız, bunları kullanmamanın sunucu güvenliği bağlamında gerçekten anlamlı olup olmadığı konusunda gerçekten çok düşünmeniz gerekir. Zamanın %99'unda olmaz.

Yaygın Web Güvenliği Hatası #2: Bozuk Kimlik Doğrulama

Bu, bozuk kimlik doğrulama sırasında ortaya çıkabilecek birden çok sorunun bir toplamıdır, ancak hepsi aynı kök nedenden kaynaklanmaz.

2014'te herhangi birinin hala kendi kimlik doğrulama kodunu almak istediğini varsayarsak (ne düşünüyorsun?), Buna karşı tavsiyede bulunuyorum. Doğruyu bulmak son derece zordur ve birkaç olası tuzaktan söz etmek gerekirse, sayısız olası tuzak vardır:

1. URL, oturum kimliğini içerebilir ve yönlendiren başlığında başka birine sızdırabilir.
2. Parolalar, depolama veya aktarım sırasında şifrelenmemiş olabilir.
3. Oturum kimlikleri tahmin edilebilir olabilir, bu nedenle erişim elde etmek önemsizdir.
4. Oturum sabitleme mümkün olabilir.
5. Oturum ele geçirme mümkün olabilir, zaman aşımları doğru uygulanmamış veya HTTP (SSL güvenliği yok) vb.

Önleme: Bu web güvenlik açığından kaçınmanın en basit yolu bir çerçeve kullanmaktır. Bunu doğru bir şekilde uygulayabilirsiniz, ancak ilki çok daha kolaydır. Kendi kodunuzu yuvarlamak istiyorsanız, son derece paranoyak olun ve tuzakların ne olduğu konusunda kendinizi eğitin. Birkaç tane var.

Yaygın Web Güvenliği Hatası #3: Siteler Arası Komut Dosyası Çalıştırma (XSS)

Bu oldukça yaygın bir girdi temizleme hatasıdır (aslında özel bir yaygın hata #1 durumu). Bir saldırgan, girişte web uygulamanıza JavaScript etiketleri verir. Bu girdi kullanıcıya temizlenmemiş olarak döndürüldüğünde, kullanıcının tarayıcısı bunu yürütür. Bir bağlantı oluşturmak ve bir kullanıcıyı tıklamaya ikna etmek kadar basit olabilir veya çok daha uğursuz bir şey olabilir. Sayfa yüklemesinde komut dosyası çalışır ve örneğin, çerezlerinizi saldırgana göndermek için kullanılabilir.

Önleme: Basit bir web güvenlik çözümü var: HTML etiketlerini istemciye iade etmeyin. Bu, saldırganın düz HTML içeriği (görüntüler veya yüksek sesle görünmez flash oynatıcılar gibi) enjekte ettiği benzer bir saldırı olan HTML enjeksiyonuna karşı koruma sağlamanın ek avantajına sahiptir - yüksek etkili değil ama kesinlikle sinir bozucu ("lütfen durdurun!"). Genellikle, geçici çözüm tüm HTML varlıklarını dönüştürmektir, böylece <script> &lt;script&gt; . Diğer sık ​​kullanılan temizleme yöntemi, < ve > üzerinde normal ifadeler kullanarak HTML etiketlerini çıkarmak için normal ifadeler kullanmaktır, ancak birçok tarayıcı ciddi şekilde bozuk HTML'yi gayet iyi yorumlayacağından bu tehlikelidir. Tüm karakterleri kaçan meslektaşlarına dönüştürmek daha iyidir.

Yaygın Web Güvenliği Hatası #4: Güvensiz Doğrudan Nesne Referansları

Bu, kullanıcı girdisine güvenmenin ve bunun sonucunda ortaya çıkan bir güvenlik açığında bedelini ödemenin klasik bir örneğidir. Doğrudan nesne başvurusu, bir dosya veya veritabanı anahtarı gibi bir dahili nesnenin kullanıcıya gösterilmesi anlamına gelir. Bununla ilgili sorun, saldırganın bu referansı sağlayabilmesi ve yetkilendirme uygulanmazsa (veya bozulursa), saldırganın engellenmesi gereken şeylere erişebilmesi veya bunları yapabilmesidir.

Örneğin, kodun, dosya adını belirtmek için bir CGI parametresi kullanarak (örneğin, download.php?file=something.txt ) dosyaları okuyan ve indirmesine izin veren bir download.php modülü vardır. Geliştirici, yanlışlıkla veya tembellik nedeniyle, koddan yetkilendirmeyi çıkardı. Saldırgan artık bunu, uygulama kodunun kendisi veya yedeklemeler gibi sunucuda kalan diğer veriler gibi PHP çalıştıran kullanıcının erişimi olan herhangi bir sistem dosyasını indirmek için kullanabilir. Ah-oh.

Başka bir yaygın güvenlik açığı örneği, kimin parolasını sıfırladığımızı belirlemek için kullanıcı girdisine dayanan bir parola sıfırlama işlevidir. Geçerli URL'yi tıkladıktan sonra, saldırgan URL'deki username alanını "yönetici" gibi bir şey söyleyecek şekilde değiştirebilir.

Bu arada, bu örneklerin ikisi de benim sıklıkla "vahşi doğada" ortaya çıktığını gördüğüm şeyler.

Önleme: Kullanıcı yetkilendirmesini düzgün ve tutarlı bir şekilde gerçekleştirin ve seçenekleri beyaz listeye alın. Çoğu zaman, verileri dahili olarak depolayarak ve istemciden CGI parametreleri aracılığıyla iletilmesine güvenmeyerek tüm sorundan kaçınılabilir. Çoğu çerçevedeki oturum değişkenleri bu amaç için çok uygundur.

Yaygın Web Güvenliği Hatası #5: Güvenlik yanlış yapılandırması

Tecrübelerime göre, yanlış yapılandırılmış web sunucuları ve uygulamalar, düzgün yapılandırılmış olanlardan çok daha yaygın. Belki de bu, işleri batırmanın bir yolu olmadığı içindir. Bazı örnekler:

1. Uygulamayı, üretimde hata ayıklama etkinleştirilmiş olarak çalıştırma.
2. Değerli bilgileri sızdıran sunucuda dizin listesinin etkinleştirilmesi.
3. Eski yazılımları çalıştırma (WordPress eklentilerini, eski PhpMyAdmin'i düşünün).
4. Makinede gereksiz servislerin çalıştırılması.
5. Varsayılan anahtarları ve şifreleri değiştirmemek. (İnandığınızdan çok daha sık olur!)
6. Yığın izleri gibi hata işleme bilgilerini saldırganlara açıklamak.

Önleme: Dağıtımda testler çalıştırabilen iyi (tercihen otomatikleştirilmiş) bir "oluşturma ve dağıtma" sürecine sahip olun. Zavallı adamın güvenlik yanlış yapılandırması çözümü, kodun varsayılan parolalarla ve/veya yerleşik geliştirme öğeleriyle dışarı çıkmasını önlemek için işlem sonrası kancalardır.

Yaygın Web Güvenliği Hatası #6: Hassas verilere maruz kalma

Bu web güvenlik açığı, kripto ve kaynak koruması ile ilgilidir. Hassas veriler, aktarım sırasında ve bekleme sırasında da dahil olmak üzere her zaman şifrelenmelidir. İstisna yok. Kredi kartı bilgileri ve kullanıcı şifreleri asla seyahat etmemeli veya şifrelenmeden saklanmamalı ve şifreler her zaman hash işlemine tabi tutulmalıdır. Açıkça kripto/karma algoritması zayıf olmamalıdır - şüpheye düştüğünüzde, web güvenlik standartları AES (256 bit ve üstü) ve RSA (2048 bit ve üstü) önerir.

Oturum kimliklerinin ve hassas verilerin URL'lerde dolaşmaması ve hassas çerezlerin güvenli bayrağının açık olması gerektiğini söylemeye gerek yok, ancak bu çok önemlidir ve fazla vurgulanamaz.

Önleme:

• Aktarım sırasında : HTTPS'yi uygun bir sertifika ve PFS (Mükemmel İletim Gizliliği) ile kullanın. HTTPS olmayan bağlantılar üzerinden hiçbir şeyi kabul etmeyin. Çerezlerde güvenli bayrağı bulundurun.

• Depolamada: Bu daha zordur. Her şeyden önce, maruz kalma durumunuzu azaltmanız gerekir. Hassas verilere ihtiyacınız yoksa, parçalayın. Sahip olmadığınız veriler çalınamaz. PCI uyumlu olmakla uğraşmak istemeyeceğiniz için kredi kartı bilgilerini asla saklamayın. Stripe veya Braintree gibi bir ödeme işlemcisine kaydolun. İkinci olarak, gerçekten ihtiyacınız olan hassas verileriniz varsa, bunları şifreli olarak saklayın ve tüm parolaların karma olduğundan emin olun. Hashing için bcrypt kullanılması önerilir. Bcrypt kullanmıyorsanız, kendinizi tuzlama ve gökkuşağı masaları konusunda eğitin.

Ve bariz olanı belirtme riskine rağmen, şifreleme anahtarlarını korunan verilerin yanında saklamayın . Bu, içinde anahtarı olan bir kilitle bisikletinizi saklamaya benzer. Yedeklerinizi şifreleme ile koruyun ve anahtarlarınızı çok gizli tutun. Ve elbette, anahtarları kaybetmeyin!

Yaygın Web Güvenliği Hatası #7: Eksik işlev düzeyi erişim denetimi

Bu sadece bir yetkilendirme hatasıdır. Bu, sunucuda bir işlev çağrıldığında, uygun yetkilendirmenin yapılmadığı anlamına gelir. Geliştiriciler çoğu zaman, kullanıcı arayüzünü sunucu tarafının oluşturduğu gerçeğine güvenir ve sunucu tarafından sağlanmayan işlevselliğe istemci tarafından erişilemeyeceğini düşünürler. Bu kadar basit değil, çünkü bir saldırgan her zaman "gizli" işlevselliğe yönelik isteklerde bulunabilir ve kullanıcı arayüzünün bu işlevi kolayca erişilebilir hale getirmemesi gerçeğinden caydırılmaz. Bir /admin paneli olduğunu ve düğmenin yalnızca kullanıcı gerçekten bir yönetici ise kullanıcı arayüzünde bulunduğunu hayal edin. Hiçbir şey bir saldırganın bu işlevi keşfetmesini ve yetkilendirme eksikse onu kötüye kullanmasını engelleyemez.

Önleme: Sunucu tarafında her zaman yetkilendirme yapılmalıdır. Evet herzaman. Hiçbir istisna veya güvenlik açığı ciddi sorunlara neden olmaz.

Yaygın Web Güvenliği Hatası #8: Siteler Arası İstek Sahteciliği (CSRF)

Bu, tarayıcının başka bir tarafça yetkisini kötüye kullanması için kandırıldığı, kafası karışmış bir vekil saldırısına güzel bir örnektir. Örneğin bir 3. taraf sitesi, kullanıcının tarayıcısının saldırgan için bir şeyler yapma yetkisini kötüye kullanmasına neden olabilir.

CSRF durumunda, bir 3. taraf site, çerezleriniz / oturumunuzla tarayıcınızı kullanarak hedef siteye (örneğin bankanız) istek gönderir. Örneğin, bankanızın ana sayfasındaki bir sekmede oturum açtıysanız ve banka bu saldırıya karşı savunmasızsa, başka bir sekme tarayıcınızın kimlik bilgilerini saldırganın adına kötüye kullanmasına neden olarak karışık vekil sorununa neden olabilir. Yardımcı, saldırganın yapmasını istediği bir şeyi yapmak için yetkisini (oturum çerezleri) kötüye kullanan tarayıcıdır.

Bu örneği düşünün:

Saldırgan Alice, parasının bir kısmını ona aktararak hedef Todd'un cüzdanını hafifletmek istiyor. Todd'un bankası CSRF'ye karşı savunmasız. Para göndermek için Todd'un aşağıdaki URL'ye erişmesi gerekir:

http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243

Bu URL açıldıktan sonra Todd'a bir başarı sayfası sunulur ve aktarım yapılır. Alice ayrıca Todd'un kendi kontrolü altındaki blog.aliceisawesome.com'daki bir siteyi sık sık ziyaret ettiğini ve burada aşağıdaki pasajı yerleştirdiğini biliyor:

<img src=http://example.com/app/transferFunds?amount=1500&destinationAccount=4673243243 width=0 height=0 />

Alice'in web sitesini ziyaret ettikten sonra, Todd'un tarayıcısı, Alice'in bir görüntüye bağlandığını düşünür ve resmi almak için otomatik olarak bir HTTP GET isteği gönderir, ancak bu aslında Todd'un bankasına Alice'e 1500$ transfer etmesi talimatını verir.

Bu arada, bu örnek, CSRF güvenlik açığını göstermenin yanı sıra, sunucu durumunun, kendisi ciddi bir güvenlik açığı olan belirsiz bir HTTP GET isteğiyle değiştirilmesini de gösterir. HTTP GET istekleri bağımsız (güvenli) olmalıdır , yani erişilen kaynağı değiştiremezler. Sunucu durumunu değiştirmek için hiçbir zaman, hiçbir zaman bağımsız yöntemler kullanmayın.

Eğlenceli gerçek: CSRF, aynı zamanda, üyeler daha akıllı hale gelene kadar geçmişte çerez doldurmak için kullanılan yöntemdir.

Önleme: Gizli bir belirteci, 3. taraf sitesinden erişilemeyen gizli bir form alanında saklayın. Elbette her zaman bu gizli alanı doğrulamanız gerekir. Bazı siteler, hassas ayarları değiştirirken (örneğin, şifre hatırlatıcı e-postanız gibi) şifrenizi de ister, ancak bunun, terk edilen oturumlarınızın kötüye kullanılmasını önlemek için orada olduğundan şüpheleniyorum (örneğin bir internet kafede).

Yaygın Web Güvenliği Hatası #9: Bilinen güvenlik açıklarına sahip bileşenleri kullanma

Başlık her şeyi söylüyor. Bunu daha çok bakım/dağıtım sorunu olarak sınıflandırırdım. Yeni kodu dahil etmeden önce biraz araştırma yapın, muhtemelen biraz denetim yapın. GitHub'da veya herhangi bir forumda rastgele bir kişiden aldığınız kodu kullanmak çok uygun olabilir, ancak ciddi web güvenlik açığı riski de yoktur.

Örneğin, sitelerin sahiplenildiği (yani, dışarıdan birinin bir sisteme idari erişim kazandığı), programcıların aptallığından değil, üçüncü taraf bir yazılımın üretimde yıllarca yamasız kalması nedeniyle birçok örnek gördüm. Bu, örneğin WordPress eklentilerinde her zaman oluyor. Gizli phpmyadmin kurulumunuzu bulamayacaklarını düşünüyorsanız, sizi dirbuster ile tanıştırayım.

Buradaki ders, uygulama dağıtıldığında yazılım geliştirmenin bitmediğidir. Özellikle üçüncü taraf veya açık kaynak bileşenleri içeriyorsa, bakımın ve güncel tutulmasının nasıl yapılacağına ilişkin belgeler, testler ve planlar olmalıdır.

Önleme:

• Dikkatli olun. Bu tür bileşenleri kullanırken açıkça dikkatli olmanın ötesinde, kopyala-yapıştır kodlayıcı olmayın. Yazılımınıza koymak üzere olduğunuz kod parçasını dikkatli bir şekilde inceleyin, çünkü kod onarılamayacak şekilde bozulabilir (veya bazı durumlarda kasıtlı olarak kötü niyetli - web güvenlik saldırıları bazen bu şekilde farkında olmadan davet edilir).

• Güncel kal. Güvendiğiniz her şeyin en son sürümlerini kullandığınızdan ve bunları düzenli olarak güncelleme planınız olduğundan emin olun. En azından ürünle ilgili yeni güvenlik açıkları haber bültenine abone olun.

Yaygın Web Güvenliği Hatası #10: Doğrulanmamış yönlendirmeler ve yönlendirmeler

Bu bir kez daha bir giriş filtreleme sorunudur. Hedef sitenin bir URL'yi GET parametresi olarak alan bir redirect.php modülüne sahip olduğunu varsayalım. Parametreyi değiştirmek, malwareinstall.com targetsite.com bir URL oluşturabilir. Kullanıcı bağlantıyı gördüğünde, kullanıcının güvenilir olduğunu ve tıklamanın güvenli olduğunu düşündüğü targetsite.com/blahblahblah görür. Bunun aslında onları bir kötü amaçlı yazılım düşürme (veya başka bir kötü amaçlı) sayfaya aktaracağını çok az biliyorlar. Alternatif olarak, saldırgan tarayıcıyı targetsite.com/deleteprofile?confirm=1 adresine yönlendirebilir.

Bir HTTP başlığına sterilize edilmemiş kullanıcı tanımlı girdiyi doldurmanın oldukça kötü olan başlık enjeksiyonuna yol açabileceğini belirtmekte fayda var.

Önleme: Seçenekler şunları içerir:

• Yönlendirmeleri hiç yapmayın (nadiren gereklidirler).
• Yönlendirilecek geçerli konumların statik bir listesine sahip olun.
• Kullanıcı tanımlı parametreyi beyaz listeye alın, ancak bu zor olabilir.

sonsöz

Umarım bu yazıyla beyninizi biraz gıdıklamayı ve sağlıklı bir dozda paranoya ve web sitesi güvenlik açığı farkındalığını tanıtmayı başardım.

Buradaki temel çıkarım, asırlık yazılım uygulamalarının bir nedenden dolayı var olduğu ve arabellek taşmaları için gün içinde uygulananların, bugün Python'da salamura dizeleri için hala geçerli olmasıdır. Güvenlik protokolleri, tüm programcıların arzu etmesi gereken (daha fazla) doğru programları yazmanıza yardımcı olur.

Lütfen bu bilgiyi sorumlu bir şekilde kullanın ve sayfaları izinsiz test etmeyin!

Daha fazla bilgi ve daha spesifik sunucu tarafı saldırıları için şu adrese bakın: https://www.owasp.org/index.php/Category:Attack.

Bu gönderiyle ilgili geri bildirim ve hafifletme tavsiyesi memnuniyetle karşılanır ve takdir edilir. Gelecekte, özellikle dağıtılmış hizmet reddi (DDoS) ve eski usul (web değil) BT güvenlik açıkları konusunda ilgili gönderiler planlanmaktadır. Ne tür bir web koruması hakkında yazacağınız konusunda özel bir talebiniz varsa, lütfen doğrudan [email protected] adresinden benimle iletişime geçmekten çekinmeyin.

İşte web sitesi güvenliği! Şerefe.