Secure Coding Practices Part 1

Web geliştirme ekiplerinin, client based input validation, hidden fields ve interface controls (örn. pull downs and radio buttons) gibi client side kontrollerinin, güvenlik avantajı sağladığının bilinmesi önemlidir. Saldırganlar, uygulama trafiğini analiz etmek ve arabirimleri atlatarak client side web proxy’leri (örn. OWASP WebScarab, Burp) veya network packet capture araçlarını (ör. WireShark) kullanabilir. Ayrıca, Flash, Java Applet’leri ve diğer client side nesneleri analiz ederek sömürebilir ve manipüle edebilir.

Bu yazım da değinilecek güvenli kodlama adımları;

Part 1:
- Input Validation:
- Output Encoding:
- Authentication and Password Management:
- Session Management:
- Access Control:
- Cryptographic Practices:
- Error Handling and Logging:

Part 2:
- Data Protection
- Communication Security
- System Configuration
- Database Security
- File Management
- Memory Management
- General Coding Practices

Yazılım güvenlik kusurları, Yazılım geliştirme yaşam döngüsünün herhangi bir aşamasında, aşağıdaki adımlardaki hatalara çözüm kazadırarak bu sürece dahil edildiğinde ekiplere Secure SDLC prensibleri kazandırılabilir. Yapılan başlıca güvenlik hataları;

• Güvenlik gereksinimlerini önceden tanımlamamak
• Teknik güvenlik açıklara neden olacak zayıf kodlama uygulamalarını kullanmak
• Yazılımı yanlış dağıtmak
• Maintenance veya güncelleme sırasında kusurların tanımlanmaması

Yazılımda oluşacak Güvenlik zafiyetlerini temel alacak kusurlar ve sömürü noktaları aşağıdaki sistemlerde de zafiyete yol açabilir;

• Ilgili Yazılım Projesini tümünde ve ilişkili olduğu bilgi kaynaklarında
• İlişkili sunucularında ve işletim sistemlerinde
• İlişkili olduğu BackEnd sistemlerde
• İlişkili olduğu Uygulamalar ve Sistemlerde
• Kullanıcı sistemlerinde
• Kullanıcının etkileşimde bulunduğu diğer yazılımlarda

OWASP Secure Coding Practices Checklist

1. Input Validation:

• Güvenilir bir sistemde tüm veri doğrulamasını yürütün.
• Tüm veri kaynaklarını tanımlayın ve bunları “Güvenilir” ve “Güvenilir Değil” olarak sınıflandırın. Güvenilmeyen kaynaklardan gelen tüm verileri doğrulayın (ör. Veritabanları, dosya akışları, vb.)
• Uygulamalar için merkezi bir input validation rutini olmalıdır.
• Tüm input kaynakları için UTF-8 gibi uygun karakter setleri belirleyin.
• Doğrulamadan önce verileri ortak bir karakter setine kodlayın (Canonicalize)
• Tüm Validation hataları, Input Rejection ile sonuçlanmalıdır.
• Sistemin UTF-8 genişletilmiş karakter kümelerini destekleyip desteklemediğini belirleyin ve eğer öyleyse, UTF-8 decoding işlemi tamamlandıktan sonra doğrulayın.
• Tüm parametreler, URL’ler ve HTTP Header içeriği (ör. Cookie adları ve değerleri) dahil olmak üzere, işlenmeden önce tüm Client verilerini doğrulayın. JavaScript, Flash veya diğer gömülü kodlardan otomatik geri gönderimleri eklediğinizden emin olun.
• Her iki istek ve yanıtta Header değerlerinin yalnızca ASCII karakterleri içerdiğini doğrulayın.
• Verileri yeniden yönlendirmelerden doğrulayın (Bir saldırgan, kötü amaçlı içeriği doğrudan yönlendirme ile hedefe gönderebilir ve böylece uygulama mantığını ve yönlendirme öncesinde gerçekleştirilen tüm doğrulamaları atlatabilir)
• Expected Veri tiplerini onaylayın.
• Data Range’leri onaylayın.
• Data Lenght’leri onaylayın.
• Mümkün olan her türlü input noktasını Whitelist benzeri listelere göre doğrulayın.
• Potansiyel olarak tehlikeli karakterlere Input olarak izin verilmesi gerekiyorsa; Output encoding, Secure tasks spesifik API’ler ve bu verilerin uygulama boyunca kullanımı için hesap oluşturma gibi ek denetimler uyguladığınızdan emin olun. Bazı tehlikeli karakterlere örnekler: <> “‘% () & + \ \’ \”
• Standart doğrulama rutininiz aşağıdaki girdileri ele alamıyorsa, bunlar açıkça kontrol edilmelidir.
• Null Bytes (%00) kontrol edilmeli
• Yeni satır karakterleri ( %0d, %0a, \r, \n ) kontrol edilmeli

