OWASP, web uygulama güvenliği alanında makaleler, metodolojiler, belgelendirme, araçlar ve teknolojiler üreten çevrimiçi bir topluluk olan Açık Web Uygulaması Güvenlik Projesi (Open Web Application Security Project) anlamına gelir.

OWASP’a ait dokümanlar ve araçlar tüm dünyadaki herkesin kullanımına açık ve ücretsizdir. OWASP’ ın hiçbir özel şirket ve kuruluşla herhangi bir bağı yoktur. Çalışmalarını tamamen insanların ihtiyaçlarını gidermek üzere yürütmektedir. OWASP’ın web sitesinde, web uygulamalarındaki zafiyetleri, bu zafiyetlerin nasıl oluştuğunu, hangi açıklıklardan kaynaklandığını, bu zafiyetlerin nasıl exploit edilebileceğini ve bu zafiyetlerin nasıl önlenebileceği ile ilgili ayrıntılı dokümanlar da mevcuttur. OWASP, birçok firma ve web uygulama sızma testleri ile ilgili çalışmalar yapan kişilerden bilgiler toplayarak ve bu bilgileri analiz ederek o yıla ait en riskli 10 güvenlik zafiyetinin istatistiğini çıkartmakta ve ücretsiz olarak sunmaktadır. OWASP topluluğunun her üç ya da dört senede bir yenilediği OWASP Top 10 ismiyle o yıla ait en riskli güvenlik zafiyetlerini listeledikleri Top 10 listesi hazırlamaktadır. OWASP İlk 10, en yaygın 10 uygulama güvenlik açığının listesidir. Ayrıca risklerini, etkilerini ve karşı önlemlerini de gösterir. [3]

Bu belge, genel olarak güvenli kod geliştirme uygulamaları üzerine bilgi vermek amacıyla hazırlanmıştır.

OWASP tarafından yayınlanan “OWASP Secure Coding Practices Quick Reference Guide” ve “Uygulama Güvenliği Doğrulama Standardı 4.0” çalışmaları referans alınarak hazırlanmıştır.

1.Input Validation (Girdi Doğrulama)

En yaygın web uygulaması zafiyetleri, istemciden veya ortamdan gelen girdiyi kullanmadan önce uygun bir şekilde doğrulamamaktan ortaya çıkmaktadır. Bu doğrulamanın yapılmaması, XSS, SQL enjeksiyonu, dosya sistemi saldırıları, yorumlayıcı enjeksiyonları, Unicode saldırıları ve bellek taşmaları gibi en bilinen zafiyetlerin ortaya çıkmasına neden olmaktadır.

Kabul edilen verilere ait bir beyaz liste ile ve güçlü veri türü kontrolleri ile yapılmış girdi doğrulama kontrolleri, tüm enjeksiyon saldırılarının %90’dan fazlasını ortadan kaldırabilir. Buna ek olarak girdiler üzerinde yapılacak uzunluk ve izin verilen aralık kontrolleri bu riski daha da azaltacaktır. Güvenli girdi doğrulama altyapısı; uygulama mimarisi tasarlanırken, müşteri ile tasarım yapılırken, kodlama anında, birim ve entegrasyon testleri yapılırken oluşturulmalıdır.

• Tüm veriler sunucu tarafında doğrulanmalıdır. Bu konuda sıkça yapılan hatalardan biri, doğrulama işlemlerinin sadece istemci (client-side) tarafında yapılmasına güvenilmesidir. Kullanıcı tarafında yapılan doğrulamaların kolaylıkla atlatılabileceği unutulmamalıdır. Bu sebeple, her türlü doğrulama adımı sunucu tarafında yapılmalıdır.
• Uygulamalarınızdaki tüm girdi noktaları (kullanıcının gönderdiği http isteğindeki başlık bilgileri, parametreler ve başka bir servisten alınan veriler gibi) kontrol edilmelidir. Alınan girdiler, işletilmeden önce mutlaka doğrulanmalıdır.
• Girdi doğrulaması beyaz liste yaklaşımı ile kontrol edilmelidir. Girdi doğrulamasında, beyaz liste (whitelist) ve kara liste (blacklist) olmak üzere iki farklı yaklaşım vardır. Beyaz liste yaklaşımı, sadece istenilen girdilere izin verilmesidir. Kara liste yaklaşımı ise, istenilmeyen girdilerin engellenmesidir. Kara liste  olarak yapılan kontroller atlatılabilmektedir.

Örneğin, PHP bir web uygulamasında dosya yükleme fonksiyonu olduğunu düşünelim. Kullanıcılar tarafından, JPG ve PNG gibi resim dosyalarının yüklenebilmesini istiyoruz. Eğer ki, uzantı kontrolü kara liste yöntemi ile yapılmışsa (.php, .exe dosyaların engellenmesi gibi) saldırganlar tarafından atlatılacaktır. Yüklenecek olan .php5 uzantılı dosya ile sunucu, saldırganlar tarafından ele geçirilebilir durumda olacaktır.

Örnekte de anlatıldığı üzere, kara liste olarak yapılan kontroller er ya da geç atlatılacaktır Bu sebeple, sadece istediğimiz ifadelere izin verilecek şekilde (beyaz liste yaklaşımı ile) girdi denetimi sağlanmalıdır.

• Girdi doğrulaması yapılırken, verinin tipi, aralığı ve uzunluğu kontrol edilmelidir.
• Eğer potansiyel olarak tehlikeli olabilecek karakterlerin alınması gerekiyorsa (Örneğin: < > “ ‘ % ( ) & + \ \’ \” gibi) kodlama gibi ek denetimler uygulanmalıdır.

2.Output Encoding (Çıktı Kodlama)

Kullanılan yorumlayıcıya (interpreter) olabildiğince yakın bir yerde çıktı kodlama yapılması uygulamanın güvenliği için kritik rol oynamaktadır. Çıktı kodlama kalıcı bir çözüm sunmamaktadır ancak anlık kullanım için, kullanıcıdan alınan verinin, doğru çıkış bağlamında (output context) güvenli şekilde işlenmesini (render) sağlamak için kullanılır. Çıktı kodlama işleminin doğru şekilde yapılmaması güvenli olmayan ve zararlı kod enjekte edilebilir bir uygulama ile sonuçlanacaktır.

• Çıktıda kodlama uygulanması, Cross-Site Scripting (XSS) atakları için büyük önem taşımaktadır. Burada dikkat edilmesi gereken konu, verinin nereye basılacağına göre uygun encoding yönteminin uygulanmasıdır. XSS ataklarına çözüm sağlanabilmesi için context’e göre encode işlemi uygulanmalıdır.
• Birbirinden farklı context yapıları vardır. (HTML context, Javascript Context gibi) Gösterim aşamasından buna uygun olarak encode edilmelidir. Örneğin, kullanıcıdan alınan bir veri, “img” etiketinin “src” öz niteliğine girdi olarakta verilebilir ya da doğrudan HTML etiketleri içerisinde de gösterilebilir.
• Yorumlayıcı için güvenli olmayan tüm karakterler, encode işleminden geçirilmelidir.
• SQL, LDAP, XML sorguları için tüm güvenilmeyen veriler, sterile edilmelidir.

3. Authentication and Password Management (Kimlik Doğrulama)

Kimlik doğrulama, bir kişinin (veya bir şeyin) özgün olarak oluşturulması (tanımlanması) ve onaylanması işlemidir. Kimlik doğrulama bir kişi veya bir cihaz tarafından yapılan hak taleplerinin doğruluğunu kontrol eder. Kimlik doğrulama kimliğe bürünmeye karşı dirençlidir ve şifrelerin güvensiz hale geri dönüştürülmesini veya ele geçirilmesini engeller.

Kullanıcı adı ve şifre doğrulaması yüksek güvenlik sistemleri dışındaki en yaygın kimlik doğrulama biçimiydi. Çok faktörlü kimlik doğrulama (MFA) güvenlik çevrelerinde yaygın olarak kabul edilmesine rağmen nadiren kullanılırdı. Parola ihlallerinin sayısı arttıkça, kullanıcı adlarının gizli olduğu ve parolaların bilinmediği fikri savunulamaz hale geldi. Örneğin; NIST 800-63, kullanıcı adlarını ve bilgi tabanlı kimlik doğrulama (KBA) verilerini herkese açık bilgi olarak kabul eder. SMS ve e-posta bildirimlerini ise “kısıtlı” kimlik doğrulayıcı türleri olarak görür. Şifreleri ise önceden ihlal edilmiş (sızdırılmış) olarak kabul eder. Bu durum; bilgiye dayalı kimlik doğrulayıcıları, SMS ve e-posta kurtarma, şifre geçmişi, parola karmaşıklığı ve parola değiştirme kontrollerini işe yaramaz hale getirir. Bu kontroller her zaman faydasız olmuştur hatta çoğu zaman kullanıcıları birkaç ayda bir zayıf şifreler bulmaya zorlar.

• Herkese açık olmayan tüm sayfa ve kaynaklar, kimlik doğrulama arkasına alınmalıdır.
• Tüm kimlik doğrulama adımları, sunucu tarafında yapılmalıdır.
• Standartlara uygun kimlik doğrulama mekanizmaları kullanılmalıdır.
• Tüm kimlik doğrulama denetimleri için merkezi bir yapı kullanılmalıdır.
• Parolalar, salt (tuzlama) değeri kullanılıp, güçlü bir hashing algoritmasından geçirilerek, saklanmalıdır.
• Kimlik doğrulama hataları sonucunda, bilgi ifşasına yol açmayacak şekilde hata mesajlarının gösterilmesi gerekmektedir. Örneğin, kullanıcı adı doğru, parola yanlış olduğu durumda, “Parolanız hatalı…” şekilde bilgi vermek yerine, “Kullanıcı adı veya parolanız hatalı.” şeklinde bilgi açığa çıkarmayacak bir mesaj gösterilebilir.
• Diğer servislere erişim için kullanılan kimlik bilgileri şifrelenerek, güvenilir bir sunucuda saklanmalıdır. Kaynak kod içerisinde saklanması güvenilir bir yöntem değildir.
• Kimlik doğrulama bilgilerinin iletilmesinde, POST metodunu kullanılmalıdır. Hassas/önemli veriler, GET metodu üzerinden gönderilmemelidir. Bunun nedeni, GET metodu üzerinden gönderilen verilerin log dosyalarında (access.log, tarayıcı geçmişi) kayıt edilmesidir.
• Bilgi güvenliği standartlarına uygun bir şekilde parola politikası uygulanmalıdır.
• Kaba kuvvet (Brute Force) saldırılarını önlemek için koruma mekanizmaları kullanılmalıdır. (Örneğin, captcha gibi)
• Geçici bağlantılar ve parolaların geçerlilik süreleri olabildiğince kısa olmalıdır. Bir sonraki kullanımda geçici parolaların değiştirilmesine zorlanmalıdır.
• Önemli işlemler yapılırken, kullanıcıya bilgilendirme yapılmalıdır. (Örneğin, parola değişikliği gibi)
• Eski parolaların tekrar kullanılabilmesi engellenmelidir. (Örneğin, son iki parolanın aynı olamaması gibi)
• Belirli zaman dilimi içerisinde, parolanın değişikliği zorunlu kılınmalıdır. Kritik sistemlerde daha sık değişiklik yapılması önerilmektedir.
• Bir kullanıcı hesabının son aktiviteleri (başarılı, başarısız girişleri) bir sonraki başarılı girişinde kullanıcıya bildirilmelidir.
• Aynı şifreyi kullanarak birden fazla kullanıcı hesabına yönelik saldırıları tanımlamak için izleme sistemlerinin uygulanması önerilmektedir.
• İki aşamalı (2FA) doğrulama yöntemi kullanılmalıdır.

