Web Yöneticileri için Web Sitesi Güvenliği

12 Mayıs 2011, Perşembe

Kullanıcılara, gelişmiş antivirüs yazılımları yükleyerek kendilerini kötü amaçlı programlardan korumaları öğretilir; ancak kullanıcılar genellikle özel bilgilerini sizin gibi web sitelerine de emanet edebilirler, bu durumda verilerini korumak büyük önem taşır. Kendi verilerinizi korumak da oldukça önemlidir; eğer bir çevrimiçi mağazanız varsa, soyulmak istemezsiniz.

Yıllar içinde şirketler ve web yöneticileri, web uygulaması güvenliğinin bir şaka olmadığını (çoğu zaman acı bir şekilde) öğrendiler; SQL injection saldırıları nedeniyle sızdırılan kullanıcı şifrelerine, XSS ile çalınan çerezlere ve ihmalkar girdi doğrulama nedeniyle hackerlar tarafından ele geçirilen web sitelerine şahit olduk.

Bugün, bir web uygulamasının nasıl istismar edilebileceğine dair bazı örnekler göstereceğiz, böylece bunlardan ders çıkarabilirsiniz; bunun için kendi iç güvenlik eğitimlerimizde de kullandığımız, kasıtlı olarak savunmasız bırakılmış bir uygulama olan Gruyere‘yi kullanacağız. İzin almadan başkalarının web sitelerinde güvenlik açığı aramayın, çünkü bu hackleme olarak algılanabilir; ancak Gruyere üzerinde testler yapmanızdan memnuniyet duyarız, hatta sizi buna teşvik ederiz.

İstemci durumu manipülasyonu – URL’yi değiştirirsem ne olur?

Diyelim ki bir resim barındırma siteniz var ve kullanıcıların yüklediği resimleri görüntülemek için bir PHP betiği kullanıyorsunuz:

Peki, URL’yi şu şekilde değiştirirsem ve userpasswords.txt gerçek bir dosyaysa uygulama ne yapacak?

userpasswords.txt dosyasının içeriğini alabilir miyim?

İstemci durumu manipülasyonuna bir başka örnek de form alanlarının doğrulanmadığı durumlardır. Örneğin, şu forma sahip olduğunuzu varsayalım:

Görünüşe göre gönderen kişinin kullanıcı adı gizli bir giriş alanında saklanıyor. Harika! Bu, o alanın değerini başka bir kullanıcı adıyla değiştirirsem, formu o kullanıcıymış gibi gönderebileceğim anlamına mı geliyor? Bu pekala gerçekleşebilir; kullanıcı girdisi görünüşe göre sunucuda doğrulanabilecek bir token gibi bir yöntemle kimlik doğrulamasına tabi tutulmuyor.

Bu formun alışveriş sepetinizin bir parçası olduğunu ve 1000 dolarlık bir ürünün fiyatını 1 dolar olarak değiştirip siparişi verdiğimi hayal edin.

Uygulamanızı bu tür saldırılara karşı korumak kolay değildir; uygulamanızı nasıl savunacağınıza dair birkaç ipucu öğrenmek için Gruyere‘nin üçüncü bölümüne bir göz atın.

Siteler arası betik çalıştırma (XSS) – Kullanıcı girdisine güvenilemez

Basit, zararsız bir URL:

Peki gerçekten zararsız mı? Eğer yüzde kodlamalı karakterlerin kodunu çözersem şunları elde ederim:

Gruyere, özel hata sayfalarına sahip birçok site gibi, yol bileşenini HTML sayfasına dahil edecek şekilde tasarlanmıştır. Bu durum, kullanıcı girdisini doğrudan web uygulamasının oluşturulan HTML sayfasına dahil ettiği için XSS gibi güvenlik hatalarına yol açabilir. “Sadece bir uyarı kutusu, ne olmuş yani?” diyebilirsiniz. Mesele şu ki, eğer bir uyarı kutusu enjekte edebiliyorsam, büyük ihtimalle başka bir şey de enjekte edebilirim ve belki de sitenize sizin adınıza giriş yapmak için kullanabileceğim çerezlerinizi çalabilirim.

Bir başka örnek de saklanan kullanıcı girdisinin temizlenmediği durumdur. Diyelim ki blogunuza bir yorum yazıyorum; yorum basit:

Eğer diğer kullanıcılar masum görünen bağlantıma tıklarsa, çerezlerini ele geçirmiş olurum:

Kendi web uygulamanızda XSS açıklarını nasıl bulacağınızı ve bunları nasıl düzelteceğinizi Gruyere‘nin ikinci bölümünde öğrenebilirsiniz; veya ileri düzey bir geliştiriciyseniz, Online Security blogumuzda hakkında yazdığımız şablon sistemlerindeki otomatik kaçış özelliklerine bir göz atın.

Siteler arası istek sahteciliği (XSRF) – evil.com’dan gelen isteklere güvenmeli miyim?

Hata, bozuk bir resim. Tehlikeli olamaz—sonuçta bozuk—bu da resmin URL’sinin 404 döndürdüğü veya sadece hatalı biçimlendirildiği anlamına gelir. Bu her durumda doğru mudur?