2. Output Encoding:

• Tüm encoding işlemlerini güvenilir bir sistemde gerçekleştirin.
• Her bir Outbound Encoding için standart, test edilmiş bir rutini kullanın.
• Bağlamsal olarak çıktı, Clint’a uygulamanın Trusted Boundary’sinin dışından kaynaklanan tüm verileri kodlar. HTML entity encoding buna bir örnektir, ancak her durumda çalışmaz.

Via OWASP — Output Encoding

• Beklenen ve güvenli görülen tüm karakterler dışındaki herşeyi encode edin.
• SQL, XML ve LDAP sorguları için tüm un-trusted verilerin çıktılarını bağlamsal olarak sanatize edin.

Authentication and Password Management:

• Özellikle genele açık olanlar dışındaki tüm sayfalar ve kaynaklar için kimlik doğrulaması istemeliyiz.
• Tüm kimlik doğrulama kontrolleri güvenilir bir sistemde uygulanmalıdır (ör. Sunucu)

ManageEngine Solutions Diagram

• Mümkün oldukça test edilmiş ve standartlara uygun stabil bir Authentication Servisi kullanılmalıdır.
• Harici kimlik doğrulama hizmetleri veren kütüphaneler de dahil olmak üzere tüm kimlik doğrulama kontrolleri için merkezi bir uygulama kullanın.
• İstenen kaynaktan gelen kimlik doğrulama mantığını ayrı tutun ve merkezi kimlik doğrulama denetimine yönlendirmeyi kullanın.
• Tüm hatalı doğrulama kontrollerinde mümkün oldukça az bilgi verilerek hata tanımlamaları kullanıcıya verilmelidir.
• Tüm yönetim ve hesap yönetimi işlevleri en azından birincil kimlik doğrulama mekanizması kadar güvenli olmalıdır.
• Uygulamanız bir Credential Store tarafından yönetiyorsa, yalnızca şifreli güçlü tek yönlü salted karma şifrelerinin saklanmasını ve anahtarları saklayan tablonun veya dosyanında yalnızca uygulama tarafından write-able olması sağlamalıdır.
• Password hashing işlemleri sadece güvenilir bir sistemde yapılmalıdır.
• Kimlik doğrulama hatası responce’ları, kimlik doğrulama verilerinin hangi bölümünün yanlış olduğunu göstermemelidir.
• Hassas bilgi veya fonksiyonları içeren harici sistemlere bağlantı için kimlik doğrulamasını kullanın.
• Kimlik doğrulama bilgilerini iletmek için yalnızca HTTP POST isteklerini kullanın
• Politika veya yönetmelikle belirlenen parola kombinasyonu gerekliliklerini uygulayın.
• Politika veya yönetmelik tarafından belirlenen şifre uzunluğu şartlarını uygulayın
• Şifre sıfırlama ve değiştirme işlemleri, hesap oluşturma ve kimlik doğrulama ile aynı düzeyde kontrol gerektirir.
• Şifre sıfırlama soruları yeterince rastgele cevapları desteklemelidir. (ör. “favori yemek” kötü bir sorudur; çünkü “hamburger” çok yaygın bir cevaptır :) )
• E-posta tabanlı sıfırlamalar kullanılıyorsa, geçici bir bağlantı / şifre ile önceden kayıtlı bir adrese e-posta gönderin
• Geçici şifreler ve linkler kısa bir sona erme süresine sahip olmalıdır.
• Bir sonraki kullanımda geçici şifrelerin değiştirilmesini zorunlu kılın
• Parola sıfırlama gerçekleştiğinde kullanıcıları bilgilendirin.
• Şifre alanları için “beni hatırla” işlevini devre dışı bırak
• Bir kullanıcı hesabının son kullanımı (başarılı veya başarısız) bir sonraki başarılı girişte kullanıcıya bildirilmelidir.
• Aynı şifreyi kullanarak birden fazla kullanıcı hesabına yönelik saldırıları tanımlamak için izleme uygulayın. Bu saldırı modeli, kullanıcı kimlikleri toplanabildiği veya tahmin edilebileceği zaman standart kilitlemelerin atlanması için kullanılır.
• Satıcı tarafından sağlanan tüm varsayılan şifreleri ve kullanıcı kimliklerini değiştirin veya ilişkili hesapları devre dışı bırakın
• Önemli işlemleri gerçekleştirmeden önce kullanıcıları yeniden doğrulayın
• Çok hassas veya yüksek değerli işlem hesapları için Çoklu Faktör Kimlik Doğrulaması kullanın
• Kimlik doğrulama için üçüncü taraf kodu kullanılıyorsa, herhangi bir zararlı koddan etkilenmediğinden emin olmak için kodu dikkatli bir şekilde inceleyin.

Session Management:

• Sunucu veya Framework’ün Session yönetimi kontrollerini kullanın. Uygulama yalnızca bu Session Identifiers’ı geçerli olarak tanımalıdır
• Session Identifier oluşturulması her zaman güvenilir bir sistemde yapılmalıdır.
• Session yönetimi kontrolleri, yeterince rastgele Session tanımlayıcılarını destekleyen, iyi araştırılmış algoritmalar ile kullanmalıdır.
• Kimliği doğrulanmış Session identifier’ları içeren Cookie’lerin etki alanı ve yollarını, site için uygun şekilde kısıtlanmış bir değere göre ayarlayın
• Logout işlevi, ilişkili Session’ı ve ilgili identifier Connection’ını tamamen sonlandırmalıdır.

(2) Daniel Szpisjak — “ Session Management “ Diagram

• Logout işlevi, yetkilendirilmiş tüm sayfalardan alınabilir.
• Dengeleme riskine ve işletme işlevsel gereksinimlerine dayanarak, mümkün olduğunca kısa bir Session etkinlik süreleri oluşturun. Çoğu durumda, birkaç saatten fazla olmamalıdır.
• Session aktif olsa bile, kalıcı girişlere izin vermeyin ve periyodik oturum sonlandırmalarını yürütün.
• Yeni bir Session açmadan önce başka bir Session açıksa, bu Session’ı kapatın ve başarılı bir girişten sonra yeni bir Session açılmasını sağlayın.
• Yeniden kimlik doğrulamasında yeni bir Session identifier oluşturun.
• Aynı kullanıcı kimliğiyle eşzamanlı girişlere izin verme
• Session identifier’larını URL’lere, hata mesajlarına maruz bırakmayın. Session identifier’ları sadece HTTP tanımlama bilgisi başlığında bulunmalıdır.
• Sunucu tarafı Session verilerini, sunucudaki uygun erişim denetimlerini uygulayarak, sunucunun diğer kullanıcıları tarafından yetkisiz erişime karşı koruyun.
• TLS bağlantısı üzerinden iletilen çerezlerin “güvenli” özelliğini ayarlayın.
• Cookie değerinin okunması veya ayarlanması için uygulamanızda Client side komut dosyalarını özellikle istemediğiniz sürece, HttpOnly özniteliği ile tanımlayın.

Access Control:

• Sadece güvenilir System Object’leri kullanın, ör. Access yetkilendirme kararlarını vermek için Server side Session Objects kullanın.
• Access yetkilendirmesini kontrol etmek için tek bir site çapında bileşen kullanın. Buna harici yetkilendirme hizmetleri veren kütüphaneler dahildir.
• Access kontrolleri güvenli bir şekilde başarısız olmalıdır.
• Uygulamanın güvenlik yapılandırma bilgilerine erişememesi durumunda tüm erişimi reddedilmelidir.
• Korunan URL’lere erişimi yalnızca yetkili kullanıcılarla kısıtlayın.
• Korunan Fonksiyonlara erişimi yalnızca yetkili kullanıcılarla kısıtlayın.
• Direct Object referanslarını yalnızca yetkili kullanıcılarla kısıtlayın.
• Korunan Servislere erişimi yalnızca yetkili kullanıcılarla kısıtlayın.
• Korunan Uygulama Verilerine erişimi yalnızca yetkili kullanıcılarla kısıtlayın.
• İş mantığı akışlarına uymak için Application Logic Flow’ları zorunlu kılın.
• Tek bir kullanıcının veya cihazın belirli bir sürede gerçekleştirebileceği işlem sayısını sınırlayın.
• “Referer” header’ını yalnızca tamamlayıcı bir denetim olarak kullanın, sahtekarlık yapabileceği için asla tek yetkilendirme kontrolü olmamalıdır
• Uzun süre doğrulanmış oturumlara izin verilirse, bir kullanıcının yetkilerini değiştirmediğinden emin olmak için. yetkilendirmesini periyodik olarak doğrulayın
• Dış sistemler ile bağlantı kurmayı destekleyen hizmet hesapları veya oturumları mümkün olan en az yetki ayrıcalığına sahip olmalıdır.

Cryptographic Practices:

• Şifreleri uygulama kullanıcısından korumak için kullanılan tüm şifreleme işlevleri, güvenilir bir sistemde (ör. Sunucu) uygulanmalıdır.
• Şifreleme modülleri güvenli bir şekilde Fail hatası vermeli ve Fail olmalıdır.
• Tüm rastgele sayılar, rastgele dosya adları, rastgele GUID’ler ve rasgele dizeler, gibi bu rastgele değerlerinde tahmin edilemez olması amaçlandığından kriptografik modülün onaylanmış rasgele sayı üretecide şifrelemeleri bu kapsamda oluşturmalıdır.
• Uygulama tarafından kullanılan şifreleme modülleri FIPS 140–2 veya eşdeğeri bir standarda uygun olmalıdır. (Bkz. Http://csrc.nist.gov/groups/STM/cmvp/validation.html)
• Şifreleme anahtarlarının nasıl yönetileceğine ilişkin bir politika ve süreç oluşturarak Kurum içi kullanmalıyız.

Error Handling and Logging:

• Sistem ayrıntıları, Session identifiers veya Account bilgileri de dahil olmak üzere Hata Responce’larında hassas bilgileri açıklamayın.
• Genel hata mesajlarını uygulayın ve özel hata sayfaları kullanın.
• Uygulama, uygulama hatalarını işlemeli ve sunucu yapılandırmasına güvenmemelidir.
• Hata koşulları oluştuğunda uygun şekilde ayrılmış bellek kullanın
• Güvenlik denetimleriyle ilişkili Error Handling Logic, varsayılan olarak erişimi reddetmelidir.
• Tüm Loglama kontrolleri güvenilir bir sistemde uygulanmalıdır.
• Loglama denetimleri, belirtilen Security Eventlerin hem Success hem de Failure aktivitelerini kaydetmelidir..
• Log detaylarını denetleyin, önemli Log Event verileri bulundurduğuna emin olun.
• Loglara erişimi yalnızca yetkili kişilerle kısıtla
• Tüm Loglama işlemleri için bir ana rutin yordamı kullanın
• Tüm giriş doğrulama hatalarını Loglayın.
• Tüm kimlik doğrulama girişimleri, özellikle hataları Loglayın.
• Tüm Kimlik Denetim hatalarını Loglayın.
• Burum verilerinde beklenmedik değişiklikler de dahil olmak üzere görünür tüm kurcalama olaylarını Loglayın.
• Loglama geçerli veya süresi dolmuş tüm Session Token’lere bağlanmaya çalışıldığında sağlanmalı.
• Tüm Backend TLS bağlantı hatalarını Loglamalıyız.
• Tüm kriptografik Modül hatalarını Loglamalıyız.

Kaynakça;

• https://security.berkeley.edu/secure-coding-practice-guidelines
• https://wiki.owasp.org/index.php/OWASP_Faux_Bank_Project
• https://www.owasp.org/images/0/08/OWASP_SCP_Quick_Reference_Guide_v2.pdf

Alıntı Resim;

• (1)https://www.manageengine.com/products/passwordmanagerpro/PMP-Datasheet.html
• (2) https://medium.com/@felin.arch/session-management-4d7642343e21