4.Session Management (Oturum Yönetimi)

Web tabanlı bir uygulamanın temel bileşenlerinden biri, uygulamayla etkileşim kuran bir kullanıcının durumunu kontrol ettiği ve koruduğu mekanizmadır. Buna “Oturum Yönetimi (Session Management)” adı verilmektedir. Bir uygulama ile bir kullanıcının arasındaki tüm etkileşim durumlarını yöneten denetimler kümesi olarak tanımlanabilmektedir.

• Kullandığınız framework’ün sunduğu oturum denetimleri kullanılmalıdır.
• Oturum kimliği oluşturma, güvenilir bir sunucuda yapılmalıdır.
• Oturum tanımlayıcıları, yeterince rastgele üretilmelidir.
• Cookie’lerin domain ve path bilgileri ayarlanmalıdır.
• Çıkış (Logout) işlemi yapıldığında, sunucu tarafında ilişkili oturum sonlandırılmalıdır.
• İş gereksinimine bağlı olarak, mümkün olduğunca kısa bir oturum haraketsizlik süresinin belirlenmesi önerilmektedir.
• Oturum etkinken bile kalıcı oturum açma işlemlerine izin verilmemeli, periyodik olarak oturum sonlandırması uygulanmalıdır.
• Oturumu açmadan önce bir oturum oluşturulduysa, başarılı bir şekilde giriş yapıldıktan sonra yeni bir oturum oluşturulmalıdır.
• Her başarılı kimlik doğrulama sonucunda, yeni bir oturum oluşturulmalıdır.
• Mümkünse, aynı kullanıcıya ait eş zamanlı oturum açılabilmesine izin verilmemelidir.
• Oturum tanımlayıcıları, URL’lerde, hata mesajlarında ve günlüklerde gösterilmemelidir.
• Cross-Site Request Forgery (CSRF) ataklarına karşı, güçlü ve rastgele bir token kullanarak koruma sağlanmalıdır. CSRF saldırısı, tarayıcının otomatik olarak cookie değerini eklenmesinden dolayı, başka bir site üzerinden oturumu açık olan kullanıcı adına işlemler yapılabilmesine olanak tanıyan bir güvenlik zafiyetidir.
• Cookie’lerde “Secure” ve “HTTPOnly” bayrakları işaretlenmelidir.
• Secure bayrağı, cookie’nin sadece güvenli bağlantılar üzerinden taşınmasını garanti altına alır. HTTPOnly bayrağı ise, javascript’in cookie’ye erişmesini engeller. Böylelikle, olası bir XSS atağına karşı cookie’nin ele geçirilmesinin önüne geçer.

5.Access Control (Erişim Kontrolü)

Yetkilendirme, kaynakların kullanımına yalnızca izin verilen kişilerin erişimine izin verme konseptidir. Doğrulanmış bir uygulamanın aşağıdaki yüksek seviye gereksinimleri karşılamalıdır  Kaynaklara erişen kişiler için geçerli kimlik bilgilerini bulundurur.  Kullanıcılar iyi tanımlanmış roller ve yetkiler ile ilişkilendirilmiştir.  Rol ve izin verisi, tekrar düzenlenmeye ve kurcalanmaya karşı korunmuştur.

