10 Web Zafiyeti ve Savunma Yolları
Merhabalar. Bu yazıda OWASP Top 10 (en tehlikeli 10 web zafiyeti) zafiyetlerini inceleyeceğiz. Bu açıklar hakkında bilgi edineceğiz ve savunma yollarını öğreneceğiz.
Bu açıkları kullanmayı göstermeyeceğim, sadece ufak bir senaryo ile örneklendireceğim.
Bu açıkların tehlike seviyesine göre sıralaması şu şekildedir:
» Injection
» Broken Authentication
» Sensitive Data Exposure
» XML External Entities (XXE)
» Broken Access Control
» Security Misconfiguration
» Cross-Site Scripting XSS
» Insecure Deserialization
» Using Components with Known Vulnerabilities
» Insufficient Logging & Monitoring
NOT: Bu yazı sadece bilgilendirme amacıyla yazılmıştır. Zafiyet kullanımı gibi kötü bir amaca hizmet etmemektedir.
NOT 2: Zafiyetler PHP, JS, HTML ve XML dilleri üzerinden anlatılmıştır.
1. Injection
Injection zafiyetini, bir siteye dışarıdan müdahale ile kod enjekte etme diye açıklayabiliriz. Biz en bilinen türlerinden SQL injection, XSS, OS Command Injection zafiyetlerini inceleyeceğiz.
1.1 SQL İnjection
Web zafiyeti denilince akıllara neredeyse ilk olarak SQL injection gelmekte. Bunun nedeni sanırım yaygın olması ve doğrudan veri tabanındaki verileri çekebilmemize olanak sağlamasıdır.
Bu açık yazılımdaki veri tabanı sorgularından kaynaklanmaktadır.
ÖRN: Sayfa id'sini URL parametresinden çeken web yazılımcı, özel karakter filtresi koymayı unutmuştur. Parametre sonuna bir özel karakter eklediğimizde açık karşımıza direk çıkabilir.
Defans
» İlk önce filtre kullanalım. Alacağımız değeri GET, POST veya JavaScript yardımıyla (ÖRN: jQuery AJAX GET-POST Method) çekiyor olmamız farketmez. Bu değerdeki zafiyette kullanılan karakterleri (' / boşluk * vb.) filtrelemeliyiz. Bunun için regex kullanacağız. GitHub'dan hazır fonksiyon da alabilirsiniz.
Kodlar: 2 adet "-", ";", "'", "`", "=" ve "*" karakterlerinin yazılmasına izin vermez.
Kullanımı: Değeri fonksiyon içerisine yazınız. Özel karakter varsa false değerini döndürür.
Örneğin parametreye deneme' yazalım. Sonuç resimdeki gibi olacaktır.
» İkinci olarak PHP'de bağlantıyı PDO kullanarak kuracağız. PDO ile bağlantıyı da bu şekil yapalım:
» Üçüncü aşama ise sorguları PDO kullanarak yapacağız. Prepare ve Execute bizi SQL Injection saldırılarından korumak için bir yöntemdir.
Bu adımları takip ederseniz SQL Injection saldırılarına karşı savunma yaparsınız.
1.2 OS Command Injection
OS Command Injection zafiyeti, site üzerinden terminal komutlarını çalıştırma mantığına dayalıdır. Türkçe kaynaklara baktığımda fazla bir kaynak bulamadım. Gördüğüm kadarıyla da ping test siteleri üzerinden anlatım yapılmış. Geleneği bozmayayım ben de kendi linux sistemime kurduğum sunucuda bu zafiyete yer verdim. Anlatıma geçelim.
PHP'de shell_exec sayesinde terminal komutları çalıştırabiliyoruz.
Bunu test edelim.
Şimdi örnek bir senaryo ile açığı test edeceğiz. Bunun için bir form ekledim.
Sıra açığı test etmede. Düzgün çalışması için önce bir adres yazdım daha sonra linux komutunu devam ettirmek için && ls yazdım.
komut:
ls: Dizindeki dosya ve klasörleri listeler.
Görüldüğü gibi açığı kullandık. Şimdi cd .. yazıp bir önceki dizine geçiyoruz ardından ls yazarak dosya ve klasörleri listeliyoruz.
komut:
Bu açık sayesinde terminal komutlarını çalıştırabiliyoruz ancak bizim amacımız Defans olduğu için ayrıntıya girmeyeceğim. Açığın tehlike seviyesini az çok tahmin etmişsinizdir.
Defans
Çoğu saldırıda olduğu gibi bu saldırıda da savunmayı filtre ile yapacağız. Ben resimdeki gibi bir fonksiyon oluşturdum bu sayede terminal komutlarının çalışmasını engelledim. Ancak siz daha gelişmiş bir fonksiyon kullanmalısınız.
Bu filtrede blacklist yöntemini kullandım ancak önerim yine whitelist'dir.
Gördüğünüz gibi komut çalışmadı. Çünkü & işaretini sildik ve bu sayede geriye www.google.com ls kaldı. Bu komut da hata verdiği için ekrana bir yazı gelmedi.
Düzgün şekilde URL girdiğinizde ise komut çalışmaktadır.
2. Broken Authentication
Broken Authentication, kötü niyetli kişilerin bir oturumu taklit etmesi sonucunda oluşan bir açık türüdür. Oturum yönetimi kusurları da bu zafiyete sebep olmaktadır.
Oturum, bir web sitesinde giriş yaptığınızda başlar ve çıkış yaptıktan sonra biter. Bu sürece oturum yönetimi adı verilir.
2.1 Kırık Kimlik Doğrulama (Broken Authentication)
Genellikle kaba kuvvet saldırıları örnek gösterilmektedir. Brute-Force saldırılarına karşı tedbir alınmaması zafiyet oluşturmakta. Bu önlemlerden bazıları her IP için sınırlı deneme hakkı vermek, resimli doğrulama kullanmak, zayıf parolalar ile sisteme kayıt olmayı engellemektir.
2.2 Oturum Yönetimi Saldırıları (Session Management Attack)
2.2.1 URL Rewriting: Bu zafiyete parametre olarak gönderilen oturum bilgileri sebep olmaktadır. En basitinden siteye giriş yapıldığında kontrol için GET metodu ile gönderilen veriler (site.com/giris.php?kadi=admin&pass=admin123) apaçık ortada olduğundan bu verilerin ele geçirilmesi sonucu yetki sahibi olunduğu türdür.
2.2.2 Session Hijacking: Oturum çalma, oturum ele geçirme anlamlarına gelmektedir. Saldırgan geçerli oturum bilgilerini çalıp sunucuda yetki sahibi olmayı hedefler. Bu yöntemde saldırgan XSS Injection, Network Tracking, istemciye (bilgisayar ve web tarayıcısı) trojan atma gibi yolları tercih edebilir. Bunun haricinde oturum kimliğini (Session ID) ele geçirmek için Brute-Force gibi yöntemler de kullanılabilir.
Aktif/Pasif olarak saldırı iki tipi vardır. Aktif oturum üzerinden yetkilenmeye aktif saldırı, oturum ele geçirildikten sonra ağ trafiği izlenilerek verileri ele geçirmeye ise pasif saldırı denir.
2.2.3 Session Fixation: Bu açık türü saldırganın oturumu önceden planlamasından ötürü meydana gelir. Saldırgan, kullanıcıya belirlenmiş SESSID parametresi içeren bir URL gönderir. Kullanıcı bu URL üzerinden girişini yaparsa saldırgan sunucuya belirlediği SESSID'yi tanıtarak kullanıcının kimliği üzerinden işlemlerde bulunabilir.
Daha da açıklayıcı olması için bir senaryo kuralım:
- Saldırgana (aslında her ziyaretçiye) sunucu tarafından bir oturum kimliği (SESSID) tanımlanır. Saldırgan yetkili bir kullanıcıya bu kimliği içeren bir bağlantı yollar ve bu kimlikle giriş yapmasını sağlar.
- Giriş yapan yetkili bu oturum kimliğine sunucu tarafından bir yetki tanımlamış olur.
- Saldırgan bu kimlik ile kendini sunucuya tanıttığı zaman, hedef yetkilinin tüm yetkilerine sahip olur.
Sorun kullanıcı taraflı gözükse de sunucu tarafından bu durum engellenebilir. Örneğin ziyaretçi giriş yaptıktan sonra farklı bir kimlik verilebilir. Bu sayede önceki kimlik geçersiz olur ve saldırganın kimliği yetkilenemez. Ayrıca outlook gibi giriş yapan cihazı tanıma gibi özellikler de bu saldırıların önünü kesmekte.
Defans
» Brute-Force Saldırılarını Engelleme,
» Oturum Bilgilerini Parametre ile Almamak,
» Anomaly Dedection,
» Güçlü Parola Denetimi,
» SSL Kullanmak,
» Oturum İçin Süre Belirleme,
» Multi-Factor Authentication Koymak,
vb. yollar izlenebilir.
3. Sensitive Data Exposure
Sensitive Data Exposure, hassas verilere erişim anlamına geliyor. Özellikle bazı hassas verilere kolayca erişmek, bu açığın en büyük ekmeği sanırım. Örneğin Flat-File veri tabanlarının, erişimin mümkün olduğu dizinde saklanması da bu zafiyete kollarını açıyor. Ayrıca SQL Injection saldırılarında veri tabanı çekildiğinde karşımıza şifrelenmemiş dümdüz veriler geliyor. Bu bir hatadır çünkü bu verilerin şifrelenmesi gerekmektedir.
Defans
Verilerin, erişimin mümkün olmayacağı şekilde saklamak,
Verileri, veri tabanında şifrelenmiş biçimde saklamak. Şifrelemek önemlidir çünkü saldırgan veri tabanına bir şekilde sızmayı başarsa bile, şifrelediğimiz veriler onun hiçbir işine yaramayacaktır. Bu da veriler için koruma sağlayacaktır.
4. XML External Entities (XXE)
Bu zafiyeti anlamanız için öncelikle XML'i bilmeniz gerekiyor. XML, Genişletilebilir İşaretleme Dili olarak çevrilebilir. XML diğer özelliklerinin yanı sıra genel olarak veri saklama amacıyla kullanılmaktadır. JSON gibi düşünebiliriz. Özellikler pazaryeri siteleri ürünlerini aktarmada XML kullanırlar. Binlerce ürünü özellikleriyle birlikte farklı bir siteye eklemek akıl işi değildir zaten.
XML kullanmanın dezavtajları da görülmekte. Bu noktada XXE zafiyeti bir Injection türü diyebiliriz.
Bu zafiyetin çeşitleri de bulunmakta. Biz 4 türünü inceleyeceğiz.
4.1 Dosya Yükleme ile XXE Saldırısı
Dosya yükleme özelliğine sahip zafiyet bulunduran sunucularda, XLSX, DOCX, PPTX, SVG vb. zararlı yazılım içeren dosyaların yüklenmesiyle, etc/passwd gibi hassas bilgilere sahip verilerin ifşa edilmesine izin veren sunuculardaki zafiyettir. Upload edilecek dosya genellikle XML Medya türüne sahiptir.
4.2 Dosyalara Erişim Sağlayan XXE Saldırısı
Bu saldırıda etc/passwd gibi sunucudaki değerli bilgiler çalınabilir. Bu yazıdaki amacımız atak olmadığı için fazla ayrıntıya girmeyeceğim.
E-Ticaret üzerinden örneğe başladık. Örneğin bir stok takibi sayfasını incelerseniz, sayfanın XML ile oluşturulduğunu görebilirsiniz. Burp Suite yardımı ile XML enjekte ettiğinizde Entity kullanarak dosyalara erişim imkanı sağlarsınız.
Örneğin resimdeki gibi XML dosyasına Burp Suite kullanarak;
<!DOCTYPE deneme [<!ENTITY tht SYSTEM "file:///etc/passwd">]>
kodunu ekleyip çıktılardan birine &tht; komutunu eklerseniz dosya verisini &tht; yazdığınız yerde görüntüleyebilirsiniz.
4.3 SSRF Saldırısı
SSRF saldırısında dosyalara erişim sağlarken kullanılan yöntemin aynısını, fakat dizin adresi yerine IP adresi yazılır.
<!DOCTYPE deneme [<!ENTITY tht SYSTEM "192.168.1.1">]>
<deneme>&tht;</deneme>
Burada <deneme> </deneme> etiketi arasına bir Response (yanıt) gelecektir. Gelen yanıt x olsun.
<!DOCTYPE deneme [<!ENTITY tht SYSTEM "192.168.1.1/x">]>
<deneme>&tht;</deneme>
Bu sefer IP sonuna / koyup gelen yanıtı ekledik. Yine Request yani istek yollayıp yanıt bekliyoruz. Bu sefer gelen yanıt y olsun.
<!DOCTYPE deneme [<!ENTITY tht SYSTEM "192.168.1.1/x/y">]>
<deneme>&tht;</deneme>
Gördüğünüz gibi bu şekil ilerliyor. Devamında bilgilere ulaşana kadar bu işlem yapılır.
4.4 Xi:include
Bazı siteler, istemci taraflı gönderilen verileri alır, verileri sunucuda bir XML dosyasına yerleştirir daha sonra da ayrıştırır. Bu tip durumlarda klasik XXE saldırıları işe yaramayacaktır.
Bu durumlarda Xinclude yöntemi tercih edilir. Aşağıda örnek bir kullanım verilmiştir.
urunId=<denemeetiket xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include parse="text" href="file:///etc/passwd"/></denemeetiket>&magazaId=1
Defans
» XML External Entitiy özelliğini devre dışı bırakmak,
» XML'i güncel tutmak,
» Dış varlıkların çözümlenmesini devre dışı bırakmak,
» SOAP 1.2 ve üstü sürümünde çalışmak,
» Xinclude desteğini devre dışı bırakmak,
» Filtreleme (Whitelist önerilir) yapmak.
5. Broken Access Control
Broken Access Control, adından da anlaşılacağı üzere web uygulamasında erişim kontrolünün hatalı yapılmasından kaynaklanmaktadır. Örneğin bir parametre üzerinden veri alırken bunun kontrolünü tamamen kullanıcıya bırakırsanız, daha yetkili bir hesap üzerinden erişim sağlayacabilecektir.
Çok basitinden bir web uygulaması yaptım, onu test edelim.
Kullanıcı ve admin için 2 hesap mevcut. Bu hesaplara giriş yaptığımızda "oturum" isminde tanımladığımız SESSION "true" olarak değişiyor.
index.php
girisyap.php
Normal bir şekilde oturum açacağız. "user" isminde kullanıcı ile giriş yapıyorum.
Gördüğünüz üzere oturum açtık ve parametremiz index.php?kullanici_adi=user olarak değişti.
Yalnız burada bir sorun var. Oturum açıp açmadığımız kontrol ediliyor ancak parametredi kullanıcı adımızı değiştirip değiştirmediğimizi kontrol etmiyor. Bu parametreye admin yazsak ne olur? Deneyelim.
Gördüğünüz üzere oturumu user yetkisinde açtık fakat parametreyi değiştirdiğimiz için admin yetkisine sahip olduk.
Bu çok basit bir örnek zaten bu kadar basit bir açığı kimse bırakmayacaktır. BAC zafiyetini anlamanız için örnekledim.
Defans
» Her sayfada kimlik doğrulama yapmak,
» Hata kodlarını, veri tabanı veri özelliklerini açığa çıkarmayacak şekilde ayarlamak,
» Web sayfaların varsayılan adlarını değiştirmek,
» Rol tabanlı kimlik doğrulama kullanmak,
» Kullanıcının her işlemi için kimlik doğrulaması yapmak,
» Kullanıcıyı doğru şekilde tanımlamak.
6. Security Misconfiguration
Security Misconfiguration, varsayılan yapılandırma, kullanılmayan veya yanlış kullanılan eklentiler, güncel tutulmayan yazılımlardan kaynaklı zafiyettir.
Varsayılan yapılandırma zafiyet örneği: Wordpress kurdunuz ve bu kurulumdaki şifreyi varsayılan bıraktınız, değiştirmediniz. Bu durumda saldırganlar tarafından oluşturulmuş dork sayesinde taramalarda siteniz çıkarsa, sitenize kolayca Brute-Force saldırısıyla erişebilirler.
Eklenti dolaylı zafiyet örneği: Sisteminizde kurulu eklentileri kullanmıyorsunuz ve yapılandırmalarını yapmadınız. Eklenti taraflı bir zafiyet mevcut olduğunda bununla ilgilenmediğiniz için farketmeyeceksiniz ve sistemde güvenlik açıklarına yer vereceksiniz.
Güncellememe sebebiyle oluşan zafiyet örneği: Kullandığınız sistemin sürümü 1.0 olsun. Saldırganlar tarafından keşfedilen açık sayesinde kullandığınız sürümde zafiyet olduğu biliniyor. Sistem geliştiricilerinin yayınladığı 1.1 sürümü güvenlik açıklarının kapatıldığı sürüm fakat siz güncellemediğiniz için zafiyet hâlen mevcut. Saldırganlar tarafından kullanılması an meselesi.
Defans
» Varsayılan ayarları mutlaka değiştirin,
» Kullanmadığınız eklentileri kaldırın veya yapılandırın,
» Yayınlanan en son sürümü kullanın.
7. Cross-Site Scripting (XSS)
XSS zafiyeti, HTML, JS kodlarının çalıştırılabilmesinden kaynaklanan bir açıktır. Açılımı Cross-Site Scripting olan bu açığın 3 farklı çeşidi vardır. Bu zafiyet türünde doğrudan veri tabanı saldırısı olmaz.
» Reflected XSS
» DOM-Based XSS
» Stored XSS
7.1 Reflected XSS
Reflected XSS, kullanıcının sitede bir yere JavaScript kodlarını yazıp çalıştırabildiği açık türüdür. Örnek verecek olursak bir arama çubuğuna JavaScript komutunu yazdınız. Eğer yazılımcı bu kodları filtrelememişse sayfada JavaScript kodları çalışacaktır. Reflected XSS açığının kullanılmış olduğu link kurbana atılırsa, sosyal mühendislik yöntemleri ile bilgileri çalınabilir.
Örnek bir link:
ÖRN: Bir arama formu oluşturdum ve bu aramadan gelen değeri dökümana yazdırdım. Sonuçlara bakalım:
Gördüğünüz gibi zafiyet oluştu.
Defans
» Bu durumdan kurtulmanın kolay bir yolu var. En basitinden dökümana bastırmadan önce PHP kısmında strip_tags() filtresini kullanacağız. Bu fonksiyon HTML kodlarını filtreler. Filtrelediğimiz HTML kodlarında <script></script> silindiği için JavaScript komutları çalışmayacaktır.
7.2 DOM-Based XSS
DOM kaynaklı bir XSS zafiyet türüdür.
Örneğin;
koduna sahip bir site yakaladık. URL sonuna #<script>alert("Açık Var")</script> eklediğinizde, JavaScript dökümana bu veriyi bastığı için JavaScript kodumuz çalışacaktır.
Defans
JavaScript ile çalışırken dışarıdan alınan verileri filtrelemelisiniz. Filtrelemede 2 farklı yol kullanabilirsiniz.
» Blacklist
» Whitelist (Önerilen)
Blacklist, belirlediğiniz karakterlere göre çektiğiniz veriyi filtrelemektir.
Whitelist, çektiğiniz veride sadece belirlediğiniz karakterlerin olmasına izin verir. Bu yöntem daha güvenlidir.
7.3 Stored XSS
Stored XSS zafiyeti tehlikeli bir açıktır. Çünkü bu açık için bir URL parametresine ihtiyaç yoktur. Açığın kullanıldığı kod kaydedildiği için belki binlerce kişiye ulaşabilir.
Örneğin Facebook'ta filtreleme yok. Biz kayıt olurken kullanıcı adımıza <script>alert("Facebook Hacked")</script> koyduk. Bu veri tabanına başarılı bir şekilde kaydedildiğinde bizim kullanıcı adımızın geçtiği her sayfada JavaScript komutu çalışacaktır.
Ben kendi sitemde bir kayıt formu oluşturdum ve bu input'ları filtrelemeden direk veri tabanına kaydettim. Daha sonradan başka bir kullanıcı bu veriyi çektiğinde JavaScript kodları çalışacaktır.
Daha detaylı anlatmak için açıklı bir sosyal medya platformunda çevrimiçi kullanıcıları listelemek istiyorum.
Bu sırada zararlı kodları kullanıcı adı yapmış bir üye çevrimiçi oluyor. Sonuç:
Biz bu zararlı kod barındıran kullanıcı adını dökümana bastığımız için kodlar çalıştı.
Defans
» Reflected XSS'de yaptığımız gibi veri tabanına ekleme yaparken ve veri tabanından veri çekerken mutlaka strip_tags() filtresinden geçirmeliyiz.
Gördüğünüz gibi sitede kodlar çalışmadı. Sadece yazdırıldı.
8. Insecure Deserialization
Serialize, kompleks verilerin serileştirilmesine ve dolayısıyla kolayca saklanmasına/depolanmasına yarar. Deserialization ise bu serileştirme işleminin tam tersi, yani saklanen verilerin tekrar kompleks verilere çevrilmesi işlemidir.
Örneğin PHP'de vir Array'i veritabanında kaydetmek istiyorsunuz. İşte Serialize işlemi sayesinde verileri serileştirip kolayca saklayabilirsiniz.
Insecure Deserialization ise manipüle edilmiş (değiştirilmiş) objenin web uygulamasına Inject edildiği saldırı türütür. Bu saldırı sonucunda SQL Injection, RCE (Remote Code Execution - Uzaktan Kod Yürütme), Dizinleri görüntüleme gibi sorunlar meydana gelebilir.
Mesela internetten bulduğum örnek Serialize edilmiş PHP nesnesinin görüntüsü:
O:6:"Member":2:{s:8:"username";s:4:"Fred";s:16:"MemberloggedIn";b:1;}
Eğer saldırgan bu serileştirilmiş veriyi manipüle edebilir ve bunu direk PHP Unserialized işlevine gönderebilirse, Insecure Deserialization zafiyeti ortaya çıkar.
Defans (Birkaçı)
» JSON veya XML gibi veri tiplerini kullanmak,
» Herhangi bir serileştirilmiş veriye dijital imza uygulayın,
» Seriyi kaldıran kapsayıcılardan veya sunuculardan ağ bağlantısını kısıtlayın veya izleyin,
» Sürekli olarak serileştirilmiş verinin kaldırılmasına izin vermeyin.
9. Using Components with Known Vulnerabilities
Bu zafiyet uygulamada kullanılan Frameworks (uygulama çatıları), Library (Kütüphane), Modüller gibi bileşenlerden kaynaklanır. Bu bileşenler, uygulamada genellikle tam yetkiyle çalıştığı için bu bileşenlerin istismar edilmesi sonucu saldırganın uygulamaya zarar vermesi kolaylaşır.
Örneğin JavaScript'de kullandığınız jQuery kütüphanesinin bilindik bir zafiyeti varsa, siz istediğiniz kadar uygulamanızı güvenli yazarsanız yazın, saldırgan kütüphanedeki açıktan faydalanıp uygulamanızın güvenlik seviyesini düşürebilir.
Örnek bir vaka;
https://snyk.io/blog/malicious-code-found-in-npm-package-event-stream/
Defans
» Buradaki en doğru çözüm, güvenliğinden emin olmadığınız bileşenleri kullanmamak olacaktır.
10. Insufficient Logging & Monitoring
Insufficient Logging & Monitoring, adından da anlaşılacağı üzere yetersiz günlük kaydetme ve izleme sebeplerinden açığa çıkan güvenlik zafiyetleridir. Doğrudan bir güvenlik açığı olmasa da yapılan bu hata zafiyetlerin tespitini zorlaştırır, zafiyetlerin ilerlemesine sebep olur.
Senaryo: Küçük bir işletmede yetki sahibi kullanıcının hesabına Brute-Force saldırısı yapılıyor. Bu esnada Insufficient Logging & Monitoring dediğimiz olay gerçekleşiyor ve saldırganın Brute-Force saldırısı bolca vakti oluyor. Sonunda başarıyor ve verilere erişiyor. Oysaki günlük kaydı ve izleme sistemi düzgün çalışmış olsaydı bilişim departmanı saldırgana müdahale edebilecekti.
Defans
» Logging & Monitoring işlemlerinin düzenli olarak takip edilmesi ve test edilmesi bu sorunu ortadan kaldırmak için gerekli bir adımdır.
Bu yazıda OWASP Top Ten çalışmasında bildirilen tehlikeli zafiyet sıralamasında bulunan açıkları tanıyarak bu açıklara karşı korunma yollarını öğrendik. Unutmayın ki zafiyetler buradaki 10 açıkla sınırlı değildir. Önümüzdeki yıllarda bu sıralamaya girebileceği öngörülen zafiyetleri tanımanız gerekmektedir. Sistemdeki her kullanıcının bilgilerini alırken bir sorumluluk da almış olursunuz. Bu yüzden ben yazılımın sadece kod yazma yeteneği ile bittiğini düşünmüyorum.
Okuduğunuz için teşekkür ederim
Merhabalar. Bu yazıda OWASP Top 10 (en tehlikeli 10 web zafiyeti) zafiyetlerini inceleyeceğiz. Bu açıklar hakkında bilgi edineceğiz ve savunma yollarını öğreneceğiz.
Bu açıkları kullanmayı göstermeyeceğim, sadece ufak bir senaryo ile örneklendireceğim.
Bu açıkların tehlike seviyesine göre sıralaması şu şekildedir:
» Injection
» Broken Authentication
» Sensitive Data Exposure
» XML External Entities (XXE)
» Broken Access Control
» Security Misconfiguration
» Cross-Site Scripting XSS
» Insecure Deserialization
» Using Components with Known Vulnerabilities
» Insufficient Logging & Monitoring
NOT: Bu yazı sadece bilgilendirme amacıyla yazılmıştır. Zafiyet kullanımı gibi kötü bir amaca hizmet etmemektedir.
NOT 2: Zafiyetler PHP, JS, HTML ve XML dilleri üzerinden anlatılmıştır.
1. Injection
Injection zafiyetini, bir siteye dışarıdan müdahale ile kod enjekte etme diye açıklayabiliriz. Biz en bilinen türlerinden SQL injection, XSS, OS Command Injection zafiyetlerini inceleyeceğiz.
1.1 SQL İnjection
Web zafiyeti denilince akıllara neredeyse ilk olarak SQL injection gelmekte. Bunun nedeni sanırım yaygın olması ve doğrudan veri tabanındaki verileri çekebilmemize olanak sağlamasıdır.
Bu açık yazılımdaki veri tabanı sorgularından kaynaklanmaktadır.
ÖRN: Sayfa id'sini URL parametresinden çeken web yazılımcı, özel karakter filtresi koymayı unutmuştur. Parametre sonuna bir özel karakter eklediğimizde açık karşımıza direk çıkabilir.
Defans
» İlk önce filtre kullanalım. Alacağımız değeri GET, POST veya JavaScript yardımıyla (ÖRN: jQuery AJAX GET-POST Method) çekiyor olmamız farketmez. Bu değerdeki zafiyette kullanılan karakterleri (' / boşluk * vb.) filtrelemeliyiz. Bunun için regex kullanacağız. GitHub'dan hazır fonksiyon da alabilirsiniz.
Kodlar: 2 adet "-", ";", "'", "`", "=" ve "*" karakterlerinin yazılmasına izin vermez.
Kod:
function guvenlik_kontrol($deger){
if (preg_match("/[\-]{2,}|[;]|[%]|[`'=]|[\*]/", $deger)){
return false;
}else{
return true;
}
}Kullanımı: Değeri fonksiyon içerisine yazınız. Özel karakter varsa false değerini döndürür.
Kod:
if (guvenlik_kontrol($_GET["parametre"])) {
echo "Güvenli";
}else{
echo "Zararlı";
}Örneğin parametreye deneme' yazalım. Sonuç resimdeki gibi olacaktır.
» İkinci olarak PHP'de bağlantıyı PDO kullanarak kuracağız. PDO ile bağlantıyı da bu şekil yapalım:
Kod:
$db = new PDO('mysql:dbname=veritabani_ismi;host=localhost;charset=utf8', 'kullanici_adi', 'sifre');
$db->setAttribute(PDO::ATTR_EMULATE_PREPARES, false);
$db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);» Üçüncü aşama ise sorguları PDO kullanarak yapacağız. Prepare ve Execute bizi SQL Injection saldırılarından korumak için bir yöntemdir.
Kod:
$sorgu = $pdo->prepare('SELECT * FROM tablo_adi WHERE id = :id');
$sorgu->execute([ 'id' => $id ]);
foreach ($sorgu as $satir) {
echo $satir['kullanici_adi'];
}Bu adımları takip ederseniz SQL Injection saldırılarına karşı savunma yaparsınız.
1.2 OS Command Injection
OS Command Injection zafiyeti, site üzerinden terminal komutlarını çalıştırma mantığına dayalıdır. Türkçe kaynaklara baktığımda fazla bir kaynak bulamadım. Gördüğüm kadarıyla da ping test siteleri üzerinden anlatım yapılmış. Geleneği bozmayayım ben de kendi linux sistemime kurduğum sunucuda bu zafiyete yer verdim. Anlatıma geçelim.
PHP'de shell_exec sayesinde terminal komutları çalıştırabiliyoruz.
Bunu test edelim.
Şimdi örnek bir senaryo ile açığı test edeceğiz. Bunun için bir form ekledim.
Sıra açığı test etmede. Düzgün çalışması için önce bir adres yazdım daha sonra linux komutunu devam ettirmek için && ls yazdım.
komut:
Kod:
www.google.com && lsGörüldüğü gibi açığı kullandık. Şimdi cd .. yazıp bir önceki dizine geçiyoruz ardından ls yazarak dosya ve klasörleri listeliyoruz.
komut:
Kod:
www.google.com; cd .. && lsBu açık sayesinde terminal komutlarını çalıştırabiliyoruz ancak bizim amacımız Defans olduğu için ayrıntıya girmeyeceğim. Açığın tehlike seviyesini az çok tahmin etmişsinizdir.
Defans
Çoğu saldırıda olduğu gibi bu saldırıda da savunmayı filtre ile yapacağız. Ben resimdeki gibi bir fonksiyon oluşturdum bu sayede terminal komutlarının çalışmasını engelledim. Ancak siz daha gelişmiş bir fonksiyon kullanmalısınız.
Bu filtrede blacklist yöntemini kullandım ancak önerim yine whitelist'dir.
Gördüğünüz gibi komut çalışmadı. Çünkü & işaretini sildik ve bu sayede geriye www.google.com ls kaldı. Bu komut da hata verdiği için ekrana bir yazı gelmedi.
Düzgün şekilde URL girdiğinizde ise komut çalışmaktadır.
2. Broken Authentication
Broken Authentication, kötü niyetli kişilerin bir oturumu taklit etmesi sonucunda oluşan bir açık türüdür. Oturum yönetimi kusurları da bu zafiyete sebep olmaktadır.
Oturum, bir web sitesinde giriş yaptığınızda başlar ve çıkış yaptıktan sonra biter. Bu sürece oturum yönetimi adı verilir.
2.1 Kırık Kimlik Doğrulama (Broken Authentication)
Genellikle kaba kuvvet saldırıları örnek gösterilmektedir. Brute-Force saldırılarına karşı tedbir alınmaması zafiyet oluşturmakta. Bu önlemlerden bazıları her IP için sınırlı deneme hakkı vermek, resimli doğrulama kullanmak, zayıf parolalar ile sisteme kayıt olmayı engellemektir.
2.2 Oturum Yönetimi Saldırıları (Session Management Attack)
2.2.1 URL Rewriting: Bu zafiyete parametre olarak gönderilen oturum bilgileri sebep olmaktadır. En basitinden siteye giriş yapıldığında kontrol için GET metodu ile gönderilen veriler (site.com/giris.php?kadi=admin&pass=admin123) apaçık ortada olduğundan bu verilerin ele geçirilmesi sonucu yetki sahibi olunduğu türdür.
2.2.2 Session Hijacking: Oturum çalma, oturum ele geçirme anlamlarına gelmektedir. Saldırgan geçerli oturum bilgilerini çalıp sunucuda yetki sahibi olmayı hedefler. Bu yöntemde saldırgan XSS Injection, Network Tracking, istemciye (bilgisayar ve web tarayıcısı) trojan atma gibi yolları tercih edebilir. Bunun haricinde oturum kimliğini (Session ID) ele geçirmek için Brute-Force gibi yöntemler de kullanılabilir.
Aktif/Pasif olarak saldırı iki tipi vardır. Aktif oturum üzerinden yetkilenmeye aktif saldırı, oturum ele geçirildikten sonra ağ trafiği izlenilerek verileri ele geçirmeye ise pasif saldırı denir.
2.2.3 Session Fixation: Bu açık türü saldırganın oturumu önceden planlamasından ötürü meydana gelir. Saldırgan, kullanıcıya belirlenmiş SESSID parametresi içeren bir URL gönderir. Kullanıcı bu URL üzerinden girişini yaparsa saldırgan sunucuya belirlediği SESSID'yi tanıtarak kullanıcının kimliği üzerinden işlemlerde bulunabilir.
Daha da açıklayıcı olması için bir senaryo kuralım:
- Saldırgana (aslında her ziyaretçiye) sunucu tarafından bir oturum kimliği (SESSID) tanımlanır. Saldırgan yetkili bir kullanıcıya bu kimliği içeren bir bağlantı yollar ve bu kimlikle giriş yapmasını sağlar.
- Giriş yapan yetkili bu oturum kimliğine sunucu tarafından bir yetki tanımlamış olur.
- Saldırgan bu kimlik ile kendini sunucuya tanıttığı zaman, hedef yetkilinin tüm yetkilerine sahip olur.
Sorun kullanıcı taraflı gözükse de sunucu tarafından bu durum engellenebilir. Örneğin ziyaretçi giriş yaptıktan sonra farklı bir kimlik verilebilir. Bu sayede önceki kimlik geçersiz olur ve saldırganın kimliği yetkilenemez. Ayrıca outlook gibi giriş yapan cihazı tanıma gibi özellikler de bu saldırıların önünü kesmekte.
Defans
» Brute-Force Saldırılarını Engelleme,
» Oturum Bilgilerini Parametre ile Almamak,
» Anomaly Dedection,
» Güçlü Parola Denetimi,
» SSL Kullanmak,
» Oturum İçin Süre Belirleme,
» Multi-Factor Authentication Koymak,
vb. yollar izlenebilir.
3. Sensitive Data Exposure
Sensitive Data Exposure, hassas verilere erişim anlamına geliyor. Özellikle bazı hassas verilere kolayca erişmek, bu açığın en büyük ekmeği sanırım. Örneğin Flat-File veri tabanlarının, erişimin mümkün olduğu dizinde saklanması da bu zafiyete kollarını açıyor. Ayrıca SQL Injection saldırılarında veri tabanı çekildiğinde karşımıza şifrelenmemiş dümdüz veriler geliyor. Bu bir hatadır çünkü bu verilerin şifrelenmesi gerekmektedir.
Defans
Verilerin, erişimin mümkün olmayacağı şekilde saklamak,
Verileri, veri tabanında şifrelenmiş biçimde saklamak. Şifrelemek önemlidir çünkü saldırgan veri tabanına bir şekilde sızmayı başarsa bile, şifrelediğimiz veriler onun hiçbir işine yaramayacaktır. Bu da veriler için koruma sağlayacaktır.
4. XML External Entities (XXE)
Bu zafiyeti anlamanız için öncelikle XML'i bilmeniz gerekiyor. XML, Genişletilebilir İşaretleme Dili olarak çevrilebilir. XML diğer özelliklerinin yanı sıra genel olarak veri saklama amacıyla kullanılmaktadır. JSON gibi düşünebiliriz. Özellikler pazaryeri siteleri ürünlerini aktarmada XML kullanırlar. Binlerce ürünü özellikleriyle birlikte farklı bir siteye eklemek akıl işi değildir zaten.
XML kullanmanın dezavtajları da görülmekte. Bu noktada XXE zafiyeti bir Injection türü diyebiliriz.
Bu zafiyetin çeşitleri de bulunmakta. Biz 4 türünü inceleyeceğiz.
4.1 Dosya Yükleme ile XXE Saldırısı
Dosya yükleme özelliğine sahip zafiyet bulunduran sunucularda, XLSX, DOCX, PPTX, SVG vb. zararlı yazılım içeren dosyaların yüklenmesiyle, etc/passwd gibi hassas bilgilere sahip verilerin ifşa edilmesine izin veren sunuculardaki zafiyettir. Upload edilecek dosya genellikle XML Medya türüne sahiptir.
4.2 Dosyalara Erişim Sağlayan XXE Saldırısı
Bu saldırıda etc/passwd gibi sunucudaki değerli bilgiler çalınabilir. Bu yazıdaki amacımız atak olmadığı için fazla ayrıntıya girmeyeceğim.
E-Ticaret üzerinden örneğe başladık. Örneğin bir stok takibi sayfasını incelerseniz, sayfanın XML ile oluşturulduğunu görebilirsiniz. Burp Suite yardımı ile XML enjekte ettiğinizde Entity kullanarak dosyalara erişim imkanı sağlarsınız.
Örneğin resimdeki gibi XML dosyasına Burp Suite kullanarak;
<!DOCTYPE deneme [<!ENTITY tht SYSTEM "file:///etc/passwd">]>
kodunu ekleyip çıktılardan birine &tht; komutunu eklerseniz dosya verisini &tht; yazdığınız yerde görüntüleyebilirsiniz.
4.3 SSRF Saldırısı
SSRF saldırısında dosyalara erişim sağlarken kullanılan yöntemin aynısını, fakat dizin adresi yerine IP adresi yazılır.
<!DOCTYPE deneme [<!ENTITY tht SYSTEM "192.168.1.1">]>
<deneme>&tht;</deneme>
Burada <deneme> </deneme> etiketi arasına bir Response (yanıt) gelecektir. Gelen yanıt x olsun.
<!DOCTYPE deneme [<!ENTITY tht SYSTEM "192.168.1.1/x">]>
<deneme>&tht;</deneme>
Bu sefer IP sonuna / koyup gelen yanıtı ekledik. Yine Request yani istek yollayıp yanıt bekliyoruz. Bu sefer gelen yanıt y olsun.
<!DOCTYPE deneme [<!ENTITY tht SYSTEM "192.168.1.1/x/y">]>
<deneme>&tht;</deneme>
Gördüğünüz gibi bu şekil ilerliyor. Devamında bilgilere ulaşana kadar bu işlem yapılır.
4.4 Xi:include
Bazı siteler, istemci taraflı gönderilen verileri alır, verileri sunucuda bir XML dosyasına yerleştirir daha sonra da ayrıştırır. Bu tip durumlarda klasik XXE saldırıları işe yaramayacaktır.
Bu durumlarda Xinclude yöntemi tercih edilir. Aşağıda örnek bir kullanım verilmiştir.
urunId=<denemeetiket xmlns:xi="http://www.w3.org/2001/XInclude"><xi:include parse="text" href="file:///etc/passwd"/></denemeetiket>&magazaId=1
Defans
» XML External Entitiy özelliğini devre dışı bırakmak,
» XML'i güncel tutmak,
» Dış varlıkların çözümlenmesini devre dışı bırakmak,
» SOAP 1.2 ve üstü sürümünde çalışmak,
» Xinclude desteğini devre dışı bırakmak,
» Filtreleme (Whitelist önerilir) yapmak.
5. Broken Access Control
Broken Access Control, adından da anlaşılacağı üzere web uygulamasında erişim kontrolünün hatalı yapılmasından kaynaklanmaktadır. Örneğin bir parametre üzerinden veri alırken bunun kontrolünü tamamen kullanıcıya bırakırsanız, daha yetkili bir hesap üzerinden erişim sağlayacabilecektir.
Çok basitinden bir web uygulaması yaptım, onu test edelim.
Kullanıcı ve admin için 2 hesap mevcut. Bu hesaplara giriş yaptığımızda "oturum" isminde tanımladığımız SESSION "true" olarak değişiyor.
index.php
girisyap.php
Normal bir şekilde oturum açacağız. "user" isminde kullanıcı ile giriş yapıyorum.
Gördüğünüz üzere oturum açtık ve parametremiz index.php?kullanici_adi=user olarak değişti.
Yalnız burada bir sorun var. Oturum açıp açmadığımız kontrol ediliyor ancak parametredi kullanıcı adımızı değiştirip değiştirmediğimizi kontrol etmiyor. Bu parametreye admin yazsak ne olur? Deneyelim.
Gördüğünüz üzere oturumu user yetkisinde açtık fakat parametreyi değiştirdiğimiz için admin yetkisine sahip olduk.
Bu çok basit bir örnek zaten bu kadar basit bir açığı kimse bırakmayacaktır. BAC zafiyetini anlamanız için örnekledim.
Defans
» Her sayfada kimlik doğrulama yapmak,
» Hata kodlarını, veri tabanı veri özelliklerini açığa çıkarmayacak şekilde ayarlamak,
» Web sayfaların varsayılan adlarını değiştirmek,
» Rol tabanlı kimlik doğrulama kullanmak,
» Kullanıcının her işlemi için kimlik doğrulaması yapmak,
» Kullanıcıyı doğru şekilde tanımlamak.
6. Security Misconfiguration
Security Misconfiguration, varsayılan yapılandırma, kullanılmayan veya yanlış kullanılan eklentiler, güncel tutulmayan yazılımlardan kaynaklı zafiyettir.
Varsayılan yapılandırma zafiyet örneği: Wordpress kurdunuz ve bu kurulumdaki şifreyi varsayılan bıraktınız, değiştirmediniz. Bu durumda saldırganlar tarafından oluşturulmuş dork sayesinde taramalarda siteniz çıkarsa, sitenize kolayca Brute-Force saldırısıyla erişebilirler.
Eklenti dolaylı zafiyet örneği: Sisteminizde kurulu eklentileri kullanmıyorsunuz ve yapılandırmalarını yapmadınız. Eklenti taraflı bir zafiyet mevcut olduğunda bununla ilgilenmediğiniz için farketmeyeceksiniz ve sistemde güvenlik açıklarına yer vereceksiniz.
Güncellememe sebebiyle oluşan zafiyet örneği: Kullandığınız sistemin sürümü 1.0 olsun. Saldırganlar tarafından keşfedilen açık sayesinde kullandığınız sürümde zafiyet olduğu biliniyor. Sistem geliştiricilerinin yayınladığı 1.1 sürümü güvenlik açıklarının kapatıldığı sürüm fakat siz güncellemediğiniz için zafiyet hâlen mevcut. Saldırganlar tarafından kullanılması an meselesi.
Defans
» Varsayılan ayarları mutlaka değiştirin,
» Kullanmadığınız eklentileri kaldırın veya yapılandırın,
» Yayınlanan en son sürümü kullanın.
7. Cross-Site Scripting (XSS)
XSS zafiyeti, HTML, JS kodlarının çalıştırılabilmesinden kaynaklanan bir açıktır. Açılımı Cross-Site Scripting olan bu açığın 3 farklı çeşidi vardır. Bu zafiyet türünde doğrudan veri tabanı saldırısı olmaz.
» Reflected XSS
» DOM-Based XSS
» Stored XSS
7.1 Reflected XSS
Reflected XSS, kullanıcının sitede bir yere JavaScript kodlarını yazıp çalıştırabildiği açık türüdür. Örnek verecek olursak bir arama çubuğuna JavaScript komutunu yazdınız. Eğer yazılımcı bu kodları filtrelememişse sayfada JavaScript kodları çalışacaktır. Reflected XSS açığının kullanılmış olduğu link kurbana atılırsa, sosyal mühendislik yöntemleri ile bilgileri çalınabilir.
Örnek bir link:
Kod:
http://www.site.com/index.php?arama=%3Cscript%3Ealert%28%22A%C3%A7%C4%B1k+Var%22%29%3B%3C%2Fscript%3EÖRN: Bir arama formu oluşturdum ve bu aramadan gelen değeri dökümana yazdırdım. Sonuçlara bakalım:
Gördüğünüz gibi zafiyet oluştu.
Defans
» Bu durumdan kurtulmanın kolay bir yolu var. En basitinden dökümana bastırmadan önce PHP kısmında strip_tags() filtresini kullanacağız. Bu fonksiyon HTML kodlarını filtreler. Filtrelediğimiz HTML kodlarında <script></script> silindiği için JavaScript komutları çalışmayacaktır.
7.2 DOM-Based XSS
DOM kaynaklı bir XSS zafiyet türüdür.
Örneğin;
Kod:
<script type="text/javascript">
d ocument.write(decodeURI(d ocument.href));
</script>koduna sahip bir site yakaladık. URL sonuna #<script>alert("Açık Var")</script> eklediğinizde, JavaScript dökümana bu veriyi bastığı için JavaScript kodumuz çalışacaktır.
Defans
JavaScript ile çalışırken dışarıdan alınan verileri filtrelemelisiniz. Filtrelemede 2 farklı yol kullanabilirsiniz.
» Blacklist
» Whitelist (Önerilen)
Blacklist, belirlediğiniz karakterlere göre çektiğiniz veriyi filtrelemektir.
Whitelist, çektiğiniz veride sadece belirlediğiniz karakterlerin olmasına izin verir. Bu yöntem daha güvenlidir.
7.3 Stored XSS
Stored XSS zafiyeti tehlikeli bir açıktır. Çünkü bu açık için bir URL parametresine ihtiyaç yoktur. Açığın kullanıldığı kod kaydedildiği için belki binlerce kişiye ulaşabilir.
Örneğin Facebook'ta filtreleme yok. Biz kayıt olurken kullanıcı adımıza <script>alert("Facebook Hacked")</script> koyduk. Bu veri tabanına başarılı bir şekilde kaydedildiğinde bizim kullanıcı adımızın geçtiği her sayfada JavaScript komutu çalışacaktır.
Ben kendi sitemde bir kayıt formu oluşturdum ve bu input'ları filtrelemeden direk veri tabanına kaydettim. Daha sonradan başka bir kullanıcı bu veriyi çektiğinde JavaScript kodları çalışacaktır.
Daha detaylı anlatmak için açıklı bir sosyal medya platformunda çevrimiçi kullanıcıları listelemek istiyorum.
Bu sırada zararlı kodları kullanıcı adı yapmış bir üye çevrimiçi oluyor. Sonuç:
Biz bu zararlı kod barındıran kullanıcı adını dökümana bastığımız için kodlar çalıştı.
Defans
» Reflected XSS'de yaptığımız gibi veri tabanına ekleme yaparken ve veri tabanından veri çekerken mutlaka strip_tags() filtresinden geçirmeliyiz.
Gördüğünüz gibi sitede kodlar çalışmadı. Sadece yazdırıldı.
8. Insecure Deserialization
Serialize, kompleks verilerin serileştirilmesine ve dolayısıyla kolayca saklanmasına/depolanmasına yarar. Deserialization ise bu serileştirme işleminin tam tersi, yani saklanen verilerin tekrar kompleks verilere çevrilmesi işlemidir.
Örneğin PHP'de vir Array'i veritabanında kaydetmek istiyorsunuz. İşte Serialize işlemi sayesinde verileri serileştirip kolayca saklayabilirsiniz.
Insecure Deserialization ise manipüle edilmiş (değiştirilmiş) objenin web uygulamasına Inject edildiği saldırı türütür. Bu saldırı sonucunda SQL Injection, RCE (Remote Code Execution - Uzaktan Kod Yürütme), Dizinleri görüntüleme gibi sorunlar meydana gelebilir.
Mesela internetten bulduğum örnek Serialize edilmiş PHP nesnesinin görüntüsü:
O:6:"Member":2:{s:8:"username";s:4:"Fred";s:16:"MemberloggedIn";b:1;}
Eğer saldırgan bu serileştirilmiş veriyi manipüle edebilir ve bunu direk PHP Unserialized işlevine gönderebilirse, Insecure Deserialization zafiyeti ortaya çıkar.
Defans (Birkaçı)
» JSON veya XML gibi veri tiplerini kullanmak,
» Herhangi bir serileştirilmiş veriye dijital imza uygulayın,
» Seriyi kaldıran kapsayıcılardan veya sunuculardan ağ bağlantısını kısıtlayın veya izleyin,
» Sürekli olarak serileştirilmiş verinin kaldırılmasına izin vermeyin.
9. Using Components with Known Vulnerabilities
Bu zafiyet uygulamada kullanılan Frameworks (uygulama çatıları), Library (Kütüphane), Modüller gibi bileşenlerden kaynaklanır. Bu bileşenler, uygulamada genellikle tam yetkiyle çalıştığı için bu bileşenlerin istismar edilmesi sonucu saldırganın uygulamaya zarar vermesi kolaylaşır.
Örneğin JavaScript'de kullandığınız jQuery kütüphanesinin bilindik bir zafiyeti varsa, siz istediğiniz kadar uygulamanızı güvenli yazarsanız yazın, saldırgan kütüphanedeki açıktan faydalanıp uygulamanızın güvenlik seviyesini düşürebilir.
Örnek bir vaka;
https://snyk.io/blog/malicious-code-found-in-npm-package-event-stream/
Defans
» Buradaki en doğru çözüm, güvenliğinden emin olmadığınız bileşenleri kullanmamak olacaktır.
10. Insufficient Logging & Monitoring
Insufficient Logging & Monitoring, adından da anlaşılacağı üzere yetersiz günlük kaydetme ve izleme sebeplerinden açığa çıkan güvenlik zafiyetleridir. Doğrudan bir güvenlik açığı olmasa da yapılan bu hata zafiyetlerin tespitini zorlaştırır, zafiyetlerin ilerlemesine sebep olur.
Senaryo: Küçük bir işletmede yetki sahibi kullanıcının hesabına Brute-Force saldırısı yapılıyor. Bu esnada Insufficient Logging & Monitoring dediğimiz olay gerçekleşiyor ve saldırganın Brute-Force saldırısı bolca vakti oluyor. Sonunda başarıyor ve verilere erişiyor. Oysaki günlük kaydı ve izleme sistemi düzgün çalışmış olsaydı bilişim departmanı saldırgana müdahale edebilecekti.
Defans
» Logging & Monitoring işlemlerinin düzenli olarak takip edilmesi ve test edilmesi bu sorunu ortadan kaldırmak için gerekli bir adımdır.
Bu yazıda OWASP Top Ten çalışmasında bildirilen tehlikeli zafiyet sıralamasında bulunan açıkları tanıyarak bu açıklara karşı korunma yollarını öğrendik. Unutmayın ki zafiyetler buradaki 10 açıkla sınırlı değildir. Önümüzdeki yıllarda bu sıralamaya girebileceği öngörülen zafiyetleri tanımanız gerekmektedir. Sistemdeki her kullanıcının bilgilerini alırken bir sorumluluk da almış olursunuz. Bu yüzden ben yazılımın sadece kod yazma yeteneği ile bittiğini düşünmüyorum.
Okuduğunuz için teşekkür ederim
Son düzenleme:
