Güvenli Yazılım Geliştirme İpuçları
Teknolojinin her alanda kendini geliştirmesiyle birlikte, siber tehditler hayatımızın her alanında karşımıza çıkar hale geldi.
Hayatımızın her alanında, internete bağlanan yada başka cihazlarla iletişim kuran (bluetooth bile olabilir) cihazlar kullanıyoruz. Tabiki firmalarda ellerinden geldiğince bu teknolojiyi her alanda kullanmaya başladılar. Bunun sonucunda internete bağlanan akıllı buzdolaplarımız bile oldu :)
Günümüzde saldırganların en büyük amacı veriye ulaşmak oluyor. Üstelik veriye ulaşmak için her zaman bir sunucuya erişmesine veya yazılımı hacklemesine de gerek yok.
Örnek vermek gerekirse, bir kahve dükkanında otururken halka açık bir wifi ağına bağlandığınızda ne kadar güvendesiniz? Küçük bir man in the middle attack ile saldırganın gerçekleştirdiğiniz tüm trafiği izleme, trafiğinizi yönlendirme/değiştirme veya trafik üzerinden geçen verilerinizi ele geçirme şansı olduğunu biliyor muydunuz? (Bu tarz ağlara bağlanıyorsanız sonrasında vpn ile daha güvenli bir networke bağlanmak bu tarz saldırılardan sizi korumaya yardımcı olacaktır.)
Teknolojideki gelişmeler ve internete erişimin artık bir lüks olmaması, son kullanıcılar olarak bizim de işimize geliyor. Tek tuşla verilen siparişler, hızlı para transferleri, parmak izi okuma, yüz tanıma ….
Hepsinin ortak noktası aslında verilerimizi işliyor/saklıyor olmaları. Buda “verilerimizi güvenli bir şekilde korunan sistemlere veriyor muyuz?” sorusunu aklımıza getiriyor.
Peki developerlar olarak nasıl daha güvenli yazılım geliştirebiliriz, işte bir kaç ipucu :
DMZ ve Secure Zone Ayrımı:
Bu kısım aslında hem sistem-network, hem de uygulama mimarisini ilgilendiren bir konu.
Temel olarak DMZ (Demilitarized Zone) uygulamanızın internetten veya güvensiz kaynaklardan (3rd party) istek aldığı fiziksel veya mantıksal bir network ağıdır. Uygulamanızın önünde duran katmanlardan (firewall/loadbalancer) geçen istek ilk olarak bu zone tarafından karşılanır. Bu zone ciddi bir saldırıda, kaybedeceğiniz ilk zonedur.
Demilitarized Zone askeri bir terimdir ve bölgede hiçbir askeri faaliyet yapılmayacağı anlamına gelir. Aynı mantık geliştirdiğimiz uygulamalar içinde geçerli buraya kurulmuş uygulamaların hiçbir şekilde iş kuralları veya database iletişimi yapmıyor olması gerekli. Bu zoneda kurulu uygulamanızın görevi karşıladığı isteği, Secure Zone’a iletmektir. Bu sayede DMZ’de bulunan uygulamanız sadece diğer uygulamaların kontratlarını içereceği için, ele geçirilmesi halinde saldırganlara çok fazla bilgi vermemiş olacak.
Secure Zone, internete veya 3rd partylere direk olarak açık olmayan internal network ağınızdır. Secure Zone, genelde DMZ zone’u veya diğer internal servisler tarafından iletilen istekleri karşılar ve asıl iş kurallarının işletildiği ortamdır. Genellikle DMZ ve Secure Zone arasında da bir firewall bulunur.
DMZ/Secure Zone arasında iletişim kuran servisler arasına authentication/authorization koymak güvenliği bir seviye daha arttıracaktır. Bu sayede DMZ ortamına bağlanan birisi tarafından Secure Zone’da bulunan uygulamalarınıza direk istek yapılmasını engellemiş olursunuz.
DMZ ile Secure Zone arasındaki iletişim protokolünün encrypted olması (TLS gibi), verilerinizin man in the middle attacklardan korunmasını sağlayacaktır.
Containerization’ın çok popülerleştiği, herkesin internal cloud ortamını kurmaya başladığı bu zamanlarda bu ayrıma dikkat etmek ve bu policyleri tanımlayabiliyor olmak önemli. Kubernetes’in internete açık bir ortamınıza Secure Zone’da olması gereken bir applicationınızı kurmasını istemezsiniz değil mi? :)
Continuous Delivery ve Code Review
Code Review hem kaliteli uygulama geliştirilmesini, hem de güvenlik açıklarının tespit edilmesi açısından önemli bir yere sahiptir. Code review aynı zamanda junior developerların hatalarını görmesi ve production öncesinde oluşabilecek problemlerin önlenmesini sağlayacaktır. Genelde kodu yazan kişiden farklı bir developer’ın kodu review etmesi beklenir.
Review edilen kodun bir build server tarafından (Jenkins, Teamcity, GoCD v.b.) derlenip binary paketlerin oluşturulmasını, kodun productiona hep aynı kaynaktan gitmesini sağlayacaktır. Build serverınızda derlenen her uygulama için unit testlerin, otomasyon testlerinin ve kod kalitesinin ölçüldüğü adımların (sonar v.b.) olması production öncesinde kalite kontrolü yapmanıza yardımcı olacaktır.
Review için upsource gibi bir tool kullanabilirsiniz. Biraz bütçeniz varsa uygulama kodunu statik kod analiz toollarından geçirmek, işinizi güvenlik anlamında kolaylaştıracaktır. Ayrıca periyodik olarak uygulamalarınıza penetrasyon testi yapılması, toolların ve reviewerların gözünden kaçan bulguları tespit etmenize yardımcı olacaktır. Eğer review kısmı çok maliyetli geliyorsa uygulamalarınızın önüne bir WAF modülü (web application firewall) koymanız en bilinen güvenlik zaafiyetlerinden korunmanız için yardımcı olacaktır.
OWASP TOP 10
OWASP (Open web application security project) dünya çapında hizmet veren ve uygulamaların security anlamında en çok açık verdiği konuları derleyip toplayan bir topluluk. Güncel top 10 listesine buradan erişebilirsiniz. Bu liste içerisindeki tüm açıkların kapatılması çok önemlidir. Bana sorarsanız bu liste içerisinde en tehlikeli açıklar Injection ve XSS’dir. (Hepsi önemli unutmayın.)
Injection denilince aklımıza sql injection gelebilir ancak liste çok daha büyük (SQL, LDAP, XPath, or NoSQL queries, OS commands, XML parsers, SMTP headers, expression languages, and ORM queries) injectiondan korunmanın en basit yöntemi input verisinin validationından geçiyor. Uygulamanızı geliştirirken input olarak aldığınız veriyi (trusted bir sourcedan bile geliyor olsa) mutlaka validationdan geçirmeniz ve veri beklediğiniz kriterlerde değilse akışınıza devam etmemeniz uygulamanızı pek çok saldırıdan koruyacaktır.
Web uygulamalarının ve javascript frameworklerinin, bu kadar popüler olduğu bir dönemde hem uygulama verisini, hem de son kullanıcıyı etkileyebilecek en tehlikeli açıklardan birisi XSS’dir. Saldırgan site üzerinden oluşan network akışını (burp, fiddler v.s.) takip edip serverdan gelen ve server’a giden verilerle kendi scriptlerini yazarak bunu sitenize inject edebilir.
Bir sitenin mesaj girme/görüntüleme kısmında XSS açığı olduğunu varsayalım saldırgan şu şekilde bir script yazabilir. “Girdiğim tüm içerikleri sil”, “Tüm arkadaşlarımın listesini getir”, “Gelen arkadaş listemdeki herkese bu scripti mesaj olarak gönder”. Site üzerinde bu mesajı alan ve görüntüleyen herkes, kendi girdiği tüm içerikleri sildikten sonra kendi arkadaş listesine aynı scripti yollayacak. Tam bir virüs. Neler olduğunu anlamadan bir saat içerisinde sitenizdeki içeriğin büyük bölümünü kaybetmiş olabilirsiniz.
Günümüzde pek çok framework output encoding veya input validation ile xss’in önüne geçiyor ama dikkatli olmazsanız yada bir yerde bile manuel olarak bu korumaları disable etmeniz durumunda başınıza büyük dertler alabilirsiniz. Özellikle dış kaynaklardan aldığınız ve html içeriğini gösterdiğiniz yerler varsa, xss açığının olup olmadığını kontrol etmeniz ve sürümünüzü kontrol sonrasında yaygınlaştırıyor olmanız bu açığa yakalanmamak için iyi bir önlemdir.
XSS ile çok değişik saldırılar gerçekleştirilebilir. Kullanıcılara ait veriler çalınabilir, uygulama verisi bozulabilir, hatta site kullanılamaz hale getirilebilir.
Log/Metrik Monitoring ve Alarm
Genelde developerlar olarak log ve metrikleri uygulamada oluşan problemleri tespit etmek için kullanırız. Uygulamanızda log veya metrik koymak için aspect oriented programming’e (AOP) göz atmanızı öneririm. AOP, temel olarak uygulamanın genelinde yapılması gereken işleri farklı bir layera taşıyıp temel iş kurallarından soyutlamanızı sağlar. Uygulamanızın iş kuralları katmanından Logging, Cache, Authentication, RequestValidation ve ExceptionHandling, Idempotency gibi kavramları AOP ile soyutlayabilirsiniz.
Loglarınızı merkezi bir sisteme (elasticsearch, splunk v.b.) gönderip buradan loglarınıza alarmlar tanımlayabilirsiniz. Bu alarmlar beklemediğiniz iş kuralı hatalarını yada beklenmeyen sistem hataları için alarm üretmeniz, sistemde neler olduğundan anlık olarak haberiniz olmasını ve buglara hızlı müdahale edebilmenizi sağlayacaktır.
Uygulamanızın karşıladığı istek sayısına ve ürettiği log boyutlarına bakarak gelen tüm istekleri loglayıp loglamamaya karar verebilirsiniz çok yoğun istek alan uygulamalarda herşeyi loglayamayabilirsiniz. Bu tarz durumlarda metriklerin gücünden faydalanmaya başlıyoruz. Daha minimal datayla prometheus/grafana/alertmanager kullanarak aynı esnekliği sağlayabilirsiniz.
Peki bu işin security ile ne ilgisi var dersek anomali tespitleri diyebiliriz. Birisi siteniz üzerinden dark web’de bulduğu kredi kartlarını deniyor olabilir yada bir başka sitenin user database’ini eline geçirmiş ve aynı kombinasyonları, sitenizde de login olmak için deniyor olabilir. Bu tarz istekler için oluşturacağınız alarmlar, durumun anlık olarak farkında olmanızı sağlayıp buna göre bir aksiyon almanıza fırsat verecektir.
Loglama yaparken password, kullanıcıya ait özel bilgiler (anne kızlık soyadı, TCKN ) veya uygulamanız için kritik olan verileri (connection string v.b.) loglamıyor yada maskeliyor olmanız uygulama ve veri güvenliğini sağlayacaktır. Özellikle KVKK ile birlikte kişisel verileri loglamamak isteyebilirsiniz. (AOP burada da çözüm için yardımcı olacaktır)
İyi bir log ve metrik sistemi, geliştiricilerin üretim ortamına bağlanma ihtiyacını da ortadan kaldırmayı mümkün kılacaktır.
Salt Kullanımı, Memoryde Saklanan Kritik Veriler ve Uygulama Konfigürasyon Yönetimi
Bir veriyi hashlerken salt kullanılmaması, verinin (özellikle verinin tipi biliniyorsa, kredi kartı, şifre gibi) açık haline hashcat gibi bir uygulamayla çok kolay bir şekilde ulaşılmasına sebep olacaktır.
Uygulamanız açıldığında kritik verileri statik olarak memory’de güvenli bir şekilde saklamanız ve ihtiyacınız olduğunda kullanıyor olmanız doğru bir yöntem olacaktır. Eğer veriyi memory’de saklamanız gerekiyorsa şifreleyip sadece ihtiyacınız olduğunda memory’deki kopyasının şifresini çözerek sürecinizi yürütmeye çalışın. Yinede memory’i korumak biraz zor çünkü memory’nin dumpını alan birisi, dump’ın alındığı anda kritik verinin açık hali o anda memory’de varsa, veriye ulaşabilir durumda olacaktır. Bu sebeple mümkün olduğunca memory üzerinde kritik veriler tutmamaya çalışın.
Uygulamanın konfigürasyon yönetimini, kullandığınız platforma göre şifreli bir şekilde saklamanız, uygulamanız için kritik olan verilere dışarıdan erişimi engellemenize yardımcı olacaktır. Özellikle dosya üzerinde saklanan konfigürasyonlarda bu yöntem işe yarayacaktır. Consul gibi konfigürasyon yönetiminede izin veren bir araç ile sunucu üzerinde duran konfigürasyon dosyalarından tamamen kurtulabilirsiniz.
Özetlemek gerekirse güvenlik için alınması gereken pek çok önlem var burada sadece bir kaç önemli noktadan çok kısaca bahsetmeye çalıştım. Şu kısmı unutmamak gerekiyor yaptığımız herşeyi sadece saldırganların işini zorlaştırmak için yapıyoruz. %100 güvenli bir sistem kurmak ne yazıkki mümkün değil. Dünyaca ünlü yazılımlarda bile çok kritik buglar çıkabiliyor (Openssl’de çıkan heartbleed bug’ı, neredeyse tüm wifiların kullandığı WPA2 protokolünde çıkan krack bug’ı gibi)
Zorlu bir dünyanın içerisindeyiz ayakta kalmak için dikkatli olmamız gerekiyor.