• Sadece güvenilir sistem objeleri kullanılmalıdır. (Örneğin, erişim yetkisi kararlarını almak için sunucu tarafındaki oturum objelerinin kullanılması)
• Erişim yetkilerini kontrol etmek için uygulama genelinde tek bir bileşen kullanılmalıdır.
• Yapılan her işlem için sunucu tarafında, yetki kontrolü sağlanmalıdır.
• Uygulama üzerindeki korunaklı kaynaklar (bağlantılar, fonksiyonlar, nesneler vs.) sadece yetkili kullanıcılar tarafından erişilebilecek şekilde kısıtlanmalıdır.
• Eğer, durum bilgisinin kullanıcı tarafında saklaması gerekiyorsa, şifreleme ve bütünlük denetimleri, sunucu tarafında kontrol edilmelidir.
• Bir kullanıcının veya cihazın, belirli bir süre içerisinde gerçekleştirebileceği işlemler sınırlandırılmalıdır. İşlem sınırı, uygulamanın gereksinime bağlı olarak ayarlanmalıdır.
• Referer başlık bilgisi üzerinden asla yetkilendirme denetimi sağlanmamalıdır. Örneğin, “Referer: example.com/admin” gibi admin yolundan geliyorsa, çeşitli işlemlerin yapılmasına izin ver gibi bir kontrol uygulanmamalıdır. Referer başlık bilgisinin kolaylıkla manipüle edilebileceği unutulmamalı, bu sebeple de sadece ek kontrollerde kullanılmalıdır.
• Uzun süreli, kimliği doğrulanmış oturumlara izin veriliyorsa, ayrıcalıkların değişmediğin emin olmak için düzenli aralıklar ile kullanıcının yetkisi kontrol edilmeli ve söz konusu durum gerçekleşirse oturum sonlandırılarak, yeniden kimlik doğrulamaya zorlanmalıdır.
• Hesap denetimi uygulanmalı ve kullanılmayan hesaplar, devre dışı bırakılmalıdır.
• Uygulama, yetkilendirmenin sonlanması durumunda hesabın devre dışı bırakılmasını veya oturumun sonlandırılmasını desteklenmelidir.
• Servis hesapları ve harici sistemler ile bağlantıda olan hesaplar, mümkün olabildiğince en az yetkiye sahip olmalıdır.
• Uygulamanın, iş süreçlerini, veri türlerini ve erişim yetkilendirme ölçütlerini belgelemek ve erişimi uygun bir şekilde sağlayıp, kontrol etmek için erişim kontrol politikası oluşturulmalıdır.

6.Cryptographic Practices (Kriptografik Uygulamalar)

Tüm şifreleme modülleri güvenli bir şekilde hata vermeli ve bu hatalar doğru şekilde işlenmelidir.

• Rastgeleliğe (randomness) ihtiyaç duyulduğunda, uygun bir rastgele sayı üreticisi kullanılmalıdır.
• Anahtarlara erişim güvenli bir şekilde yönetilmelidir.
• Tüm şifreleme işlemleri güvenilir bir sunucuda yapılmalıdır.
• Tüm rastgele ifadelerin (sayılar, GUID’ler vs) tahmin edilemez olması amaçlandığından, şifreleme modülünün onaylanmış rastgele sayı üreteci kullanılarak, üretilmelidir.
• Uygulama tarafında kullanılacak olan tüm şifreleme ve hashing algoritmaları, güçlü ve standartlara uygun olmalıdır.
• Şifreleme anahtarlarının nasıl yönetileceğine ilişkin bir politika oluşturulmalıdır.

7. Error Handling and Logging ( Hata İşleme ve Kayıt)

Hata işleme ve kayıt altına almanın temel amacı; kullanıcılar, yöneticiler ve olayla mücadele ekiplerinden (incident response teams) yararlı aksiyonlar alabilmektir. Amaç çok kayıt tutmak değil, kaliteli ve gürültüden arındırılmış kayıtlar tutmaktır. Yüksek kalitedeki kayıtlar (loglar) genellikle hassas veriler içerecektir ve kişisel verilerin korunması ile alakalı yasalara uygun bir şekilde korunmalıdır. Bu durum ile alakalı aşağıdaki öneriler incelenebilir;

