- 13 Mar 2023
- 2,168
- 1,460
Merhabalar TurkHackTeam Ailesi Bugun Sizlerle
Temel Bi Hacker'in Bilecek Zafiyet Kapsamlarini Anlatacagiz.
Hadi Konumuza Gecelim
OWASP Nedir?
OWASP açılımı, Open Web Application Security Project olan OWASP Türkçeye Açık Web Uygulama Güvenliği Projesi olarak geçmiştir. OWASP, web uygulama güvenliği alanında makaleler, metodolojiler, dokümantasyon, araçlar ve teknolojiler üreten ve kar amacı gütmeyen bir topluluktur.
OWASP TOP 10 (2021) Nedir?
OWASP Top 10, birkaç yılda bir yayınlanan en yaygın 10 web uygulama güvenlik açığının listesini yayınlar. OWASP, açıkladığı Web uygulama güvenlik açıklarının risklerini, etkilerini ve karşı önlemlerini de beraberinde yayınlar
2020’nin En İyi 10 OWASP Güvenlik Açığı:
- Enjeksiyonlar (Injection)
- Bozuk Kimlik Doğrulama (Broken Authentication)
- Hassas Verilerin İfşası (Sensitive Data Exposure)
- XML Harici Varlıkları (XXE)
- Erişim kontrolü ihlali (Broken Access Control)
- Yanlış güvenlik yapılandırmaları (Security Misconfiguration)
- Siteler Arası Komut Dosyası (XSS)
- Güvensiz Serileştirme (Insecure Deserialization)
- Bilinen güvenlik açıkları olan Bileşenleri kullanma (Using Components with Known Vulnerabilities)
- Yetersiz günlük kaydı ve izleme (Insufficient Logging & Monitoring)
1. Broken Access Control
Bozuk Erişim Kontrol
güvelik açığı, izni olmayan bir kullanıcının gizli bilgileri görme ihlalidir. Access control, hangi kullanıcıların nereye erişip nereye erişemeyeceğini kontrol etmektedir. Broken access control ise bunun ihlal edilmesi anlamına gelmektedir. Bir kullanıcı istemediğimiz bir veriyi görebilir, düzenleyebilir hatta silebilir.
Uygulama içerisinde belirli fonksiyonlara erişmek için kullanıcı rolleri tanımlarız. Bu roller, Anonymous user, visitor, emloyee, content contributor, administrator veya developer olabilir. Broken access control, bir kullanıcının bu rollerin dışında yetki kazanarak farklı bir rol gibi davranmasıdır. Bu yolla, başka kişilere ait hassas ve gizli bilgilere erişim sağlayabilmektedir.
Gerçek hayattan bir örnek verirsek; insan kaynakları departmanından birinin, performans çıktılarını veya gizli bir bilgiyi printer da unutması olabilir. Benzer şekilde, insan kaynakları departmanı gizli bir bilgiyi departmanındaki birine email atmak isterken, yanlışlıkla email adresini farklı girerek bu gizli bilgi yanlış bir kişiye göndermesi olabilir. Bu durumların önüne geçmek için gerçekten kimin neye yetkisi olduğunu tekrar tekrar kontrol etmeliyiz.
2. Cryptographic Failures
Saklanan veya taşınan verinin güvenlik ihtiyaçlarına karar verilmesi son derece önemlidir. Örneğin, şifre, kredi kartı numarası, sağlık bilgileri, kişisel veriler, ve gizli iş bilgileri extra güvenlik ihtiyacına sahip olabilir. Verinin gerçekten güvenlik ihtiyacı varsa bu durumda veriyi encrypt ederek şifreleyebiliriz. Bu sayede, bilginin anlamlı bir şekilde okunmasının önüne geçmiş oluruz.
Bu tür ekstra güvenlik adımı uygulamak istediğimizde izleyeceğimiz adımlar; Birincisi, eğer hassas veriyi saklamak zorunda değilseniz, saklamayınız. İkincisi, eğer hassas veriyi saklamanız gerekiyorsa veriyi hem saklarken (at rest) hemde taşırken (in transit) encrypt ediniz. Üçüncüsü, veriyi encrypt ederken iyi bilinen güçlü encrypt algoritmalarını kullanınız.
3. Injection
Uygulama veriyi girdi (input) olarak kabul ederken, bu verinin talimat (instruction) olarak işlenmesine injection denilmektedir. Düşmanca (hostile) veriler kullanıldığında, uygulamamız bu saldırılara savunmasız (vulnerable) kalabilir.
Gerçek yaşam örneği olarak, bir köpeğimiz olsun ve ismine otur (sit) diyelim. Bu durumda, köpeğimize otur diye seslendiğimizde köpek ne yapacağını bilemeyecektir. Çünkü bu bir otur komutumu yoksa köpeğimizin ismini mi çağırıyoruz anlamlandıramayacaktır. Injection da benzer şekilde gerçekleşmektedir. Uygulamamız kullanıcı girdilerini yanlış yorumlayarak bu güvenlik açığına maruz kalmaktadır. Kullanıcı girdi içerisine kötü niyetli (malicuous) bir kod enjekte ederek (inject), uygulamamızın o girdiyi bir talimat (instruction) olarak algılamasını sağlayabilir.
Cross Site Scripting
bir tür injection yöntemidir. Uygulama, kullanıcı girdisini nötralize edemez (neutralize). Girdinin güvenli (safe) veya meşru (legitimate) olmasını ve uygun formatta olmasını doğrulayamama durumudur. Bu durumu önlemek için girdiyi kontrol etmeliyiz. Örneğin, kullanıcı tarih bilgisi giriyorsa, girilen tarih bilgisine ait formatı kontrol etmeliyiz eğer uygun değilse validasyon hatası dönmeliyiz. Benzer şekilde sql injection ile veri tabanında injection da yapılabilir.
4. Insecure Design
Tasarım ve mimari kusurlarla (flaw) ilgili risklere odaklanmaktadır.
Hata mesajları
geliştirme fazında çok faydalıdır ancak bu kodlar production’a gönderilirken gereksiz hata mesajları temizlenmelidir. Çünkü içerisinde hassas verileri de içerebilmektedir. Bu hassas mesajları kötü niyetli aktörler rahatlıkla kullanabilmektedirler. Düz metin (plain text) şifreleri de aynı şekilde insecure design kusurudur.
5. Security Misconfiguration
Eğer uygulamanız güvenlik konfigurasyon süreçleriyle uyumlu (concerted) ve tekrar edilebilir (repeatable) değilse, uygulamanız savunmasız (vulnerable) olabilmektedir. Örneğin, bisiklet sürerken kaskınızı başınıza değilde bisikletin dümenine asmışsanız, bu güvenli bir yöntem değildir. Kaskı başınıza takarak bisiklet sürüyorsanız o zaman güvenli diyebilirsiniz.
Uygulamanızın konfigurasyonları katılaştırılarak (hardened) güvenli bir şekilde yapılandırılmalıdır. Örneğin, evden çıkıp kapıyı kitlememiş olmanız veya arabaya binip emniyet kemerini takmamış olmanız security misconfiguration konusudur. Telefonunuza şifre koymamanız veya default olanı değiştirmemeniz, uygulamayı güncellememeniz, gereksiz servis veya özellikleri açmanız da security misconfiguration konusudur.
Security misconfiguration belirlemek için izlenecek yollar; Birincisi, güvenlik için gerekli her ayar ve konfigurasyonu ölçmek ve belirlemek gerekmektedir. İkincisi, Center for Internet Security (CIS) rehberini kullanmalıyız. Üçüncüsü, ideal olarak CIS rehberini uygulamayı katılaştırmalıyız. Gerçek
te ise bu zafiyeti engellemek için, organizasyonunuz için risk tolerans ve gereksinimlerinizi adreslemelisiniz.
6. Vulnerable and Outdated Components
Eğer uygulamanız içerisindeki bileşenlerin versiyonlarını bilmiyorsanız, o bileşen savunmasız, desteksiz (unsupported) veya tarihi geçmiş (out dated) olabilir. Bu durumda sizin uygulamanızın o bileşene bağımlılığı olduğu için uygulamanız da savunmasız kalmış demektir. Ayrıca, uygulamalarımız içerisinde açık kaynak kodlu bileşenler kullanabiliriz ve bu bileşenlerin bazı versiyonlarında güvenlik açıkları olabilir. Bu güvenlik açıkları, uygulamamızı otomatik olarak savunmasız bırakacaktır.
Bu sorunlardan kaçınabilmek için; öncelikle bütün varlıklarımızı(assets) bilmemiz gerekmektedir. İkincisi, her bir bileşenin savunmasız olup olmadığını bilmeliyiz ve proaktif bir şekilde test yapmalıyız. Üçüncüsü, tarihi geçmiş bileşenlerimizi güncellemeliyiz ve varsa güvenlik için patch atmalıyız.
Aslında, bu sorun teknik bir problem değildir, kişi ve süreç problemidir. Bu nedenle, tekrar eden varlık envanter (inventory) süreçlerimizi güçlendirmeliyiz (robust).
7. Identification and Authentication Failures
Kimlik doğrulama saldırılarına karşı, kullanıcı kimliği doğrulama ve oturum yönetimi önemli bir savunma aracıdır. Gerçek yaşam örneği olarak, bir yolcu uçağa binmek istediğinde kimlik doğrulamasından geçer ve o kişinin iddia edilen (claimed) kişi olup olmadığı doğrulanır ve uçağa alınır. Bunun için kimlik üzerindeki fotoğraf ile aynı kişi olup olmadığı kontrol edilebilir. Kişi fake bir kimlik yapmışsa peki bunun da doğrulanması gerekmektedir
Benzer bir şekilde, kötü niyetli bir kişi web sitenizin fake bir versiyonunu yapmışsa ve kullanıcıları kendine yönlendirerek kullanıcı bilgilerini alıyorsa. Bu durumda, sizin kullanıcının
gerçekte o kişi olup olmadığını telefona kod göndermek gibi farklı bir yolla doğrulamanız gerekmektedir.
Diğer bir ihlal ise kullanıcının oturumunu halka açık bir yerde açık unutması ve başka bir kişinin aynı bilgisayarı kullanarak o kişinin bilgilerine erişebilmesidir.
8. Software and Data Integrity Failures
Yazılım geliştirme ortamında otomasyon olarak kullandığımız güvenilir olmayan CI/CD pipeline potansiyel risk taşıyabilir. Bir çok uygulama otomatik güncelleme fonksiyonuna sahiptir. Bu otomatik güncellemenin nereden yapıldığı ve yeterli doğrulama yöntemine sahip olup olmadığı önemlidir. Çünkü CI/CD pipeline içerisine istenmeyen yeni bir iş akışı eklenebilir.
Örneğin, bir çikolata fabrikası düşünün. Ham made (raw material) alındıktan sonra bu ham maddeler otomatik olarak belirli süreçlerden geçirilerek çikolata üretilmektedir. Eğer ham madde kalitesiz ise veya iş süreçlerine yanlış bir işlem daha eklenmiş ise, bu durumda istenilen kalitede ve şekilde bir çikolata üretilemez. Benzer şekilde, kötü niyetli kişiler otomatize edilmiş CI/CD pipeline içerisine bir saldırıda bulunabilir ve kendi işlemini araya ekleyebilirler. Bu durumda sizin uygulamanız da savunmasız hale gelmiş olur.
Mesela, bir nesneyi serialize ederken veya deserialize ederken otomatik bir şekilde yapabiliriz. Bu işlem arasına farklı bir algoritma dahil edilirse bu durumda serialize edilen işlemi tekrar deserialize edemeyiz ve sistemimiz hasar görmüş olur.
9. Security Logging and Monitoring
Monitor ve loglama yapılmadan ihlaller (breaches) tesbit edilemez. Örneğin, evinizin veya arabanızın kapısı her açıldığı ve kapandığında size bilgi gelse, bu durumda hırsızları durdurma ve yakalama şansınız çok yüksektir.
Bu ihlalin oluşmaması için çalışan bir organizasyon vardır. UK National Cyber Security Centre, güvenlik amacıyla gözlemleme ve loglama işlerini hangi durumlarda yapmamız gerektiğini belirtmektedir. Bu durumlar; Hangi dosya indirildi ve gözlemlendi? Herhangi bir yanlış kullanıcı doğrulaması yapıldı mı?, Yenilerde kim login oldu? Beklenmeyen zamanda veya beklenmeyen bir yerden kullanıcı doğrulaması oldu mu?
Loglama, monitoring ve alarm mekanizmaları sistem sızmalarını tesbit etmek ve güvenlik ekibini bu doğrultuda uyarmak için kullanılmaktadır. Bu sayede, güvenlik ekipleri, saldırganın sisteme daha fazla hasar vermesini engelleyerek saldırganın kimliğini belirleyebilirler.
10. Server Side Request Forgery
SSRF kusurunda (flaw), saldırgan hazırlanmış (crafted) bir isteği beklenmeyen bir hedefe göndermeye zorlar. Saldırgan isteklerini sanki madur kimse’nin (victim) sunucusu gibi rol yaparak gönderir. Çünkü, sunucu güvenilir bir varlıktır. Bu saldırı, hassas ve yönetimsel fonksiyonlara erişmekle sonuçlanabilir. Bu saldırıdan kurtulmanın en önemli yolu meşru (legitimate) dış kaynaklardan sadece bazı ip addreslerine ve host isimlerine izin verirken diğerlerine izin vermemektir.
Owasp Top 10'Ait Kaynaklar
Link 1
Link 2
Link 3
Link 4
Link 5
Son düzenleme:
