Artan Güvenlik Risklerine Karşı Sisteminizi nasıl korumalısınız?


OWASP ( Open Web Application Security Project) web uygulama güvenliği ile ilgilenen, bu konuda makale ve uygulamalar yayınlayan kar amacı gütmeyen bir kuruluştur. Workcube OWASP'ı takip etmekte ve düzenli olarak iyileştirme faaliyetlerinde bulunmaktadır.


OWASP TOP 10 listesinde muhtemel güvenlik problemleri ve bu problemlerden korunma yolları aşağıdaki gibi sıralanmaktadır.

  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 Compenents With Known Vulnerabilities
  10. Insefficient Logging & Monitoring

A1. Injection Açıkları
Injection zafiyetleri kullanıcıdan alınan veri içerisinde bir komut veya sorgunun bir bölümünün yorumlayıcıya gönderilmesi ile gerçekleştirilir. Injection açıkları özellikle SQL Injection web uygulamalarında ortak bir açıktır. Birden çok injection tipi vardır : SQL, LDAP, XPath veya NoSQL, XML ayrıştırıcıları, OS komutlarında, SMTP headerlarında, ifade dilleri ve ORM query’leri ve daha fazlası. Injection veri sızmasına veya doğrudan kaybına neden olur.

Nasıl Korunulur?
Yorumlayıcıların kullanımından kaçınılmalıdır. Eğer yorumlayıcıya istek gönderilecekse API kullanılmalıdır. Örn. Güçlü sorgu ve ilişkili nesne haritalama kütüphaneleri (ORM) kullanılabilir.
Sunucu taraflı giriş doğrulaması için “beyaz liste” kullanın. Birçok uygulama, mobil uygulamalar için metin alanları veya API’ler gibi özel karakterler gerektirdiğinden bu tam bir savunma değildir. Depolanmış prosedürler çağırıldığında işaretçilerin yerine güçlü tipte sorgular koyulmalıdır.
Girilen verilerin doğrulanması gerekir. (SQL injectionlar için limit veya sql kontrollerinin kullanılması gerekir. Veritabanı erişim yetkileri doğru yapılmalıdır.


A2. Broken Authentication 
Saldırganların kullanıcı bilgilerini, şifreleri, sessionları brute force (kaba kuvvet saldırı) kullanarak ele geçirmek için kullandığı zaafiyet türüdür. Saldırganlar manuel araç kullanarak kırılmış kimlik doğrulamayı tespit edebilir veya otomatik araç kullanarak şifre listesini ve sözlük saldırılarılarını sömürebilir. Saldırgalar sadece bir kaç önemli hesaba erişip amaçlarına ulaşabilirler.Örneğin Admin hesabına erişirse bu kullanıcı ile büyük zararlar verebilirler

Nasıl Korunulur?
Mümkünse çok faktörlü kimlik doğrulama işlemi yapılırken otomatikleştirmeyi engellemek gerekir. Admin/Administrator kullanıcılar için herhangi bir kimlik bilgisi eklenmemelidir. Güçlü şifre kontrolleri uygulanması zorunludur. Şifre uzunluğu, karmaşıklığı modern şifre politikalarına uygun olmalıdır.
Tüm sonuçlar için aynı mesajların kullanılması gerekiyor.  API yollarının zorluğundan emin olunması gerekiyor. Başarısız oturum açmalarına sınır konulması gerekir. Tüm bilgilerin günlüğe kayıt edilmesi gerekir. Kaba kuvvet veya herhangi bir saldırı algılandığında yöneticilerin uyarılması gerekir.
Olabildiğince random session token üretilmesi ve session tokenların düzgün uygulanması zorunludur. 


A3. Sensitive Data Exposure
Bu zaafiyet türü verilerin şifrelenmemesi veya verilerin eski, default, açığa çıkmış şifreleme algoritmaları kullanılmasından ortaya çıkar. Kredi kartı bilgileri, parolalar, kişisel  kayıtlar, firma belgeleri ve daha bir çok önemli bilgilerin şifrelenmesi gerekmektedir.
Aynı zamanda sunucu tarafında bilgiler kayıt altına alınırken şifrelense bile, bilgiler clienttan sunucuya aktarılırken şifrelenmeden gidiyor ise bu da bir zaafiyet oluşturmaktadır. Bu yüzden sunucu tarafında şifrelenmenin yanı sıra transfer esnasında da şifrelenme kullanılmalıdır.

Nasıl korunulur?
Eski şifreleme algoritmalarının yerine güçlü şifreleme algoritmaları kullanılmalıdır. Güvenli olmayan kanallarda asla kişisel anahtarlarınızı yayınlamayın.Http, ftp, smtp gibi güvensiz cleartext olarak çalışan protokoller yerine şifreli bir şekilde transfer yapan https, ftps, smtps gibi SSL protokoller kullanılmalıdır.
PCI veri güvenliği standart gereksinim 3 altında, cardhpolder verisini korumalısınız. En iyi pratik asla gereksiz veriyi depolamamaktır.


A4. Xml External Entities (XXE)
Bu zaafiyet eski ya da yanlış configure edilmiş xml parselarından kaynaklanıyor. Saldırganlar bu zaafiyeti kullanarak sunucuya zararlı bir xml dosyası göndererek sunucudan dosya okuyabilir, kod çalıştırabilir ve dos saldırısı gerçekleştirebilir

Nasıl korunulur?
Eğer mümkünse daha az karışık olan JSON formatını kullanın. XML ile ilgili kütüphaneleri güncel tutun. XML External Entity özelliğinin kapatılması faydalı olacaktır. Sunucu tarafından “whilelisting” kontrolünün yapılması gereklidir.


A5. Broken Access Control
Saldırganlar bu zaafiyeti kullanarak izni olmayan dosyalara erişebilir, yetkisi olmayan fonksiyonları kullanabilir, diğer kullanıcıların verilerine erişebilir ya da yetkileri değiştirebilir.

Nasıl korunulur?
Genel verilerin harici diğer verilerin default olarak engellenmelidir. İzin kontrol mekanizmasının düzgün olarak yapılıp diğer yerlerde de kullanılması ve  Server directory listingin disable edilmesi şarttır. Yanlış erişimlerin loglanması ve sistem yöneticisine bildirilmesi ve yöneticinin düzenli montor etmesi şarttır.


A6. Security Misconfiguration
Servis ayarlarının yanlış ya da eksik yapılması sonucu ortaya çıkan bir zaafiyet türüdür. Security misconfiguration, network service’leri, platform, web server, application server, veritabanı, frameworks, custom code ve önceden yüklenmiş sanal makineler, containers veya storage dahil olmak üzere herhangi bir uygulama yığınında olabilir. 

Nasıl korunulur?
Kullanılmayan özellikleri veya frameworkleri kaldırın.Tüm ortamlarda yapılandırmaların ve ayarların etkinliğini doğrulamak için kontroller yapın. Default parolaları mutlaka değiştirin.


A7. Cross Site Scripting (XSS)
Kullanıcıdan alınan verilerin kontrol edilmeden, filtrelenmeden html response olarak gönderilmesi sonucu oluşur.  Genellikle kullanıcıların tarayıcılarını hedef alan üç XSS formu vardır:

  • Reflected XSS:  Kullanıcıdan alınan verinin o anlık kullanıcı browserında JS kodu çalıştırabilmesidir. Reflected XSS genelde zararlı linklere tıklanması sonucunda oluşur.
  • Stored XSS: Genellikle yüksek veya kritik bir risk olarak kabul edilir. Çünkü sunucu tarafından kayıt altına alınır ve o sayfa her çağırıldığında kod çalışır.
  • DOM XSS: JS Framework’leri, single-page uygulamaları, ve API’lerde dinamik olarak tanımlı saldırganın kontrol edebileceği verilerdir. 

Nasıl korunulur?
Gelen verilerin doğrulanması, HTML çıktısındaki güvenilmeyen HTML isteğinden kaçınılması gereklidir. İçeriğe duyarlı encode işlemi uygulamak güvenlik riskini azaltacaktır.


A8. Insecure Deserialization
Bu zafiyet kullanıcıdan gelen güvenilmeyen zararlı inputun deserialization’u sonucu oluşuyor. Bu yüzden kullanıcıdan gelen verilerin kontrol edilmesi gerekmektedir.

Nasıl korunulur?
Serileştirilmiş nesneler üzerinde dijital imzalar gibi bütünlük denetimleri uygulanmalıdır. Obje oluşturulmadan önce tip kısıtlamaları uygulanmalıdır. Mümkün oldukça düşük ayrıcalıklı ortamlarda seri hale getiren kodun yalıtılması ve çalıştırılması şarttır
Log’lamak, sunucudan veya containerdan gelen giden seri ağ bağlantılarını izlemek veya kısıtlamak veya anomalilerde banlamak gereklidir. Aynı kullanıcıdan benzer seriler geliyorsa uyarı verilmeli ve banlanmalıdır.


A9. Using Components with Known Vulnerabilities
Bilinen birçok güvenlik açığı için önceden yazılmış açıkları bulmak kolay olmakla birlikte, diğer güvenlik açıkları özel bir açığın açılması için yoğun çaba sarf edilmesini gerektirir. 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.

Nasıl korunulur?
İşletim sistemini, servisleri, uygulamaları güncel tutmak, kullanılmayan servisleri kaldırmak gereklidir. Düzenli olarak yeni çıkan zafiyetleri kontrol edip uygun yamaların yapılması şarttır. Bileşenleri yalnızca resmi kaynaklardan güvenli bağlantılar üzerinden alın. Değiştirilmiş, kötü niyetli bir bileşen ekleme şansını azaltmak için imzalı paketleri tercih edin.


A10. Insufficient Logging and Monitoring
Yetersiz kayıt ve izlenme kullanımı hemen hemen her büyük olayın ana kökenidir. Yeterli izlemeye sahip olup olmadığınızı belirlemek için bir strateji penetration testinden sonra günlükler/loglar incelenmelidir. Testçilerin eylemleri, hangi zararları verebileceğini anlamak için yeterince kaydedilmelidir.
Başarılı saldırıların çoğu güvenlik açığı araştırmasıyla başlar. Bu gibi probların devam etmesine izin vermek, başarılı istismar olasılığını neredeyse% 100'e yükseltir.

Nasıl korunulur?
Tüm oturum açma işlemlerinin, erişim kontrolü başarısızlıklarının ve sunucu tarafı giriş doğrulama hatalarının, şüpheli veya kötü amaçlı hesapları tanımlamak için yeterli kullanıcı bağlamı ile günlüğe kaydedilebildiğinden ve gecikmiş adli analize izin vermek için yeterli bir süre boyunca tutulduğundan emin olun.
Merkezi bir log yönetimi çözümleri ile Logların kolayca tüketilebilir (?) bir biçimde oluşturulması gerekir. Şüpheli faaliyetlerin zamanında algılanıp yanıtlanacağı şekilde etkin izleme ve uyarı oluşturma yapılmalı.Yüksek değerli işlemlerin denetim takibinin olmasını sağlayın.


OWASP kaynaklarından yararlanarak derleyen ve çeviren
Esma Uysal - Workcube Senior Developer
 

Geri Bildirim

Bu içeriği faydalı buldunuz mu?