• Özel olarak istenmiyorsa hassas bilgi toplanmamalı ve kaydedilmemelidir.
• Kayıtlı bilgilerin güvenliği sağlanmalı ve veriler sınıflandırılarak korunmalıdır.
• Kayıtlar süresiz olarak saklanmamalı, saklanma süresi mümkün olduğunca kısa olmalıdır.
• Kayıtların içeriği ülkeden ülkeye değişmekle beraber hassas bilgiler içerebilir. Bu gibi durumlar, saldırganlar için çok cazip olmaktadır.
• Hata mesajlarında, sistem hakkında bilgi ifşasına sebep olabilecek durumlardan kaçınılmalıdır.
• Stack Trace ve debug hata mesajları kapatılmalıdır.
• Hata durumları ele alınarak, özel olarak hazırlanmış hata sayfaları kullanıcıya gösterilmelidir.
• Tüm günlük (loglama) denetimleri güvenilir bir sistemde yapılmalıdır.
• Güvensiz veriler içeren günlük dosyalarının, günlük görüntüleme arayüzünde veya yazılımda kod olarak yürütülemeyeceğinden emin olunmalıdır.
• Günlükler, sadece yetkili kişiler tarafında erişilebilecek şekilde kısıtlanmalıdır.
• Hassas bilgiler (oturum belirteçleri, parola bilgileri gibi) günlük dosyalarında saklanmamalıdır.
• Tüm giriş doğrulama hataları, kimlik doğrulama işlemleri (özellikle başarısız olanlar), erişim denetimi hataları, sistem hataları, yönetici işlemleri, TLS bağlantıları hataları ve şifreleme hataları gibi durumlar günlüklere kaydedilmelidir.
• Günlüklerin, bütünlüğü kontrol edilmelidir.

8.Data Protection (Veri Koruma)

Veri koruması için üç önemli unsur vardır: Gizlilik, Bütünlük ve Erişilebilirlik (İngilizce kısaltması CIA olarak bilinir). Bu standart, sıkılaştırılmış ve gerekli güvenlik önlemlerinin alınmış olduğu güvenli bir sistemde veri güvenliğinin sağlandığını varsayar. Uygulamalar, kullanıcılarının cihazlarının bir şekilde tehlikede olabileceğini varsaymak zorundadır. Bir uygulama, bilgisayar, telefon veya tablet gibi güvensiz cihazlar arasında veri alışverişi yapılması ve saklanması durumunda; verilerin şifrelenmesinden, kolayca elde edilememesinden ve değiştirilememesinden sorumludur.

Gizlilik Veriler iletimdeyken ya da depolandığında yetkisiz olarak erişilemez ve ifşa edilemez olmalıdır.

Bütünlük Veriler kötü amaçlı olarak oluşturulamaz, değiştirilemez veya yetkisiz olarak silinemez olmalıdır.

Erişilebilirlik Veriler yetkili kullanıcılar tarafından her an kullanılabilmelidir.

• Kullanıcılar, sadece görevlerini yerine getirebilecek yetkiler ve bilgiler ile sınırlanmalıdır. En az ayrıcalıklar ile çalışacak şekilde tanımlanmalıdır.
• Sunucu tarafında saklanan veriler dahi olmak üzere tüm hassas/önemli veriler, güçlü bir şifreleme algoritmasıyla şifrelenmelidir.
• Kullanıcı tarafında saklanacak olan hassas veriler, düz metin olarak veya güvensiz bir şifreleme algoritmasıyla saklanmamalıdır.
• Kullanıcı tarafından erişilebilen kod üzerinde, bilgi ifşasına sebep olabilecek yorumlar kaldırılmalıdır.
• GET metodu üzerinden, hassas/önemli veriler taşınmamalıdır.
• Hassas bilgiler içermesi beklenen form alanlarında, otomatik tamamlama özelliği devre dışı bırakılmalıdır.
• Hassas bilgiler içeren sayfaların, kullanıcı tarafında önbelleğe alınması devre dışı bırakılmalıdır.
• Uygulamadan veri dönen noktalar incelerek, iş akışına göre en az şekilde veri döndürülmesi sağlanmalıdır.

9.Communication Security (İletişim Güvenliği)

