Owasp(Open Web Application Security Project), web uygulama güvenliği ile ilgilenen, bu konuda makaleler/uygulamalar yazan kâr amacı gütmeyen bir kuruluştur.

Owasp’ın web sitesinde, web uygulamalarındaki zafiyetleri, zafiyetlerin nasıl oluştuğunu, zafiyetlerin nasıl exploit edilebileceğini ve bu zafiyetlerin nasıl önlenebileceği ile ilgili çok güzel yazılar bulunuyor. Fakat Owasp’ın çok güzel bir şeyi daha var: Owasp Top 10

Owasp, birçok firma ve web uygulama sızma testleri ile ilgilenen kişilerden bilgi toplayarak o yıla ait en riskli 10 güvenlik zafiyetinin istatistiğini çıkartıyor. Bu da firmaların “nerelerden daha çok gol yeniyor(!)” anlamalarına ve sızma testi ile ilgilenen kişilerin ise hangi zafiyetlerin üzerinde daha çok duracaklarını bir nebze değiştiriyor.

Owasp çokta uzak olmayan bir zamanda bu yıla ait(2017) en çok riske sahip 10 güvenlik zafiyetini yayınladı. Bu listeyi beraber inceleyelim.

Owasp Top 10 – 2017

1. Injection
2. Broken Authentication
3. Sensitive Data Exposure
4. XML External Entities (XXE)
5. Broken Access Control
6. Security Misconfiguration
7. Cross-Site Scripting (XSS)
8. Insecure Deserialization
9. Using Components with Known Vulnerabilities
10. Insufficient Logging & Monitoring

Injection

Injection zafiyetleri genellikle kullanıcıdan alınan, kontrol edilmeyen yada önlem alınmayan verilerin komut olarak çalıştırılması yada sorguya dahil edilmesi yüzünden oluşur.

Saldırgan beklenilenden farklı bir veri göndererek sistemde komut çalıştırabilir, erişmemesi gereken verilere erişebilir hale gelir. Saldırgan komut çalıştırarak zaten sisteme erişmiş oluyor. Saldırgan bundan sonra hak yükseltme zafiyetlerini kullanarak sistemdeki etkinliğini dahada arttırabilir, bütün organizasyonun içine sızabilir. Injection neden risk sıralamasında en üstte artık anlayabiliriz.

SQL Injection ve Command Injection en yaygın injection türleridir ve ikiside kullanıcıdan gelen verinin kontrol edilmemesi, filtrelenmemesi yada “sterilize” edilmemesinden kaynaklanıyor.

Owasp bu zafiyetlerin tespit edilmesinin en iyi yönteminin kaynak kod analizi olduğunu belirtiyor.

SQL Injection

Sql injection, kullanıcıdan gelen verinin direk olarak sql sorgusuna dahil edilmesinden kaynaklanıyor. Örneğin bir websitesi düşünün:

http://somewebsite.com/news.php?read=113

Bu websayfası read parametresindeki değeri sql sorgusu ile veritabanındaki kayıtlı olan haberler arasından bulup kullanıcıya gösteriyor. Hiçbir önlem alınmadığını varsayalım. Yukarıdaki sayfayı ziyaret ettiğimizde şu şekilde bir sql sorgusu çalışıyor.

SELECT * FROM news WHERE id = 113

Şu ana kadar her şey normal. Fakat kötü amaçlı birisi read parametresine beklenilmeyen bir veri girerse ne olacak? Saldırganın şu şekilde bir parametre girdiğini düşünelim.

http://somewebsite.com/news.php?read=**113; DROP ALL TABLES; –**

Bu sayfa çalıştığı zaman arka tarafta

SELECT * FROM news WHERE id = 113; DROP ALL TABLES; —

sql sorgusu çalışacak ve veritabanındaki tüm tablolar silinecek. Tabiki sql injection la sadece tablo silme işlemi yapmıyorsunuz, aynı zamanda tüm tablolardaki verileri de görebiliyorsunuz ve hatta komut bile çalıştırabiliyorsunuz.

SQL injection ile saldırganın yönetici parolalarını çaldığını düşünün. Artık o sistemi ele geçirmiş demektir saldırgan.

Command Injection

Bir web sayfası düşünün, aldığı parametre isminde sistemde dosya oluşturuyor.

http://somewebsite.com/admin/command.php?*command*=**deneme.txt**