Hayır, değil! İçerik türüne bakılmaksızın herhangi bir URL’yi resim kaynağı olarak belirtebilirsiniz. Bu bir HTML sayfası, bir JavaScript dosyası veya başka bir potansiyel olarak kötü amaçlı kaynak olabilir. Bu durumda resim kaynağı basit bir sayfanın URL’siydi:

Bu sayfa yalnızca giriş yapmışsam ve bazı çerezlerim ayarlanmışsa çalışacaktır. Uygulamaya gerçekten giriş yapmış olduğum için, tarayıcı resim kaynağı URL’sine erişerek resmi getirmeye çalıştığında, ilk kod parçamı da sildi. Bu kulağa çok tehlikeli gelmiyor, ancak uygulamaya biraz aşinaysam, bir kullanıcının profilini silen veya yöneticilerin diğer kullanıcılar için izin vermesini sağlayan bir URL’yi de tetikleyebilirim.

Uygulamanızı XSRF’ye karşı korumak için durum değiştiren eylemlerin GET aracılığıyla çağrılmasına izin vermemelisiniz; POST yöntemi bu tür durum değiştiren istekler için icat edilmiştir. Sadece bu değişiklik bile yukarıdaki saldırıyı hafifletmiş olabilir, ancak genellikle bu yeterli değildir ve XSRF’yi önlemek için tüm durum değiştiren isteklere tahmin edilemez bir değer eklemeniz gerekir. XSRF hakkında daha fazla bilgi edinmek istiyorsanız lütfen Gruyere‘ye gidin.

Siteler arası betik dahil etme (XSSI) – Tüm betikleriniz bize aittir

Günümüzde birçok site, JSON verisi döndüren asenkron JavaScript istekleri aracılığıyla bir sayfanın içeriğini dinamik olarak güncelleyebilir. Bazen JSON hassas veriler içerebilir ve doğru önlemler alınmazsa, bir saldırganın bu hassas bilgileri çalması mümkün olabilir.

Şu senaryoyu hayal edelim: Standart bir HTML sayfası oluşturdum ve size bağlantıyı gönderdim; bana güvendiğiniz için gönderdiğim bağlantıyı ziyaret ediyorsunuz. Sayfa sadece birkaç satır içeriyor:

Gruyere’ye giriş yaptığınız ve özel bir kod parçacığınız olduğu için, sayfamda size kod parçacığınızın içeriği hakkında bilgi veren bir uyarı kutusu göreceksiniz. Her zaman olduğu gibi, bir uyarı kutusunu tetiklemeyi başardıysam, istediğim her şeyi yapabilirim; bu durumda basit bir kod parçacığıydı, ancak en büyük sırrınız da olabilirdi.

Uygulamanızı XSSI’ye karşı savunmak çok zor değildir, ancak yine de dikkatli bir düşünce gerektirir. XSRF bölümünde açıklandığı gibi token kullanabilir, betiğinizi yalnızca POST isteklerine yanıt verecek şekilde ayarlayabilir veya betiğin çalıştırılabilir olmadığından emin olmak için JSON yanıtını ‘n’ ile başlatabilirsiniz.

SQL Injection – Hala kullanıcı girdisinin güvenli olduğunu mu düşünüyorsunuz?

Uygulamanıza JohnDoe'; DROP TABLE members;-- gibi bir kullanıcı adıyla giriş yapmaya çalışırsam ne olur?

Bu özel örnek kullanıcı verilerini açığa çıkarmasa da, uygulamanızın üyeler hakkındaki bilgileri sakladığı SQL tablosunu tamamen silme potansiyeline sahip olduğu için büyük baş ağrılarına neden olabilir.

Genel olarak, uygulamanızı proaktif düşünme ve girdi doğrulama ile SQL injection’dan koruyabilirsiniz. İlk olarak, SQL kullanıcısının DROP TABLE members komutunu yürütme iznine sahip olması gerektiğinden emin misiniz? Sadece SELECT hakları vermek yeterli olmaz mıydı? SQL kullanıcısının izinlerini dikkatlice ayarlayarak acı verici deneyimlerden ve birçok sorundan kaçınabilirsiniz. Ayrıca hata raporlamayı, başarısız bir sorgu durumunda veritabanının ve tablolarının isimleri açığa çıkmayacak şekilde yapılandırmak isteyebilirsiniz.

İkinci olarak, XSS vakasında öğrendiğimiz gibi, kullanıcı girdisine asla güvenmeyin: size giriş formu gibi görünen şey, bir saldırgana potansiyel bir kapı gibi görünür. Veritabanında saklanacak girdileri her zaman temizleyin ve tırnak işaretlerini güvenli hale getirin; mümkün olduğunda çoğu veritabanı programlama arayüzünde bulunan hazırlanmış veya parametreli ifadeler olarak adlandırılan ifadeleri kullanın.

Web uygulamalarının nasıl istismar edilebileceğini bilmek, onları nasıl savunacağınızı anlamanın ilk adımıdır. Bu ışıkta, sizi Gruyere kursunu almaya, Google Code University‘den diğer web güvenliği kurslarını almaya ve otomatik bir web uygulaması güvenlik testi aracı arıyorsanız skipfish‘e göz atmaya teşvik ediyoruz. Daha fazla sorunuz varsa lütfen bunları Web Yöneticisi Yardım Forumumuzda paylaşın.

Yazan:
Gary Illyes, Web Yöneticisi Trendleri Analisti