Tüm istemci iletişimleri yalnızca şifrelenmiş ve güvenli kabul edilen iletişim yolları üzerinden gerçekleştirilmelidir. Sunucu iletişimleri HTTP’den daha fazlasıdır. İzleme sistemleri, yönetim araçları, uzaktan erişim ve ssh, ara katmanyazılımı, veri tabanı, ana bilgisayarlar, ortak veya harici kaynak sistemleri gibi diğer sistemlere ve bu sistemlerden güvenli bağlantılar kurulmalıdır

• İletişim, SSL/TLS üzerinden sağlanmalıdır. HTTP üzerinden gönderilen veriler, düz metin (clear text) olarak taşınmaktadır. Bu durum, olası bir ortadaki adam saldırısında (MiTM) trafiğin okunabilmesine neden olacaktır. Bu sebeple, SSL/TLS ile şifrelenmiş bir şekilde haberleşme sağlanmalıdır.
• Kullanılan SSL/TLS sertifikasının, geçerli ve doğru alan adına sahip olması gerekmektedir.
• Başarısız SSL/TLS bağlantıları, güvensiz bağlantılara geri dönmemelidir. HSTS gibi başlık bilgileri kullanılarak, trafik SSL/TLS’e zorlanmalıdır.
• SSL/TLS sertifikaları, zayıf şifreleme ve hashing algoritmalarını desteklememelidir. (Örneğin, şifreleme olarak RC4 kullanılmaması yada imzalama için MD5 veya SHA1 kullanılmaması gibi)

10.System Configuration (Sistem Yapılandırması)

• Kullanılan tüm bileşenlerin, en güncel versiyonları tercih edilmelidir. Kullanımda olan sürümler için yayınlanan yamalar takip edilerek, sistemlere geçildiğinden emin olunmalıdır.
• Dizin listeleme kapatılmalıdır.
• Gereksiz tüm işlevler ve dosyalar kaldırılmalıdır.
• Uygulama üzerinde kullanılacak olan HTTP metotları belirlenerek, sadece izin verilen metotların kullanılması sağlanmalıdır.
• Dönen cevaplardan, işletim sistemi, web sunucu ve kullanılan framework sürümleri kaldırılmalıdır. (Örneğin, Server: IIS 7.5 veya X-Powered-By: PHP/7.2 gibi)
• Tüm bileşenlerin yer aldığı bir envanter oluşturulmalıdır. Bu envanterin takibi yapılarak, sürekli güncellenmesi sağlanmalıdır.
• Test ve production ortamları birbirinden ayrılmalıdır. Test ortamı, sadece yetkili kişiler tarafından erişilecek şekilde kısıtlanmalıdır. Test ortamlarının, production ortamlar kadar güvenli bir yapıya sahip olmaması nedeniyle yetkisiz kişilerin, bu ortamlara erişebilmesi büyük risk taşımaktadır.

11.Database Security (Veritabanı Güvenliği)

• SQL Injection ataklarına karşı, prepared statement yapısı kullanılmalıdır.
• Prepared Statement’ı kısaca özetlemek gerekirse, sorguyu ve sorguya dahil olacak verileri ayırır diyebiliriz. Şöyle ki, sorguya dahil olacak nesne, soru işareti “?” ile belirtilir. Ardından sorgu bu şekilde veri tabanına gönderilerek, hazırlanır. Kullanıcıdan gelen veri ile hazırlanan sorgu birleştirilir. Böylelikle, derlenmiş bir ifade ile kullanıcıdan alınan değer birleştirildiğinden dolayı SQL Injection ataklarının önüne geçilmektedir.
• Girdi doğrulaması ve meta karakterler üzerinde encoding işlemi uygulanmalıdır.
• Uygulama, veri tabanı üzerinde en az ayrıcalıklara sahip olmalıdır. Sadece, yapılması gereken işlemlere izin verilecek şekilde yetkilerin tanımlanması gerekmektedir.
• Veri tabanına erişim için güçlü kimlik bilgileri kullanılmalıdır.
• Veri tabanı bağlantı bilgileri, kaynak kod içerisinde statik olarak tanımlanmamalıdır.
• Eğer, uygulama ve veri tabanı aynı sunucu üzerinde çalışıyorsa, veri tabanı servisi dış dünyaya kapatılmalıdır. Sadece, localhost üzerinde çalışacak şekilde yapılandırılmalıdır. Genellikle, uygulama ve veri tabanı farklı sunucular üzerinde hizmet vermektedir. Bu durumda, uygulama sunucu ve veri tabanı sunucusu üzerinde IP kısıtlaması yapılarak, sadece uygulama sunucu üzerinden erişilmesi sağlanmalıdır.