Bu sayfada command parametresine verdiğimiz değer isminde sistemde dosya oluşuyor diyelim. Bu sayfanın kaynak kodları şu şekilde olsun.

<?php
...
$file=$_GET['command'];
system("touch $file");
...
?>

Normal bir kullanıcı dosya.txt adında bir dosya oluşturmak istediğinde sistemde “touch dosya.txt” komutu çalışıyor. Şuana kadar her şey normal.

Saldırgan ise şu şekilde bir değer veriyor.

http://somewebsite.com/admin/command.php?command=**dosya.txt; reboot**

Bu sefer sistemde “touch dosya.txt; reboot” komutu çalışıyor. Dosya oluşuyor fakat ardından sistem yeniden başlatılıyor. Tabi bu örnekte sadece sistemi yeniden başlatıyor. Bu zafiyet ile sistemde her türlü komutu çalıştırabiliyorsunuz. Gerisi saldırganın hayal gücüne kalmış!

Broken Authentication

Broken Authentication zafiyeti genellikle kimlik doğrulama yada oturum yönetimi ile ilgili fonksiyonların yanlış uygulanması sonucunda ortaya çıkar. Saldırganlar parolaları, session token ları ele geçirebilir.

Saldırganlar genellikle brute force(kaba kuvvet saldırıları) yaparak kullanıcıların kimliklerini açığa çıkartabilirler.

Aynı şekilde default parolaların kullanımı saldırganların uygulamaya sızmalarına neden olur. Örneğin: admin, admin123, password, 123456, tomcat…

Önlem olarak:

1. Kolay tahmin edilemeyen, güçlü parolaların kullanılması
2. Default parolaların kullanılmaması, web servisi kurarken servisin sağladığı ilk parolaların değiştirilmesi
3. Yanlış giriş denemelerine sınır koyulması
4. Yanlış giriş denemelerinin log altına alınması ve incelenmesi
5. Mümkünse girişlerde robot kontrolü yapılması
6. Olabildiğince random session token üretilmesi ve session token larının düzgün uygulanması

Sensitive Data Exposure

Bu zafiyet türü verilerin şifrelenmemesi veya şifrelenen verilerin eski, default, açığa çıkmış şifreleme algoritmaları kullanılmasından ortaya çıkıyor.

Kredi kartı bilgileri, parolalar, kişisel kayıtlar, firma belgeleri ve daha bir çok önemli bilgilerin şifrelenmesi gerekmektedir.

Saldırgan, sql injection zafiyetini kullanarak veritabanındaki verilere erişebilse bile şifrelenmiş verileri anlamlandıramaz ise bir işine yaramayacaktır. Kullanılmakta olan şifreleme algoritmalarının güçlü olması burada işimize yarayacaktır.

Aynı zamanda sunucu tarafında bilgiler kayıt altına alınırken şifrelense bile, bilgiler client tan sunucuya aktarılırken şifrelenmeden gidiyor ise buda bir zafiyet oluşturmaktadır. Saldırgan client ile sunucu arasındaki trafiği izleyip önemli bilgilere erişebilir. Bu yüzden sunucu tarafında şifrelemenin yanı sıra transfer esnasında da şifreleme kullanılmalıdır.

Bilgiler clear text transfer ediliyorsa, default şifreleme anahtarı kullanılıyorsa, eski/açığa çıkmış şifreleme algoritmaları kullanılıyorsa, veriler yedeklenirken cleartext olarak yedekleniyorsa bu zafiyetten etkilenilir. Önlem olarak:

1. Http, ftp, smtp gibi güvensiz cleartext olarak çalışan protokoller yerine, şifreli bir şekilde transfer yapan https, ftps, smtps gibi protokoller kullanılmalıdır.
2. Default olarak gelen şifreleme anahtarları değiştirilmelidir.
3. Eski şifreleme algoritmalarının yerine güçlü şifreleme algoritmaları kullanılmalıdır.
4. Verileri kaydederken şifreli bir şekilde kaydedilmelidir.

XML External Entities

Bu zafiyet Owasp’ın 2013 yılında yayınladığı listede bulunmuyor. Fakat bu yıl yayınladığı top 10 listesinde 4.sırada yer alıyor.