12.File Management (Dosya Yönetimi)

• Kullanıcıdan alınan değerler ile dinamik olarak dosya gösterilmesi durumu mevcutsa, beyaz liste ile izin verilen dosya adları kontrol edilmelidir.
• Kullanıcılar tarafından yüklenebilecek dosya tipleri, beyaz liste yaklaşımı ile kontrol edilmelidir. (Örneğin, sadece JPG, PNG uzantılarına izin verilmesi gibi)
• Yüklenen dosyanın içeriği kontrol edilmelidir.
• Yüklenen dosyanın boyutu kontrol edilmelidir.
• Kullacılar tarafından yüklenen dosyalar, uygulama ile aynı sunucuda saklanmamalıdır. (Örneğin, CDN gibi teknolojiler kullanılabilir.)
• Dosyaların yüklendiği dizine, çalıştırma yetkisi verilmemelidir. Sadece, okuma yetkisinin verilmesi yeterli olacaktır.
• Tam dosya yolu, asla kullanıcıya gönderilmemelidir.
• Kullanıcılar tarafından yüklenen dosya adlarının, sunucu tarafında değiştirilmesi ek koruma sağlayacaktır.
• Kullanıcılar tarafından yüklenen dosyalar, virüslere ve zararlı yazılımlara karşı taranmalıdır.

13.Memory Management (Bellek Yönetimi)

• Güvenilmeyen veriler için girdi ve çıktı kontrolü yapılmalıdır.
• Tampon boyutunun belirtildiği kadar büyük olup, olmadı ikinci kez kontrol edilmelidir.
• Ara bellek sınırları kontrol edilmeli ve ayrılan alanı geçme tehlikesi olmadığından emin olunmalıdır.
• Kopyalama ve birleştirme işlemlerine geçmeden, tüm girdi dizelerini mantıklı bir uzunlukta kısaltılmalıdır.
• Kaynaklar özellikle kapatılmalıdır. (Örneğin, bağlantı nesneleri ve dosya tanıtıcıları gibi)
• Mümkün olduğunca çalıştırılamaz yığınlar kullanılmalıdır.
• Bilinen zafiyetli fonksiyonlar kullanılmamalıdır. (Örneğin, printf, strcat, strcpy gibi)

14.General Coding Practices (Genel Kodlama Uygulamaları

• Ortak işlevler için, standartların kullanılması önerilmektedir.
• Tüm doğrulama işlemleri sunucu tarafında yapılmalıdır.
• Kullanıcıdan gelen verilere asla güvenilmemelidir.
• Kullanıcıdan gelen veriler, doğrudan herhangi bir dinamik yürütme fonksiyonuna geçirilmemelidir.
• Uygulama tarafından, doğrudan işletim sistemine komut gönderilmesine izin verilmemelidir.
• Dosyaların ve kütüphanelerin bütünlüğü kontrol edilmelidir.
• En az ayrıcalıklar ile çalışma prensibi uygulanmalıdır.
• İkincil uygulamalar, 3. parti yazılımlar ve kütüphaneler kullanılmadan önce gözden geçirilmelidir.

Kaynaklar:

1. Uygulama Güvenliği Doğrulama Standardı 4.0 – OWASP
2. Secure Coding Practices Quick Reference Guide – OWASP
3. OWASP Nedir ? – Beyaz.net