Bu zafiyet eski yada yanlış configure edilmiş xml parserlarından kaynaklanıyor. Saldırgan bu zafiyeti kullanarak sunucuya zararlı bir xml dosyası göndererek sunucudan dosya okuyabilir, kod çalıştırabilir, ve dos(denial of service) saldırısı gerçekleştirebilir durumuna geliyor.

Örneğin kullanıcıdan bir xml dosyası alan ve içeriğini ekrana bastıran bir sayfa olsun.

<?php
$xml = simplexml_load_string(file_get_contents(“php://input”));
echo $xml;
?>

Biz bu sayfaya şu şekilde bir xml dosyası gönderelim

<?xml version=”1.0″ ?>
Some legit writing

Normal olarak sayfada “Some legit writing” yazacaktır.

Fakat saldırgan şu şekilde bir xml dosyası göndererek sunucuda dosya okuyabilir durumuna geliyor.

<?xml version=”1.0″ ?>
<!DOCTYPE tag [<!ENTITY ups SYSTEM “file:///etc/passwd”>]>
&ups;

Saldırgan bu xml dosyasını gönderdiğinde sunucuda bulunan kullanıcıların olduğu dosyayı okuyabilir.

Owasp bu zafiyet için şunları öneriyor:

• Eğer mümkünse daha az karmaşık olan JSON formatını kullanın
• XML ile ilgili kütüphaneleri güncel tutun
• XML External Entity özelliğinin kapatılması
• Sunucu tarafında “whilelisting” kontrolünün yapılması

Broken Access Control

Bu açıklıklar hangi kullanıcıların neleri yapabileceğinin düzgün uygulanmaması sonucu oluşur. Saldırganlar bu zafiyetleri kullanarak izni olmayan dosyalara erişebilir, yetkisi olmayan fonksiyonları kullanabilir, diğer kullanıcıların verilerine erişebilir yada yetkileri değiştirebilir.

Örnek saldırı senaryosu:

http://somewebsite.com/kullanici.php?**kull=ahmet**

Websitesine giriş yapıldığında yukarıdakine benzer bir sayfaya gidip kullanıcı bilgilerinin görüntülendiği bir sayfa olsun. Normal bir kullanıcı olması gerektiği gibi kendi bilgilerini görecektir. Fakat saldırgan “kull” parametresini değiştirdiğini varsayalım.

http://somewebsite.com/kullanici.php?**kull=mehmet**

Artık saldırgan istediği kullanıcının bilgisini görebilir. Hatta dictionary saldırısı kullanarak olası bütün kullanıcıların bilgisini ele geçirebilir.

Önlemler:

• Genel verilerin harici diğer verilerin default olarak engellenmesi
• İzin kontrol mekanizmasının düzgün olarak yapılıp diğer yerlerdede kullanılması
• Server directory listing’in disable edilmesi
• Yanlış erişimlerin loglanması ve adminlere bildirilmesi

Security Misconfiguration

Servis ayarlarının yanlış yada eksik yapılması bu zafiyet türünün ortaya çıkmasına neden olur. Owasp’ a göre en çok bulunan güvenlik zafiyeti security misconfiguration dır.

Gereksiz servis ve eklentilerin yüklenmesi, default kullanıcıların değiştirilmemesi/kaldırılmaması, sistemde bulunan servislerin güncel olmaması bu zafiyeti ortaya çıkartır.

Örneğin XML External Entity özelliği kullanılmıyor fakat açıksa bu zafiyetin ortaya çıkmasına neden olur.

Önlemler:

• Sistemin ve servislerin güncel tutulması
• Gereksiz servis ve uygulamaların kaldırılması
• Default parolaların değiştirilmesi
• Hardening yapılması

Cross Site Scripting

Cross Site Scripting(XSS), kullanıcıdan alınan verilerin kontrol edilmeden, filtrelenmeden html response olarak gönderilmesi sonucu oluşur. XSS zafiyeti sayesinde saldırganlar kullanıcı browserında javascript çalıştırarak kullanıcı oturumunu çalabilirler.

XSS, sıklıkla karşılaşılan bir zafiyettir. Kontrol edilmeyen bir input, bütün uygulamayı ele geçirmesine neden olabilir.

Reflected XSS:

Reflected XSS, kullanıcıdan alınan verinin sadece o anlık html response a eklenip kullanıcının browser ında javascript kodu çalıştırabilmesidir. Bu XSS türünde XSS payloadı, sunucu tarafında kayıt altına alınmaz. Reflected XSS genellikle zararlı linklerin tıklanması sonucu olur. Personellere farkındalık eğitimi verilmesi bu tür saldırıların engellemesinde rol oynayabilir.

Örnek bir zararlı link(Gerçek değildir, sadece linkin genel bir tipi):

http://somewebsite.com/index.php?ad=<&script>alert(“Reflected XSS”);</&script>

Stored XSS:

Bu XSS türünü Reflected XSS‘ten ayıran özellik, Stored XSS adından da anlaşılacağı gibi sunucu tarafında kayıt altına alınıyor ve o sayfa her çağırıldığında kullanıcı tarafında javascript kodu çalıştırılıyor. Reflected XSS’ ten daha fazla zarar verme potansiyeli vardır. Çünkü Reflected XSS ten etkilenen sadece o linki tıklayandır fakat Stored XSS te o sayfayı görüntüleyen bütün kullanıcılar etkilenir.

DOM XSS:

Bu XSS türü html üzerinde değil de DOM objeleri üzerinde etki ediyor. Yine aynı şekilde kullanıcının browser ı üzerinde zararlı javascript kodları çalıştırılmasına neden oluyor.

Örnek URL:

http://somewebsite.com/index.html#<&script>alert(“dom based xss”);<&/script>

XSS’e karşı alınabilecek önlemler:

• Kullanıcıdan alınan verilerin kontrol, sterilize edilmesi
• XSS saldırılarına önlem alan framework ler kullanılması
• Personellere farkındalık eğitimi verilmesi

Insecure Deserialization

Bu zafiyet kullanıcıdan gelen güvenilmeyen zararlı inputun deserialization u sonucu oluşuyor. Bu zafiyet, denial of service saldırılarına yada remote code execution saldırılarına yol açabiliyor. Bu yüzden kullanıcıdan gelen verilerin kontrol edilmesi gerekmektedir.

Java deserialization örneğine bakalım.

Set root = new HashSet();
Set s1 = root;
Set s2 = new HashSet();
for (int i = 0; i < 100; i++) {
Set t1 = new HashSet();
Set t2 = new HashSet();
t1.add("foo"); // make it not equal to t2
s1.add(t1);
s1.add(t2);
s2.add(t1);
s2.add(t2);
s1 = t1;
s2 = t2;
}

“root” objesi deserialization sonucunda sürekli kendini tekrar ediyor ve denial of servise saldırısına dönüşüyor.

Bu zafiyet hakkında Owasp’ı ziyaret ederek daha detaylı bilgi alabilirsiniz.

Using Components with Known Vulnerabilities

Bu zafiyet türü kullanılan servislerin, uygulamaların, eklentilerin eski ve bilindik exploitleri olan sürümlerinin kullanılması sonucu oluşuyor. Saldırganlar bu servislerin sürümlerini bulduktan sonra bilindik exploitleri kullanıp uygulamayı/sunucuyu ele geçirebilirler. Buda büyük bir risk oluşturuyor.

Önlemler:

• İşletim sistemini, servisleri, uygulamaları güncel tutmak
• Kullanılmayan servisleri kaldırmak
• Düzenli olarak yeni çıkan zafiyetleri kontrol edip uygun güncellemenin yapılması

Insufficient Logging and Monitoring

Yeterli log lama ve monitoring işleminin yapılmaması büyük bir risk oluşturuyor. Girişler, başarısız giriş denemeleri, transferler ve önemli olan faliyetler loglanmalı ve sürekli kontrol edilip gerektiği yerde yöneticiler uyarılmalıdır.

Saldırganın bruteforce saldırı yaptığını düşünelim. Eğer giriş denemeleri loglanır ve izlenirse belli bir denemeden sonra sistem adminlerinin dikkatini çekecek ve saldırının önüne geçme imkanı sağlayacaktır.

İlk 10 zafiyete bakarak çoğunluğunun kullanıcıdan gelen verinin kontrol edilmemesinden dolayı olduğunu görüyoruz. Her zaman kullanıcıdan gelen veriye güvenmeyip, sistemi ve servisleri güncel tutup ve olayları kayıt altına alıp izlenirse saldırıların bir nebze önüne geçmiş olunur. Ayrıca güvenliği sonradan sağlamak yerine, güvenli kod geliştirilmesi daha iyidir.