WEB UYGULAMA GÜVENLİĞİ KILAVUZU

ULUSAL ELEKTRONİK VE KRİPTOLOJİ ARAŞTIRMA ENSTİTÜSÜ Doküman Kodu: BGT-4001 WEB UYGULAMA GÜVENLİĞİ KILAVUZU SÜRÜM 1.00 16 KASIM 2007 Hazırlayan: Bedirhan URGUN P.K. 74, Gebze, 41470 Kocaeli, TÜRKİYE Tel: (0262) 648 1000 Faks: (0262) 648 1100 http://www.bilgiguvenligi.gov.tr teknikdok@bilgiguvenligi.gov.tr

WEB UYGULAMA GÜVENLİĞİ KILAVUZU ÖNSÖZ ÖNSÖZ Ulusal Elektronik ve Kriptoloji Araştırma Enstitüsü (UEKAE)'nün misyonu, "bilgi güvenliği, haberleşme ve ileri elektronik alanlarında Türkiye'nin teknolojik bağımsızlığını sağlamak ve sürdürmek için nitelikli insan gücü ve uluslararası düzeyde kabul görmüş altyapısı ile, bilimsel ve teknolojik çözümler üretmek ve uygulamaktır". Bu ana hedef göz önünde bulundurularak belirlenen "bilgi güvenliği, haberleşme ve ileri elektronik alanlarında yeni teknolojilerin geliştirilmesine öncülük eden uluslararası bilim, teknoloji ve üretim merkezi olmak" vizyonuna ulaşılabilmesi ve ülkenin ihtiyacı olan teknolojilerin geliştirilmesi için Enstitü'nün akredite test ortam ve laboratuarlarında temel ve uygulamalı araştırmalar yapılmakta ve ihtiyaç sahiplerine teknik destek sağlanmaktadır. Bu doküman Ulusal Bilgi Sistemleri Güvenlik Projesi kapsamında hazırlanmış olup ihtiyaç sahiplerini bilgi sistemleri güvenliği konusunda bilinçlendirmeyi hedeflemektedir. Tüm kurum ve kuruluşlar bu dokümandan faydalanabilir. Bu dokümanda bahsi geçen belirli ticari marka isimleri kendi özgün sahiplerine aittir. Burada anlatılanlar tamamen tavsiye niteliğinde olup değişik ürünler/yapılandırmalar için farklılık gösterebilir. UEKAE, yapılan uygulamalardan doğabilecek zararlardan sorumlu değildir. Bu doküman UEKAE nin izni olmadan değiştirilemez. 2 TÜBİTAK UEKAE

BİLGİLENDİRME WEB UYGULAMA GÜVENLİĞİ KILAVUZU BİLGİLENDİRME Bu dokümanın oluşturulmasında emeği geçen Ağ Güvenliği personeline ve dokümanı gözden geçirip fikirlerini öne sürerek dokümanın olgunlaşmasına katkıda bulunan kişilere teşekkürü borç biliriz. TÜBİTAK UEKAE 3

WEB UYGULAMA GÜVENLİĞİ KILAVUZU İÇİNDEKİLER İÇİNDEKİLER 1. GİRİŞ... 15 1.1 Amaç ve Kapsam...15 1.2 Hedeflenen Kitle...15 1.3 Kısaltmalar...16 2. WEB UYGULAMALARI GİRİŞ... 17 2.1 Teknolojiler...17 2.1.1 CGI...17 2.1.2 Filtreler...18 2.1.3 Betik Yazmak...18 2.1.4 Web Uygulama Çatıları...19 2.1.5 Sunum (view)...20 2.1.6 Kontrolcü (controller)...20 2.1.7 Uygulama Mantığı (model)...20 3. GÜVENLİ KODLAMA PRENSİPLERİ... 22 3.1 Değer Sınıflandırması...22 3.2 Saldırganlar Hakkında...22 3.3 Bilgi güvenliğinin temel dayanakları...23 3.4 Güvenlik Mimarisi...24 3.5 Güvenlik İlkeleri...24 3.6 Saldırı Yüzey Alanını Küçültmek...25 3.7 Güvenli Öntanımlar...25 3.8 En Az Öncelik İlkesi...25 3.9 Kademeli Savunma İlkesi...26 3.10 Güvenli Aksama...26 3.11 Dış Sistemlerin Güvenli Olmaması...26 3.12 Görevlerin Ayrımı...27 3.13 Belirsizlik Yolu ile Güvenliğe Güvenmeyin...27 4 TÜBİTAK UEKAE

İÇİNDEKİLER WEB UYGULAMA GÜVENLİĞİ KILAVUZU 3.14 Basitlik...28 3.15 Güvenlik Sorunlarını Uygun Şekilde Ele Almak...28 4. TEHDİT RİSK MODELLEME... 29 4.1 Tehdit Riskleri Modellemesinin Yapılması...29 4.2 Tehdit Model Akışı...30 4.3 Güvenlik Hedeflerinin Belirlenmesi...30 4.4 Uygulamanın Gözden Geçirilmesi...31 4.5 Uygulamayı Ayrıştırma...32 4.6 Bilinen Tehditlerin Dokümanı...32 4.7 STRIDE...34 4.7.1 Yanıltıcı kimlik...34 4.7.2 Veriyle oynamak...34 4.7.3 Reddetme...35 4.7.4 Bilgi Açıklama...35 4.7.5 Servis reddi...35 4.7.6 Ayrıcalık Seviyesi...35 5. WEB SERVİSLERİ... 37 5.1 Web Servislerinin Güvenliği...37 5.2 İletişim Güvenliği...38 5.3 Kimlik Bilgilerinin Taşınması...39 5.4 Mesaj Tazeliğini Sağlamak...39 5.5 Mesaj Bütünlüğünün Sağlanması...40 5.6 Mesaj Gizliliğinin Korunması...40 5.7 Erişim Kontrolü...41 5.8 Denetleme...41 5.9 Web Servisleri Güvenlik Hiyerarşisi...42 5.10 Standartlar Komitesi...42 5.11 SOAP...43 5.12 XML Güvenlik Spesifikasyonları (XML-dsig & Şifreleme)...44 TÜBİTAK UEKAE 5

WEB UYGULAMA GÜVENLİĞİ KILAVUZU İÇİNDEKİLER 5.13 Güvenlik Spesifikasyonları...44 5.14 WS-Güvenlik) Standardı...45 5.15 Standardın Organizasyonu...45 5.16 Amaç...46 5.17 WS- Güvenlik Yapı Taşlar...47 5.18 Veri Nasıl Taşınıyor...47 5.19 Güvenlik Başlığının Yapısı...47 5.20 Sembol Çeşitleri...51 5.21 Mesaj Parçacıklarına Atıf...52 5.22 İletişim Korum Mekanizmaları...53 5.23 Bütünlük...53 5.24 Gizlilik...54 5.25 Tazelik...54 5.26 Erişim Kontrol Mekanizmaları...55 5.27 Tanımlama...55 5.28 Kimlik Doğrulama...55 5.29 Yetkilendirme...56 5.30 Politika Anlaşması...56 5.31 Web Servis Zinciri Oluşturma...57 5.32 Uyumsuz Kullanıcı Eşimi Kontrol Modelleri...58 5.33 Servislerin Güven İlişkisi...58 5.34 Güvenli Bağlantılar...58 5.35 Kullanıcı Dizinlerinin Senkronizasyonu...58 5.36 Etki Alanı Birleşmeleri...59 5.37 Var olan Uygulamalar...59 5.38.NET Web Servis Eklentisi...59 5.39 Java Araç Kitleri...60 5.40 Donanım, yazılım sistemleri...60 6 TÜBİTAK UEKAE

İÇİNDEKİLER WEB UYGULAMA GÜVENLİĞİ KILAVUZU 5.41 Problemler...61 5.42 Standartların Hamlığı...61 5.43 Performans...62 5.44 Karmaşıklık ve Birlikte Çalışırlık...62 5.45 Anahtar Yönetimi...63 6. KİMLİK DOĞRULAMA... 64 6.1 Amaç...64 6.2 En İyi Uygulamalar...64 6.3 Genel Web Kimlik Doğrulama Yöntemleri...65 6.4 Temel ve Özet Kimlik Doğrulama...65 6.5 Form Tabanlı Kimlik Doğrulama...66 6.6 Bütünleşik Kimlik Doğrulama...67 6.7 Sertifika Tabanlı Kimlik Doğrulama...67 6.8 Güçlü Kimlik Doğrulama...68 6.9 Ne Zaman Güçlü Kimlik Doğrulama Kullanılmalıdır:...68 6.10 Risk Ne Anlam İfade Eder?...69 6.11 Biometrikler Kendi Başlarında Güçlü Bir Kimlik Doğrulama Değillerdir...69 6.12 Güçlü kimlik doğrulamanın sorunları...73 6.13 Birleşik Kimlik Doğrulama...74 6.14 Kimlik (Bilgisi) Kanunları (Kuralları)...74 6.15 Microsoft Pasaport...75 6.16 İstemci Taraflı kimlik doğrulama kontrolleri...75 6.16.1 Saldırıya Açıklığı Anlama...75 6.16.2 Korunma Yolları...76 6.17 Pozitif Kimlik Doğrulama...76 6.17.1 Saldırıya Açıklığı Anlama...76 6.17.2 Korunma Yolları...77 6.18 Birden Fazla Anahtar ile Bakmak...78 6.18.1 Saldırıya Açıklığı Anlama...78 TÜBİTAK UEKAE 7

WEB UYGULAMA GÜVENLİĞİ KILAVUZU İÇİNDEKİLER 6.18.2 Korunma Yolları...79 6.19 Yönlendirici Kontrolü...81 6.19.1 Saldırıya Açıklığı Anlama...81 6.19.2 Korunma Yolları...81 6.20 Tarayıcılar parolaları hatırlar...82 6.20.1 Saldırıya Açıklığı Anlama...82 6.20.2 Korunma Yolları...82 6.21 Varsayılan Hesaplar...83 6.21.1 Saldırıya Açıklığı Anlama...83 6.21.2 Korunma Yolları...84 6.22 Kullanıcı adı seçimi...84 6.22.1 Saldırıya Açıklığı Anlama...84 6.22.2 Korunma Yolları...84 6.23 Şifre Değiştirmek...85 6.24 Saldırıya Açıklığı Anlama...85 6.25 Korunma Yolları...85 6.26 Kısa Parolalar...85 6.26.1 Saldırıya Açıklığı Anlama...86 6.26.2 Korunma Yolları...86 6.27 Zayıf Parola Kontrolleri...86 6.27.1 Saldırıya Açıklığı Anlama...87 6.27.2 Korunma Yolları...87 6.28 Tersinir Parola Şifreleme...88 6.28.1 Saldırıya Açıklığı Anlama...88 6.28.2 Korunma Yolları...88 6.29 Otomatik Parola Yenilemeleri...89 6.29.1 Saldırıya Açıklığı Anlama...89 6.29.2 Korunma Yolları...90 6.30 Kaba Kuvvet...91 8 TÜBİTAK UEKAE

İÇİNDEKİLER WEB UYGULAMA GÜVENLİĞİ KILAVUZU 6.30.1 Saldırıya Açıklığı Anlama...91 6.30.2 Korunma Yolları...91 6.31 Beni Hatırla...93 6.31.1 Saldırıya Açıklığı Anlama...94 6.31.2 Korunma Yolları...94 6.32 İşe Yaramaz Zaman Aşımları...94 6.32.1 Saldırıya Açıklığı Anlama...94 6.32.2 Korunma Yolları...94 6.32.3 Saldırıya Açıklığı Anlama...95 6.32.4 Korunma Yolları...95 6.33 Hesabın Kapatılması...95 6.33.1 Saldırıya Açıklığı Anlama...95 6.33.2 Korunma Yolları...96 6.34 Kendi Kendine Kayıt...96 6.34.1 Saldırıya Açıklığı Anlama...97 6.34.2 Korunma Yolları...97 6.34.3 TOBIAT(CAPTCHA)...97 6.34.4 Saldırıya Açıklığı Anlama...98 6.34.5 Korunma Yolları...98 7. YETKİLENDİRME... 99 7.1 Amaç...99 7.2 Minimum hak prensibi...99 7.2.1 Saldırıya Açıklığı Anlama...100 7.2.2 Korunmanın Yolları...100 7.3 Erişim Kontrol Listeleri...101 7.3.1 Saldırıya Açıklığı Anlama...101 7.3.2 Korunmanın Yolları...101 7.4 Özel yapım yetkilendirme kontrolleri...102 7.4.1 Saldırıya Açıklığı Anlama...103 7.4.2 Korunmanın Yolları...103 TÜBİTAK UEKAE 9

WEB UYGULAMA GÜVENLİĞİ KILAVUZU İÇİNDEKİLER 7.5 Merkezi yetkilendirme rutinleri...103 7.5.1 Saldırıya Açıklığı Anlama...103 7.5.2 Korunmanın Yolları...104 7.6 Yetkilendirme matrisi...104 7.6.1 Saldırıya Açıklığı Anlama...104 7.6.2 Korunmanın Yolları...104 7.7 İstemci taraflı yetkilendirme parçaları (jetonlar)...104 7.7.1 Saldırıya Açıklığı Anlama...104 7.7.2 Korunmanın Yolları...105 7.8 Korunan kaynaklara erişimi kontrol etme...106 7.8.1 Saldırıya Açıklığı Anlama...107 7.8.2 Korunmanın Yolları...107 7.9 Statik kaynaklara erişimi korumak...107 7.9.1 Saldırıya Açıklığı Anlama...108 7.9.2 Korunmanın Yolları...108 8. OTURUM YÖNETİMİ... 109 8.1 Amaç...109 8.2 Açıklama...109 8.3 En iyi yöntemler...110 8.4 Yanılgılar (Yanlış Bildiklerimiz)...111 8.5 Serbest Oturum Üretmek...112 8.5.1 Saldırıya Açıklığı Anlama...112 8.5.2 Korunma Yolları...112 8.6 Korunmasız Oturum Değişkenleri...112 8.6.1 Saldırıya Açıklığı Anlama...113 8.6.2 Korunma Yolları...113 8.7 Sayfa ve Form Jetonları...113 8.7.1 Saldırıya Açıklığı Anlama...113 8.7.2 Korunma Yolları...114 8.8 Zayıf Oturum Kriptografik Algoritmaları...114 10 TÜBİTAK UEKAE

İÇİNDEKİLER WEB UYGULAMA GÜVENLİĞİ KILAVUZU 8.8.1 Saldırıya Açıklığı Anlama...114 8.8.2 Korunma Yolları...114 8.9 Uygun Anahtar Uzayı...114 8.10 Oturum Jeton Entropisi...115 8.11 Oturum Zaman Aşımı...115 8.11.1 Saldırıya Açıklığı Anlama...115 8.11.2 Korunma Yolları...115 8.12 Oturum Jetonlarının Yeniden Oluşturulması...116 8.12.1 Saldırıya Açıklığı Anlama...116 8.12.2 Korunma Yolları...116 8.13 Oturum Sahteciliği/Kaba Kuvvet Yakalama ve/veya Kilitleme...116 8.13.1 Saldırıya Açıklığı Anlama...117 8.13.2 Korunma Yolları...117 8.14 Oturum Jetonlarının Aktarılması (Transmission)...117 8.14.1 Saldırıya Açıklığı Anlama...117 8.14.2 Korunma Yolları...118 8.15 Çıkış İşlemi Sırasında Oturum Jetonları...118 8.15.1 Saldırıya Açıklığı Anlama...118 8.15.2 Korunma Yolları...118 8.16 Oturum Korsanlığı...118 8.16.1 Saldırıya Açıklığı Anlama...119 8.17 Korunma Yolları...119 8.18 Oturum Doğruluğu Saldırıları...119 8.18.1 Saldırıya Açıklığı Anlama...120 8.18.2 Korunma Yolları...120 8.19 Oturum Denetleme Saldırıları...120 8.19.1 Saldırıya Açıklığı Anlama...120 8.19.2 Korunma Yolları...120 8.20 Önceden Belirlenmiş Oturum Saldırıları...120 TÜBİTAK UEKAE 11

WEB UYGULAMA GÜVENLİĞİ KILAVUZU İÇİNDEKİLER 8.20.1 Saldırıya Açıklığı Anlama...121 8.20.2 Korunma Yolları...121 8.21 Oturum Kaba Kuvvet Saldırıları...121 8.21.1 Saldırıya Açıklığı Anlama...122 8.21.2 Korunma Yolları...122 8.22 Oturum jeton tekrar oynaması (replay)...122 8.22.1 Saldırıya Açıklığı Anlama...123 8.22.2 Korunma Yolları...123 9. GİRDİ DENETİMİ... 124 9.1 Amaç...124 9.2 Açıklama...124 9.3 Tanımlar...124 9.3.1 Bütünlük kontrollerini nerde uygulamalı...124 9.3.2 Denetlemeyi nereye koymalı...125 9.3.3 İş mantığı denetlemesini nereye koymalı...125 9.4 Örnek - Senaryo...125 9.4.1 Yanlış Yol...125 9.4.2 Kabul Edilebilir Yöntem...125 9.4.3 En İyi Yöntem...126 9.4.4 Sonuç...126 9.5 Girdi Denetimi Stratejileri...126 9.5.1 Sadece iyiyi kabul etmek...126 9.5.2 Bilinen kötüleri refüze etmek...127 9.5.3 Düzeltmek...127 9.5.4 Denetim uygulamamak...127 9.6 Parametre manipülasyonunu engellemek...128 9.7 Gizli alanlar...129 9.8 ASP.NET Viewstate...130 9.8.1 Saldırıya Açıklığı Anlama...130 9.8.2 Korunma Yolları...131 12 TÜBİTAK UEKAE

İÇİNDEKİLER WEB UYGULAMA GÜVENLİĞİ KILAVUZU 9.9 Selects, radio button, ve checkbox...131 9.10 Kullanıcıya Ait Veriler...133 9.11 URL kodlama...134 9.12 HTML kodlama...135 9.13 Kodlanmış dizgiler (strings)...135 9.14 Ayraçlar ve özel karakterler...135 10. HATA YÖNETİMİ ve KAYIT TUTMA... 137 10.1 Amaç...137 10.2 Tanımlama...137 10.3 En iyi uygulamalar...138 10.4 Hata başa çıkma...138 10.4.1 Sistemden düşmeye karşı korunmalı...139 10.4.2 Kusur giderme hataları...139 10.4.3 Hariç tutma işlemi...139 10.4.4 Fonksiyonel geri dönüş değerleri...139 10.5 Ayrıntılı hata mesajları...140 10.5.1 Tehlikeye açık olup olmadığınızı saptama...140 10.5.2 Korunma Yolları...140 10.6 Kayıt...140 10.6.1 Nereye kayıtlama?...140 10.6.2 Başa çıkma...141 10.6.3 Genel kusur giderme...141 10.6.4 Adli Analiz kanıt...141 10.6.5 Saldırı saptama...141 10.6.6 Geçerliliğin kanıtlanması...141 10.6.7 Kayıt türleri...142 10.7 Karmaşa...143 10.7.1 Korunma Yolları...144 10.8 İz kaybettirme...144 TÜBİTAK UEKAE 13

WEB UYGULAMA GÜVENLİĞİ KILAVUZU İÇİNDEKİLER 10.8.1 Korunma Yolları...144 10.9 Yanlış alarmlar...145 10.9.1 Korunma Yolları...145 10.9.2 Hizmetin reddi...145 10.9.3 Korunma Yolları...145 10.10 İmha...146 10.10.1 Korunma Yolları...146 10.11 Saptama izleri...146 10.11.1 Tehlikeye açık olup olmadığınızı saptama...147 10.11.2 Korunma Yolları...147 14 TÜBİTAK UEKAE

GİRİŞ WEB UYGULAMA GÜVENLİĞİ KILAVUZU 1. GİRİŞ Bu dokümanda web uygulaması geliştirmesinde uyulması gereken güvenlik esasları anlatılacaktır. Doküman büyük ölçüde OWASP Guide 2.0.1 [1] dokümanın bazı ana konu bölümlerinin dilimize çevrilmesi ile oluşturulmuştur. Diğer çevirilere www.webguvenligi.org sayfasından ulaşabilirsiniz [3]. Bu bölümlerin çevirilerinde rol alan; Billur Ç. Yılmazyiğit e Çiğdem Akanyıldız a Emre Çakır a Mesut Timur a Oğuz Yılmaz a teşekkürler. 1.1 Amaç ve Kapsam Bu dokümanda amaç, bir web uygulamasının güvenli bir şekilde tasarımı ve geliştirilmesi için gerekli esasları belirlemektir. Esaslar belirlenirken, belirli bir kritiklik derecesindeki uygulamalar hedef alınmamıştır. Fakat bazı esasların daha kritik sistemlerde nasıl uygulanması gerektiği üzerinde durulmuştur. Literatürde kullanılan en iyi güvenli uygulama tasarım ve geliştirme metotları araştırılmış ve esas olarak belirlenmiştir. Esaslar, güvenli web uygulaması tasarım ve geliştirme amacı ile oluşturulmuştur. Esaslar içinde çoğu zaman esasların teknik anlamda nasıl uygulanması gerektiği üzerinde bilgiler verilmiştir. Ayrıca yapılan araştırma çalışmalarının kaynakları da referans bölümünde verilmiştir. Web uygulamaları tasarım ve geliştirme esasları dokuz ana başlık altında ele alınmıştır. Her başlık altında o başlığın güvenlik hedefleri anlatılmış ve daha sonra esaslar verilmiştir. 1.2 Hedeflenen Kitle Bu doküman bir web uygulaması planlama, geliştirme ve test sürecinde görev alan, yöneten ya da bu konularda çalışmak isteyen kişiler tarafından kullanılabilir. TÜBİTAK UEKAE 15

WEB UYGULAMA GÜVENLİĞİ KILAVUZU GİRİŞ 1.3 Kısaltmalar UEKAE : Ulusal Elektronik ve Kriptoloji Araştırma Enstitüsü IP : Internet Protocol XST : Cross Site Tracing XHR : XML HTTP Request HTTPS : Hyper Text Transfer Protocol Secure HTTP : Hyper Text Transfer Protocol FTP : File Transfer Protocol CGI : Common Gateway Interface PHP : PHP Hypertext Processor ASP : Active Server Pages JSP : Java Server Pages UML : Unified Modeling Language B2B : Business to Business SOAP : Service Oriented Application Protocol SQL : Structured Query Language LDAP : Lightweight Directory Access Protocol XML : extensible Markup Language URL : Unified Resource Locator XSS : Cross Site Scripting 16 TÜBİTAK UEKAE

WEB UYGULAMALARI GİRİŞ WEB UYGULAMA GÜVENLİĞİ KILAVUZU 2. WEB UYGULAMALARI GİRİŞ Web in ilk zamanlarında Internet içeriği statik sayfalardan oluşmaktaydı. Açıktır ki, statik içerik bir uygulamanın kullanıcıyla etkileşimde bulunmasını engeller. Bu durum sınırlayıcı olduğundan, web sunucu üreticileri Common Gateway Interface (veya CGI) ı kullanarak harici programların çalışmasını sağladılar. Bu gelişme, kullanıcının sağladığı girdilerin harici programlara veya betiklere gitmesini, işlenmesini ve kullanıcıya tekrar cevap dönülmesini sağladı. CGI bugün yaygın olarak kullanılan bütün web uygulama çatıların, betik dillerin, ve web servislerin babasıdır. CGI artık günümüzde çok daha az kullanılmaktadır ama kullanıcıdan veya veritabanından gelen dinamik bilginin işlem görmesi ve bunu takiben çıktı akışının dönülmesi fikri web uygulamalarında kullanılmaya devam edecektir. 2.1 Teknolojiler 2.1.1 CGI CGI hala birçok site tarafından kullanılmaktadır. CGI ın bir avantajı C veya C++ gibi dillerde uygulama mantığının rahatlıkla yazılabiliyor olması veya web ile ilgili olmayan önceden yazılmış bir uygulamayı web tarayıcıları ile kullanılabilir hale getirilebiliyor olmasıdır. CGI ile uygulama yazmanın birçok dezavantajı vardır; TÜBİTAK UEKAE 17

WEB UYGULAMA GÜVENLİĞİ KILAVUZU WEB UYGULAMALARI GİRİŞ Çoğu alt seviye dilleri HTML çıkış akışını direk olarak desteklemediklerinden özel bir kütüphane yazımını gerektirirler veya HTML çıkış yazılımcı tarafından manuel olarak oluşturulur. Yaz Derle - Kur Yürüt döngüsü sonradan gelen teknojılere gore daha yavaştır. CGI ayrı bir süreçtir ve IPC & süreç yaratma işlemleri bazı mimarilerde büyük bir performans problemi oluştururlar. CGI oturum kontrollerini desteklemediğinden, bu işlemleri desteklemesi için bir kütüphane yazılması ve içerilmesi gerekmektedir. Herkes alt düzey dillerde (C veya C++ gibi) çok rahat olmadığından, program yazılımı sonradan çıkan teknolojilere gore zordur. CGI la kullanılan çoğu 3 üncü kuşak diller, arabellek taşmaları ve kaynak sızmalarından zarar görmektedirler. Bu problemlerden kurtulmak için büyük ölçüde bir yetenek gerekmektedir. CGI ağır yük ve uzun süren gerektiren az kullanıcılı işlemlerde faydalı olabilir. 2.1.2 Filtreler Filtreler, bir web sitesine erişimi kontrol etmek, başka bir web uygulama çatısı (mesela Perl, PHP, veya ASP) yazmak veya güvenlik kontrolü sunmak gibi belirli amaçlar için kullanılmaktadırlar. Bir filtrenin C veya C++ da yazılması gerekir ve web sunucunun çalışma kapsamında (execution context) bulunduğundan süreçlerde yüksek performans sergileyebilir. Filtre arabirimlerine verilebilecek tipik örnekler arasında Apache web sunucu modülleri, SunONE nın NSAPI sı, ve Microsoft un ISAPI sı yer almaktadır. Filtreler çok nadiren web sunucuların kullanılabilirliğini etkileyen arabirimlerde kullanıldığından daha fazla üzerinde durulmayacaktır. 2.1.3 Betik Yazmak CGI nın oturum yönetimi ve yetkilendirme kontrollerinin olmaması, ticari amaçlar için faydalı web uygulamaların gelişmesini engelledi. Yavaş kar dönüşümüyle birlikte, web geliştiriciler çözüm olarak yorumlanmış betik dillerine yöneldiler. Yorumlayıcılar, betikleri web sunucunun süreci içerinde çalıştırdıkları ve betikler derlenmedikleri için, yaz-kur-yürüt döngüsü biraz daha hızlı olmaktaydı. Betik dilleri çok nadiren arabellek taşmaları ve bilgi sızmalarından zarar gördüklerinden programcılar için genel güvenlik meselelerini önlemek daha kolay olmaktadır. 18 TÜBİTAK UEKAE

WEB UYGULAMALARI GİRİŞ WEB UYGULAMA GÜVENLİĞİ KILAVUZU Betik kullanmanın bazı dezavantajları; Çoğu betik dilleri güçlü tipleri zorunlu kılan diller (strongly typed) değildirler ve en iyi programcılık usullerinin gelişmesine yardım etmezler. Genel olarak betik diller derlenmiş dillerden daha yavaştırlar (bazen 100 kat daha yavaş) Betikler çoğu zaman idame edilemeyen kod bütünlüğüne dönüşür ve performansı büyük ölçüde düşürürler. Betikler ile birden fazla katmanlı büyük uygulamalar yazmak (imkansız değilse bile) zordur ve bundan dolayı çoğu zaman sunum, uygulama ve veri katmanları aynı makinada bulunurlar. Bu durumda ölçeklenirlik ve güvenlik sınırlanmış olur. Çoğu betik dilleri sisteme özgül olarak uzaktan metod ve servis çağrılarını desteklemezler ve bundan dolayı uygulama sunucuları ve harici web servisleri ile iletişim daha zor olur. Dezavantajları bir yana, egroupware (PHP) gibi büyük ve faydalı kod bazları betik dilleri ile ve çoğu eski Internet bankacılık siteleri çoğu zaman ASP ile yazılmıştır. Betik çatıları ASP, Perl, Cold Fusıon, ve PHP dillerini de içerir. Ama bunların çoğu, özellikle PHP ve Cold Fusion dillerinin en son versiyonları, hibrid yorumlamalar olarak düşünülmektedirler. 2.1.4 Web Uygulama Çatıları Betik dillerin performans ve ölçeklenirlik sınırlarına yaklaşıldıkça, bir çok büyük üretici Sun firmasının J2EE web geliştirme platformuna yöneldiler. J2EE: TÜBİTAK UEKAE 19

WEB UYGULAMA GÜVENLİĞİ KILAVUZU WEB UYGULAMALARI GİRİŞ Kolay kolay arabellek taşmalarından ve hafıza bilgi sızmaları gibi problemler yaşamayan ve hızlı web uygulamaları için (C++ uygulamaları kadar hızlı) Java dilini kullanır. İlk olarak büyük dağıtık uygulamaları kabul edilir ölçülerde çalışmasını mümkün kıldı. İyi oturum ve yetkilendirme kontrollerine sahiptir. Birçok uzaktan çağırma (remote invocations) mekanizmaları ile beraber neredeyse şeffaf çok katmanlı uygulamaları mümkün kıldı. Çoğu, genel güvenlik ve programcılık sorunlarını program çalışmadan bile engelleyen kuvvetli tipler kullanmaktadır. 2.1.5 Sunum (view) Ön uç görüntülemeye yarayan, çoğu zaman sunum katmanı denilen kod, HTML çıktısını uygulama mantığına hiç bağlı olmadan üretmeyi hedef alması gerekmektedir. Birçok uygulama uluslararası hale geleceğinden (yani sunum katmanında hiç yöresel dizgi (string) veya kültürel bilgisi olmayacağından), bu uygulamaların kullanıcının şeçtiği dil, kültür, yazı yönü, ve birimlere göre, faydalı bilgiyi görüntülemeye yarayan verileri almak için model in (uygulama mantığının) içine çağrılarda bulunması gerekmektedir. Büyün kullanıcı girdileri uygulama mantığında kontrolcülere yönlendirilmektedirler. 2.1.6 Kontrolcü (controller) Kontrolcü (veya uygulama mantığı) kullanıcılardan girdi alır ve bu girdiyi veri çekmek, işlemek veya saklamak için uygulamanın model nesnelerini çağıran çeşitli iş akışlarına aktarır. 2.1.7 Uygulama Mantığı (model) Modeller Hesap veya Kullanıcı gibi fonksiyonellikleri kapsar ve üst seviye iş süreçlerini gerçeklemek için metot (method) sağlarlar. Örnek olarak iyi bir model, kontrolcüde aşağıdaki gibi bir kod benzerinin bulunması yerine; if oaccount->ismyacct(fromacct) & amount < oaccount->getmaxtransferlimit() & oaccount->getbalance(fromacct) > amount & oaccount->toaccountexists(toacct) & 20 TÜBİTAK UEKAE

WEB UYGULAMALARI GİRİŞ WEB UYGULAMA GÜVENLİĞİ KILAVUZU then if oaccount->withdraw(fromacct, Amount) = OK then oaccount->deposit(toacct, Amount) end if end if if oaccount->ismyacct(fromacct) & amount < oaccount->getmaxtransferlimit() & oaccount->getbalance(fromacct) > amount & oaccount->toaccountexists(toacct) & then if oaccount->withdraw(fromacct, Amount) = OK then oaccount->deposit(toacct, Amount) end if end if aşağıdaki kod benzerinin bulunmasını sağlar; oaccount->transferfunds(fromacct, ToAcct, Amount) oaccount->transferfunds(fromacct, ToAcct, Amount) Web uygulamaları çok değişik yollarla ve dillerle yazılabilirler. Bu kılavuz verdiği örneklerde yaygın kullanılan üç uygulama çatılarına (PHP, J2EE, ASP.NET) ağırlık verse de, mesajları bütün web uygulamaları için geçerlidir. TÜBİTAK UEKAE 21

WEB UYGULAMA GÜVENLİĞİ KILAVUZU GÜVENLİ KODLAMA PRENSİPLERİ 3. GÜVENLİ KODLAMA PRENSİPLERİ Tasarımla güvenli uygulamalar üretebilmek için yönlendirmeye ihtiyaç duyan uygulama mimarları ve çözüm üreticileri, bunu gerçekleştirebilmek adına ana metinde belgelenen temel kontrolleri uygulamakla birlikte bu ilkelerin altında yatan Neden? sorusuna da tekrar gönderme yaparlar. Gizlilik, bütünlük ve kullanılabilirlik gibi güvenlik ilkeleri, önemli, geniş ve belirsiz olsalar da, değişime uğramazlar. Bu ilkeler ne kadar çok kullanılırsa, uygulamalar o denli sağlam olacaktır. Örneğin, girilen bütün bilgi türleri için, merkezileştirilmiş bir geçerlilik rutini kapsamaya yönelik veri geçerliliği uygulamak hassas bir süreçtir. Ancak, kullanıcının gireceği tüm bilgiler için uygun hata yönetimi ve sağlam erişim kontrolüyle birlikte her dizide geçerlilik görmek çok daha hassas bir süreçtir. 3.1 Değer Sınıflandırması Kontrollerin seçimi, ancak korunacak verinin sınıflandırılmasından sonra mümkün olabilmektedir. Örneğin, blog ve forumlar gibi düşük değerli sistemlerde uygulanabilen kontroller muhasebe, yüksek değerli bankacılık ve elektronik ticaret sistemlerine uygun kontrollerden seviye ve nicelik açısından farklıdır. 3.2 Saldırganlar Hakkında Uygulamalarınızın yanlış kullanımını engellemek üzere kontroller tasarlarken, olası saldırıları (olasılık ve gerçek kayıpları çoktan en aza indirebilmek adına) dikkate almanız gerekmektedir: 22 TÜBİTAK UEKAE

GÜVENLİ KODLAMA PRENSİPLERİ WEB UYGULAMA GÜVENLİĞİ KILAVUZU Memnun olmayan çalışanlar ya da üreticiler Yan etkiler ya da virüs, solucan ve truva atları saldırılarının doğrudan sonuçları gibi sürücü saldırıları Organize suç benzeri, güdülenmiş ve suçlu saldırganlar Tahrif ediciler gibi organizasyonunuzun aleyhinde bulunan ancak motive olmamış suçlu saldırganlar Niteliksiz saldırılar Bilgisayar korsanlığı terimi için hiçbir madde olmadığına dikkat çekmek isteriz. Bu, medyanın bilgisayar korsanlığı kelimesini duygusal ve yanlış kullanımından kaynaklanmaktadır. Doğru terim suçlu dur. Polise giderek daha ciddi suçluları cezalandırmaları için onlara destek olma konusunda istekli olmayan organizasyonlardan dolayı, polis tarafından yakalanan ve dava edilen tipik suçlular niteliksiz saldırganlardır. Ancak, bilgisayar korsanlığı kelimesinin yanlış kullanımını düzeltmek ve kelimeyi doğru köküne döndürmek için artık çok geçtir. Kılavuz, belirli bir özelliği aktif halde kötüye kullanma girişiminde bulunan bir şey ya da birini ifade ederken devamlı olarak saldırgan kelimesini kullanmaktadır. 3.3 Bilgi güvenliğinin temel dayanakları Bilgi güvenliği aşağıdaki unsurlara dayanmaktadır: Gizlilik sadece kullanıcıya izin verilen bilgiye erişim sağlama Bütünlük verilerin yetkisi olmayan kullanıcılar tarafından tahrif edilmemesini ve değiştirilmemesini sağlamak Kullanılabilirlik ihtiyaç duyulması halinde yetkisi olan kullanıcıların sistem ve verileri kullanabilmesi Aşağıdaki ilkeler ise bu üç dayanakla bağlantılıdır. Aslında, kontrolün nasıl oluşturulacağına karar verme aşamasında her dayanağı da dikkate almak, sağlam bir güvenlik kontrolü oluşturulmasını destekleyecektir. TÜBİTAK UEKAE 23

WEB UYGULAMA GÜVENLİĞİ KILAVUZU GÜVENLİ KODLAMA PRENSİPLERİ 3.4 Güvenlik Mimarisi Güvenlik mimarisi bulunmayan uygulamalar sınırlı eleman analizi ve rüzgar tüneli testi yapılmadan inşa edilen köprüler gibidir. Kesinlikle bir köprüye benzerler ancak bir kelebeğin kanatlarını ilk çırpışıyla birlikte yerle bir olacaklardır. Güvenli mimari gibi uygulama güvenliğine duyulan ihtiyaç, bina ya da köprü inşaatındaki kadar büyük ve önemlidir. Güvenlik mimarisi temel dayanaklarla ilgilidir: uygulama, sadece doğru kullanıcılar için bilgilerin gizliliğini, verilerin bütünlüğünü korumaya ve gerektiğinde veriye erişilebilirlik sağlamaya (kullanılabilirlik) yönelik kontroller temin etmelidir. Güvenlik mimarisi, güvenlik ürünleri carnucopia sının birlikte karıştırıldığı ve çözüm adının verildiği markitecture değil, titizlikle belirlenen özellik, kontrol, daha güvenli süreçler ve aksaklık güvenlik modu bütünüdür. Yeni bir uygulama başlatırken veya zaten var olan bir uygulamayı yeniden yapılandırırken her işlevsel özellik göz önüne alınmalı ve şunlara dikkat edilmelidir: Bu özellik kapsamındaki süreç olabildiğince güvenli mi? Başka bir deyişle, hatasız bir süreç mi? Eğer ben kötü amaçlı olsaydım, bu özelliği nasıl kötüye kullanırdım? Aksaklık durumunda bu özelliğin çalışır durumda olması gerekmekte midir? Eğer gerekliyse, bu özellikten kaynaklanan riskleri aza indirgemeyi sağlayacak limit ya da seçenekler mevcut mu? En iyi sistem mimari tasarımları ve ayrıntılı tasarım belgeleri, her özellik için risklerin nasıl azaltılacağına ve kodlama sırasında ne yapıldığına dair güvenlik bilgileri içerir. Güvenlik mimarları iş gerekliliklerinin modellenmeye başlamasıyla güne başlarlar ve uygulamanızın son kopyası tamamlanmadan da işlerini bırakmazlar. Güvenlik tek seferlik bir kaza değil, yaşam boyu devam eden bir süreçtir. 3.5 Güvenlik İlkeleri Bu güvenlik ilkeleri OWASP Kılavuzunun önceki versiyonundan alınmıştır ve Howard ile Leblanc ın son derece başarılı Writing Secure Code (Güvenli Kod Yazımı) adlı çalışmalarında açıklanan güvenlik ilkeleri doğrultusunda düzenlenmiştir. 24 TÜBİTAK UEKAE

GÜVENLİ KODLAMA PRENSİPLERİ WEB UYGULAMA GÜVENLİĞİ KILAVUZU 3.6 Saldırı Yüzey Alanını Küçültmek Bir uygulamaya eklenen her özellik, bütün uygulamalar için belirli oranda risk teşkil eder. Güvenli gelişimin amacı saldırı yüzey alanını daraltarak genel risk oranını azaltmaktır. Örneğin, bir web uygulaması arama işlevli online hizmet uygulamaktadır. Arama işlevi SQL enjeksiyon saldırılarına karşı korumasız olabilir. Eğer yardım özelliği yalnızca yetkisi bulunan kullanıcılarla sınırlandırılmış ise, saldırı olasılığı azaltılmış demektir. Eğer yardım özelliği merkezileştirilmiş veri geçerlilik kuralları aracılığıyla açılmışsa, SQL enjeksiyonun gerçekleştirebilme kapasitesi oldukça düşürülmüş demektir. Ancak, yardım özelliği arama özelliğini ortadan kaldırma (örneğin daha iyi kullanıcı ara alanı aracılığıyla) amacıyla yeniden yazılmış ise, yardım özelliği İnternet üzerinden büyük ölçüde erişilebilir olsa bile bu işlem saldırı yüzey alanını hemen hemen ortadan kaldıracak demektir. 3.7 Güvenli Öntanımlar Kullanıcılara sıra dışı bir deneyim yaşatmanın pek çok yolu vardır. Ancak, bu deneyimin ön tanımla güvenli olması sağlanmalıdır. Ayrıca, eğer yetkileri var ise, güvenliklerini azaltmak kullanıcıların kararına bırakılmalıdır. Örneğin, şifre eskitme ve karmaşıklığın ön tanımla yapılabilmesi sağlanmalıdır. Uygulamalarını kullanma süreçlerini basitleştirme ve risk oranlarını artırma konusunda yukarıda adı geçen iki özelliği uygulama dışı bırakmak için kullanıcılara yetki verilebilir. 3.8 En Az Öncelik İlkesi En az öncelik ilkesi, hesapların iş süreçlerini gerçekleştirmek en düşük oranda öncelik kapsaması gerektiğini önermektedir. Bu işlem, kullanıcı hakları, CPU sınırlandırmaları gibi kaynak izinleri, bellek, ağ ve dosya sistem izinlerini kapsar. Örneğin, bir aracı yazılım sunucusu, sadece ağ erişimi, veritabanı tablosunu okuma erişimi ve kayıt yazma kapasitesi gerektiriyorsa, verilmesi gereken tüm izinleri tanımlıyordur. Hiçbir koşulda bu sunucuya yönetimsel öncelikler tanınmamalıdır. TÜBİTAK UEKAE 25

WEB UYGULAMA GÜVENLİĞİ KILAVUZU GÜVENLİ KODLAMA PRENSİPLERİ 3.9 Kademeli Savunma İlkesi Kademeli savunma ilkesi, bir kontrolün akılcı olduğu durumda, riske farklı biçimlerde yaklaşan daha fazla sayıda kontrolün daha iyi olduğunu ifade eder. Kademeli olarak kullanıldıklarında kontroller, ciddi savunmasızlık durumlarınının kötüye kullanılmasını oldukça yüksek seviyede güçleştirir ve böylece oluşmalarını da engeller. Güvenli kodlama ile bu işlem dizi odaklı geçerlilik denetimi, merkezileştirilmiş denetim kontrolleri halini alabilir ve kullanıcıları bütün sayfalarda oturum açmak zorunda bırakabilir. Örneğin, üretim yönetim ağlarına erişimi doğru bir şekilde sağlıyor, yönetsel kullanıcı yetkilendirmesini kontrol ediyor ve bütün erişimi kaydediyorsa, hatalı bir yönetimsel ara yüzün isimsiz saldırılara karşı savunmasız kalması olası değildir 3.10 Güvenli Aksama Uygulamalar pek çok sebebe bağlı olarak işlemleri gerçekleştiremeyebilirler. Bu aksaklığın nasıl ortaya çıktığı, uygulamanın güvenli olup olmadığını belirleyebilir. Örneğin; isadmin = true; try { codewhichmayfail(); isadmin = isuserinrole( Administrator ); } catch (Exception ex) { log.write(ex.tostring()); } Eğer WhichMayFail() kodunda bir aksaklık ortaya çıkarsa, kullanıcı ön tanımla bir admin olur. Bu, açık bir şekilde bir güvenlik sorunudur. 3.11 Dış Sistemlerin Güvenli Olmaması Çok sayıda organizasyon, sizlerden farklı güvenlik sistem ve tutumları uygulayan üçüncü taraf ortakların işlem yapma kapasitelerini kullanmaktadırlar. Ana kullanıcılar, esas tedarikçiler ya da ortaklar olsalar da, dışarıdan üçüncü bir şahsı etkilemeniz ya da kontrol etmeniz mümkün değildir. 26 TÜBİTAK UEKAE

GÜVENLİ KODLAMA PRENSİPLERİ WEB UYGULAMA GÜVENLİĞİ KILAVUZU Bu nedenle, dışarı kaynaklı yürütme sistemlerine güven garantisi verilemez. Bütün dış kaynaklı sistemler benzer bir tutumla dikkate alınmalıdır. Örneğin, bağlı bir program tedarikçisi İnternet Bankacılığı tarafından kullanılan bir veri sunmaktadır. Bunun yanında, ödül puanlarını ve potansiyel geri alım kalemlerine yönelik küçük bir liste vermektedir. Ancak, bu verilerin en son kullanıcılara görüntülenmesinin güvenli olmasını sağlamak adına kontrol edilmesi, ödül puanlarının pozitif bir sayı olduğu ve büyük olmalarının imkânsız olduğundan emin olunması gerekmektedir. 3.12 Görevlerin Ayrımı Görevlerin ayrımı, dolandırıcılığa karşı kullanılabilecek temel bir kontrol aracıdır. Örneğin, bir bilgisayar isteyen biri aynı zamanda kayıt olamaz ya da bilgisayarı doğrudan alamaz. Böylece, kullanıcının çok sayıda bilgisayar istemesi ve eline ulaşmadığını iddia etmesi engellenmiş olacaktır. Belirli görevlerin, normal kullanıcılara göre farklı güven seviyeleri vardır. Özellikle, yöneticiler normal kullanıcılardan farklıdır. Genelde, yöneticiler uygulama kullanıcıları olmamalıdırlar. Örneğin, bir yönetici sistemi açabilmeli ya da kapatabilmeli, şifre politikasını belirleyebilmeli ancak süper öncelikli bir kullanıcı gibi depo bölümünde oturum açıp diğer kullanıcılar adına eşya satın alamamalıdır. 3.13 Belirsizlik Yolu ile Güvenliğe Güvenmeyin Belirsizlik yolu ile güvenlik zayıf bir güvenlik kontrolüdür. Tek kontrol aracı olduğu pek çok durumda da hemen hemen her zaman başarısız olur. Sır tutmanın kötü bir fikir olduğu anlamına gelmemekle birlikte, kilit sistemlerin güvenliğinin ayrıntıların gizli tutulması esasına dayandırılmaması ifade edilmektedir. Örneğin, bir uygulamanın güvenliği, gizlenen bir kaynak kod bilgisine dayandırılmamalıdır. Güvenlik pek çok etmene dayandırılmalıdır. Akla yatkın şifre politikaları, kademeli savunma, iş bağlamında işlem sınırlamaları, sağlam ağ mimarisi, dolandırıcılık ve denetim kontrolleri de dikkate alınmalıdır. Linux, oldukça pratik bir örnektir. Linux kaynak kodu geniş ölçüde erişilebilirdir. Bununla birlikte doğru bir şekilde güvence altına alındığında, zorlu, güvenli ve sağlam bir işletim sistemidir. TÜBİTAK UEKAE 27

WEB UYGULAMA GÜVENLİĞİ KILAVUZU GÜVENLİ KODLAMA PRENSİPLERİ 3.14 Basitlik Saldırı yüzey alanı ve basitlik yakından ilişkilidir. Belirli yazılım mühendisliği akımları, diğer bir şekilde doğrudan ve basit olabilecek kodlara yönelik oldukça karmaşık yaklaşımlar izlemektedirler. Daha basit yaklaşımların daha hızlı ve basit olacağı durumlarda, sistem geliştiricilerin de çifte negatif ve karmaşık mimari kullanımında kaçınmaları gerekmektedir. Örneğin, ayrı bir aracı yazılım sunucusunda çok sayıda tek varlık kullanımı çok moda olsa da, yarış durumlarına karşı korunma amacıyla uygun mutex mekanizmasıyla birlikte küresel değişkenler kullanmak hem daha güvenli hem de daha hızlıdır. 3.15 Güvenlik Sorunlarını Uygun Şekilde Ele Almak Bir güvenlik sorunu belirlendiğinde, sorun için bir test süreci oluşturmak ve soruna yol açan esas meselenin anlaşılması önemlidir. Tasarım biçimleri kullanıldığında, güvenlik sorununun bütün kod tabanlarına yayılmış olması olasıdır. Bu nedenle gerilemelere yol açmadan doğru çözüm yolunu geliştirmek esastır. Örneğin, bir kullanıcı, oturum bilgilerini uyumlaştırarak diğer bir kullanıcının bakiyesini görebilmektedir. Direk çözüm yolu ortadadır, ancak oturum bilgisi kullanım kodu bütün uygulamalar tarafından paylaşılmaktadır, bu nedenle yalnızca bir uygulama üzerinde yapılacak değişiklik bütün diğer uygulamaları etkileyecektir. Çözüm yolu, etkilenen bütün uygulamalar üzerinde denenmelidir. 28 TÜBİTAK UEKAE

TEHDİT RİSK MODELLEME WEB UYGULAMA GÜVENLİĞİ KILAVUZU 4. TEHDİT RİSK MODELLEME Uygulamanızı tasarlarken, en çok önem vermeniz gereken tehdit, riski tayin edilmiş kontrolleri kullanmaktır. Aksi halde kaynaklarınızı, zamanınızı ve paranızı gereksiz kontroller için boş yere harcarsınız ve bu gerçek riskler için yeterli değildir. Riskleri belirlemek için kullandığınız metot, yapılandırılmış tehdit riskleri modellemesi yapmanız kadar önemli değildir. Microsoft, güvenlik geliştirme programının en önemli ilerlemesinin, tehdit modellemesine evrensel bir uyum sağlaması olduğunu belirtmiştir. OWASP, Microsoft un tehdit modelleme yöntemini, uygulama güvenliğinde nadir olarak karşılaşılan sorunları iyi çözebilmesi ve tasarımcılar, geliştiriciler ve kodu kontrol eden kişiler tarafından kolay uyum sağlanıp öğrenilmesinden dolayı seçmiştir. Tehdit modelleme, güvenli web uygulamalarının gelişimi için temeldir ve organizasyonların doğru kontrolleri belirlemesini ve bütçe içinde etkili karşı tedbir oluşturmasını sağlar. Örneğin; ihmal edilebilecek kadar hilesi olan bir sisteme 100,000 dolarlık bir kontrol eklemek. 4.1 Tehdit Riskleri Modellemesinin Yapılması Tehdit modelleme yönteminde beş aşama bulunmaktadır. Microsoft tehdit ağaçlarını takip etmeyi ve göstermeyi destekleyen.net ortamında yazılmış bir tehdit modelleme aracı sağlar. Bu aracın kullanımı büyük ve uzun ömürlü projeler için yardımcı olabilir. TÜBİTAK UEKAE 29

WEB UYGULAMA GÜVENLİĞİ KILAVUZU TEHDİT RİSK MODELLEME 4.2 Tehdit Model Akışı Şekil 4-1 Tehdit model akış diyagramı 4.3 Güvenlik Hedeflerinin Belirlenmesi Şirketler (veya topluluk başkanlıkları) güvenlik hedeflerinin belirlenmesinde geliştirici takım ile hem fikir olmalıdır. Uygulamaların güvenlik hedefleri aşağıdakilere ihtiyaç duyar: 30 TÜBİTAK UEKAE

TEHDİT RİSK MODELLEME WEB UYGULAMA GÜVENLİĞİ KILAVUZU Kimlik: Bu uygulama kullanıcının kimliğini suistimallere karşı koruyor mu? Kimliğin doğruluğuna emin olmak için yeterli kontroller var mı? (Birçok banka uygulaması için gereklidir.) İtibar: Suistimal edilmiş veya saldırıya uğramış uygulamaların neden olduğu itibar kaybı Mali: Risk seviyesindeki şirketler potansiyel mali kayıpları iyileştirmek için yatırım yapmalıdırlar. Forum yazılımları ortak internet bankacılığından daha az mali risk taşır. Gizlilik ve düzenleme: Kullanıcının bilgilerinin ne kadar kapsamlı korunduğudur. Forum yazılımı yapısı gereği herkes tarafından görülebilir, fakat bir vergi programı birçok ülkede vergi düzenlemeleri ve gizlilik kanunlarıyla sınırlandırılmıştır. Kullanılırlık garantileri: Bu yazılım SLA veya benzer bir anlaşma tarafından tanınması gerekli midir? Ulusal olarak korunan bir altyapısı var mı? Hangi aşamada uygulamayı kullanmak gereklidir? Çok kullanılan uygulamalar ve teknikler aşırı derecede pahalıdır. Bu yüzden, doğru kontrollerin kurulması büyük ölçüde zaman, kaynak ve para kaybını önler. Bu ayrıntılı bir liste sayılamaz fakat kurulmuş teknik kontrolleri yürüten şirketin risk kararlarına dair bir fikir verir. Risk kılavuzunun diğer kaynakları bunlardır: Yasalar(gizlilik yasası veya mali yasalar gibi ) Düzenlemeler(bankacılık veya e-ticaret düzenlemeleri gibi ) Standartlar (ISO 17799, 270001 ve COBIT gibi) Yasal Anlaşmalar ( ticari anlaşmalar gibi) Bilgi Güvenliği Politikası 4.4 Uygulamanın Gözden Geçirilmesi Güvenlik hedefleri tanımlandığında, aşağıdakileri belirlemek için uygulama analiz edilmeli: TÜBİTAK UEKAE 31

WEB UYGULAMA GÜVENLİĞİ KILAVUZU TEHDİT RİSK MODELLEME Uygulamanın Kısımları Veri Akışı Güvenlik Sınırları Bunu yapmanın en iyi yolu uygulamanın yapısı ve tasarım dokümanlarını incelemektir. Uygulamanın kısımlarının UML şemalarına bakılmalıdır. Uygulamanın en üst kısmının şemaları genellikle veri akışının çeşitli yerlere neden ve nasıl olduğunun anlaşılması için gereklidir. Güvenlik sınırı ile çakışan veri (İnternette kaynak kod veya şirket mantığında veritabanı sunucusu gibi) dikkatlice analiz edilmeliyken aynı güvenlik seviyesinde akan verinin tekrar kontrol edilmesine gerek yoktur. 4.5 Uygulamayı Ayrıştırma Uygulamanın yapısı anlaşıldığında, uygulama ayrıştırılmalıdır. Bunun anlamı güvenlik etkisine sahip bütün özelliklerin ve kısımların ayrıştırılmasıdır. Örneğin; doğruluğu kanıtlanmış bir kısım araştırılırken, verinin bu kısma nasıl girdiği, bu kısmın veriyi nasıl onayladığını, verinin akışı ve eğer veri kaydediliyorsa bu kısmın aldığı kararların neler olduğu anlaşılmalıdır. 4.6 Bilinen Tehditlerin Dokümanı Bilinmeyen tehditleri listelemek imkânsızdır ve talihsizce yeni savunmasızlıklara karşı koymak için birçok müşteri sistemi kötü niyetli yazılımlar (malware) üretmiştir. Bunu yerine, bilinen ve araçlarla ya da Bugtraq tan kolayca belirlenebilen riskler üzerinde yoğunlaşılmalıdır. Bir tehdit yazılırken Microsoft iki farklı yaklaşım önerir. Bunlardan biri tehdit grafiği, diğeri ise yapı listesidir. Tipik olarak, tehdit grafiği okuyuculara kısa sürede birçok bilgi verir, fakat yapılandırılması uzun sürer. Yapı listesi yazmak için daha kolaydır fakat tehdidin etkisinin açığa kavuşmasında daha uzun süre alır. 32 TÜBİTAK UEKAE

TEHDİT RİSK MODELLEME WEB UYGULAMA GÜVENLİĞİ KILAVUZU Şekil 4-2 Olası tehditler 1. Saldırgan diğer kullanıcıların mesajlarını okuyabilir (Paylaşılan bir bilgisayarda kullanıcı sistemden çıkmamış olabilir.) 2. Veri doğrulanması SQL girişine izin verebilir. 3. Veri doğrulanmasını gerçekleştirme 4. Yekti sistemi başarısız olabilir, yetkisiz ulaşıma izin verme 5. Yetki kontrolünü gerçekleştirme 6. Tarayıcı önbellek mesajın içeriğine sahip olabilir. 7. Önbelleğe alınmayan http başlıklarını gerçekleştirme 8. Eğer risk yüksekse SSL kullanımı Tehditler saldırganlar tarafından harekete geçirilir; onlar genellikle sizin uygulamalarınızdan veya önlenmiş kontrollerinizden bir şeyler isterler. Hangi tehditlerin uygulanabilir olduğunu anlamak, uygulamaya kimin saldırdığını anlamak için güvenlik hedeflerini kullanmak: TÜBİTAK UEKAE 33

WEB UYGULAMA GÜVENLİĞİ KILAVUZU TEHDİT RİSK MODELLEME Rastlantısal buluş: yetkili kullanıcılar uygulama mantığında tarayıcı kullanarak hataya düşerler. Otomatikleştirilmiş kötü niyetli yazılım (malware) ( bilinen savunmasızlıkları fakat bu kez biraz daha dikkatli ve akıllıca araştırmak) Meraklı saldırgan ( sizin uygulamanızda bir şeylerin yanlış gittiğini fark eden güvenlik araştırmacıları veya kullanıcıları gibi) Betik Hırsızlığı: bilgisayar suçluları saygı için veya politik sebepler yüzünden uygulamalara saldırır ve ya uygulamaları bozar- kullanılan teknikler burada ve OWASP test kılavuzunda uygulamayı uzlaştırmak için açıklandı Harekete geçmiş saldırganlar(huzursuz personel ve ücretli saldırganlar gibi) Organize suç (genellikle e- ticaret veya bankacılık gibi yüksek riskli uygulamalar) Karşı koyduğunuz saldırganların seviyesini bilmek büyük önem taşır. Örneğin, işlemlerinizi anlayan bilgili bir saldırgan bir betik hırsızından çok daha fazla tehlikelidir. 4.7 STRIDE 4.7.1 Yanıltıcı kimlik Yanıltıcı kimlik birçok kullanıcının sahip olduğu, uygulamanın anahtar risklerinden biridir. Fakat yanıltıcı kimlik uygulamada bir tane yürütme içeriği ve veritabanı seviyesi kullanır. Kullanıcılar kesinlikler başka bir kullanıcı gibi davranmamalı veya o kullanıcının yerine geçmemelidir. 4.7.2 Veriyle oynamak Kullanıcılar onlara ulaşan herhangi bir veriyi değiştirebilirler ve böylece alıcı doğrulamasını, GET ve POST verisini, HTTP başlıklarını ve bu gibi şeyleri değiştirebilirler. Örneğin, Uygulama, kullanıcıya uygulamanın kendisi tarafında bulunabilen faiz oranları veya dönemleri gibi verileri göndermemelidir. Uygulama, kullanıcıdan gelen herhangi bir verinin uygulanabilirliğini ve mantıklı olup olmadığını dikkatlice kontrol etmelidir. 34 TÜBİTAK UEKAE

TEHDİT RİSK MODELLEME WEB UYGULAMA GÜVENLİĞİ KILAVUZU 4.7.3 Reddetme Yetersiz izlenilebilirlik ve kullanıcı aktivitelerinin yetersiz denetlenmesi söz konusu ise kullanıcı işleme itiraz edebilir. Örneğin, eğer kullanıcı Parayı bu dış hesaba aktaramadım derse ve başından sonuna kadar onların aktivitelerini izleyemediyseniz, bu kesinlikle işlemin başarısız olduğu anlamına gelir. Uygulamalar yeterli reddetme kontrolüne sahip olmalıdır, web erişim günlükleri, her kattaki izlerin kontrolü ve başından sonuna kadar kullanıcı içeriği gibi. Tercihen uygulama kullanıcı tarafından çalıştırılmalıdır fakat bu birçok çatıda (framework) mümkün olmamaktadır. 4.7.4 Bilgi Açıklama Kullanıcılar özel detayları siteme girmekten sakınırlar. Eğer bir saldırganın, kullanıcının detaylarını açıklaması mümkün olursa, isimsiz veya yetkili bir kullanıcı olsa da, itibar kaybının olacağı bir süreç başlayacaktır. Uygulamalar, kullanıcılar tek bir üyelikle tüm bir programı çalıştırırken, kullanıcı ID si ile oynanmasını engellemek için güçlü kontroller içermelidir. Kullanıcının tarayıcısı bilgi sızdırabilir. Her tarayıcı, HTTP başlıkları tarafından istenen ön belleğe alınmama yönergesini uygulamaz. Her uygulama, bilginin sızdırılmaması ve bir saldırgan tarafından daha çok bilgi öğrenebilmek için kullanılamaması için tarayıcı tarafından kaydedilen bilginin miktarını minimuma indirmelidir. 4.7.5 Servis reddi Uygulamalar servisin reddettiği saldırılar tarafından kötü kullanılabileceklerinden haberdar olmalıdırlar. Onaylanmış uygulamalar için pahalı kaynaklar geniş dosyalar, karışık hesaplamalar, ağır görev araştırmaları veya isimsiz kullanıcılar için değil yetkili kullanıcılar için muhafaza edilmesi gereken sorgular gibi. Bu lükse sahip olmayan uygulamalarda, en az işi yapmak için uygulamanın bütün kesimleri yürütülmeli, hızlı veritabanı sorguları kullanılmalı ya da hiç kullanılmamalı, geniş dosyalar açığa çıkarılmamalı veya servisin reddettiği basit bir saldırıyı engellemek için her kullanıcıya özel bağlantılar (links) sağlanmalı. 4.7.6 Ayrıcalık Seviyesi Eğer bir uygulama kullanıcı ve yönetici işlevleri sağlıyorsa, kullanıcının herhangi yüksek bir seviyenin işlevlerine erişemeyeceğinden emin olmak önemlidir. TÜBİTAK UEKAE 35

WEB UYGULAMA GÜVENLİĞİ KILAVUZU TEHDİT RİSK MODELLEME Özellikle, sadece kullanıcı bağlantıları (link) sağlamamak yeterli değildir ayrıcalıklı işlevselliklere sadece doğru kişilerin ulaşabildiğinden emin olmak için bütün eylemler bir otorite matrisinden geçmelidir. 36 TÜBİTAK UEKAE

WEB SERVİSLERİ WEB UYGULAMA GÜVENLİĞİ KILAVUZU 5. WEB SERVİSLERİ Kılavuzun bu bölümünde web servisi geliştiricilerinin karşılaştığı genel konular ve bu genel konuları işaret eden metotlar incelenmektedir. Web servisleri online basında çok fazla yazıldığından gerçekten ne oldukları hakkında büyük karışıklıklar ve yanlış anlaşılmalar meydana gelmiştir. Bazıları web servislerini, Web in kendisinden sonra ortaya çıkan en büyük teknolojik gelişme olarak görürken; başka bir grup, biraz daha şüpheci yaklaşarak biraz evrimleşmiş web uygulamaları olarak görmektedir. Her iki durumda da, web uygulaması güvenliğini ilgilendiren konular web servisleri için de geçerlidir. En basit seviyede web servisleri, sunum şekli açısından farklı olan, özelleşmiş web uygulamaları olarak görülebilir. Web uygulamaları tipik olarak HTML-tabanlı iken, web servisleri XML-tabanlıdır. B2C hareketlerinin interaktif kullanıcıları normalde web uygulamalarına erişirken, web servisleri, SOA modeli kullanarak B2B zincirleri oluştururlar ve bu web uygulamaları için yapı taşları olarak kullanılırlar. Web servisleri genel olarak, programlardan çağrılabilir, kamuya açık fonksiyonel bir arabirime sahipken; web uygulamaları daha zengin özelliklere sahip olma ve çoğu zaman içeriğe bağlı çalışma eğilimindedirler. 5.1 Web Servislerinin Güvenliği Web servisleri, diğer dağıtık uygulamalar gibi farklı seviyelerde korunur: SOAP mesajları, kablolardan, gizli olarak ve üzerinde değişiklik yapılamadan dağıtılmalıdır. Sunucu kimin konuştuğu ve konuşan istemcilerinin hakları konularında emin olmalıdır. İstemciler doğru sunucu ile konuştuklarından ve bir balık ağına yakalanmadıklarından (phishing) emin olmalıdırlar. Sistem mesajlarının kayıtları olaylar zincirinin güvenilebilir bir şekilde tekrar edilebilmesi ve kimliği doğrulanmış ziyaretçileri takip edebilecek kadar yeterli bilgiye sahip olmalıdırlar. Aynı şekilde, ileriki bölümlerde incelenen ve dağıtık uygulamaların güvenliğine yönelik yüksek seviye yaklaşımları, uygulama ayrıntılarındaki ufak değişiklerle web servisleri için de geçerlidir. TÜBİTAK UEKAE 37

WEB UYGULAMA GÜVENLİĞİ KILAVUZU WEB SERVİSLERİ Web servisleri geliştiriciler için güzel haber ise bu yaklaşımlar altyapı seviyesinde görevler gerektirir, dolayısıyla, teorik olarak, bu konularla sistem yöneticilerinin ilgilenmesi gerekir. Fakat bu bölümün ileriki kısımlarında bahsedilen bazı sebeplerden dolayı, web servisi geliştiricileri en azından bu risklerden haberdar olmalı ve çoğu zaman koruma işlemine bizzat katılmalıdırlar. 5.2 İletişim Güvenliği Ortak olarak benimsenen ve daha yaygın bir şekilde uygulanan bir yargı vardır: her türlü iletişimimizi korumak için SSL kullanıyoruz ve biz güvendeyiz. Aynı zamanda, birçok makale kanal güvenliğine karşı parçacık (jeton) güvenliği konusu üzerinde yayınlanmaktadır ki bu görüşleri burada tekrarlamak anlamsızdır. Bu yüzden aşağıdaki listede kanal güvenliğini yalnız bir şekilde kullanırken ortaya çıkabilecek gizli tehlikelerin özeti bulunmaktadır: Sadece noktadan noktaya güvenlik sağlar. Birden fazla noktadan oluşan herhangi bir iletişim, bu yol üzerindeki her bir iletişimde bulunan nokta arasında ayrı birer kanal (ve güvenlik) kurulmasını gerektirir. Ayrıca güvenin geçişliliği gibi hemen göze çarpmayan konular da vardır, mesela {A,B} ve {B,C} nokta ikilileri arasındaki güven, otomatik olarak {A,C} arasındaki güveni gerektirmez. Bellek meselesi Mesajlar sunucu tarafında alındıktan sonra (kastedilen alıcı olmasa da), en azından kısa süreliğine de olsa düz yazı biçiminde bulunur. Taşınan bilginin aradaki noktalarda kayıt edilmesi veya kayıt dosyalarındaki hedef sunucu (herkes tarafından görüntülenebilir) ve yerel önbellek problemi daha da kötü hale getirir. Birlikte çalışılabilirliğin eksikliği SSL taşıma korunmasında standart bir mekanizma sağlasa da, uygulamalar kimlik bilgilerinin taşınmasında, güvenli kanaldan taşınan verinin bütünlük, gizlilik ve tazelik gibi hususlarının sağlanmasında yüksek derecede özel mekanizmalar kullanır. Farklı bir sunucu kullanmak, işlev itibariyle değişmediği halde aynı bilgileri farklı formatlarda kabul ettiği için istemcilerin değişmesine ve B2B servis zincirlerinin oluşamamasına sebep olur. Standart-tabanlı parçacık (jeton) korunumu, birçok durumda, mesaj-bazlı Web Servisi SOAP iletişim modeline karşı ileri bir alternatiftir. 38 TÜBİTAK UEKAE

WEB SERVİSLERİ WEB UYGULAMA GÜVENLİĞİ KILAVUZU Bu demektir ki, bugünkü Web Servislerinin çoğu halen kanal güvenlik mekanizmalarının bir versiyonu ile korunmaktadır ki bu tek başına basit bir iç uygulama için yeterlidir. Fakat bu yaklaşımın sınırları iyice anlaşılmalıdır ve tasarım sırasında gerekli düzenlemeler yapılmalıdır, kanal güvenliğinin mi yoksa parçacık (jeton) güvenliğinin mi, yoksa bu ikisinin bir karışımının mı bu özel durum için gerekliliği düşünülmelidir. 5.3 Kimlik Bilgilerinin Taşınması Kimlik bilgilerinin karşılıklı değiştirilmesi ve Web Servislerinde kimlik doğrulamanın yapılabilmesi için, geliştiriciler aşağıdaki konuları hedef almalıdır. Öncelikle, SOAP mesajları XML-tabanlı olduğundan, değiştirilen bütün bilgiler yazı biçiminde olmalıdır. Bu, kullanıcı adı/şifre gibi kimlik bilgilerinde sorun yaratmazken, yürütülebilir dosyalar(mesela X.509 sertifikaları veya Kerberos parçacıkları-jetons-) gönderilmeden ve alınmadan önce Base64 kodlama sistemi ile kodlanmalı ve çözülmelidir. İkinci olarak da, kimlik bilgilerinin taşınması bu bilgilerin kaybedilmesi riskini hep taşır- iletim sırasında dinlenebilir veya sunucu kayıtları incelenebilir. Bu yüzden parola veya gizli anahtar gibi bilgilerin şifrelenmiş bir şekilde gönderilmesi veya hiçbir zaman düz yazı şeklinde gönderilmemesi gerekir. Hassas kimlik bilgilerinin yollanmasındaki genel yöntem, kriptografik hash ve/veya imzalama yöntemidir. 5.4 Mesaj Tazeliğini Sağlamak Yeniden oynatma saldırısında kullanıldığında geçerli bir mesaj bile tehlike arz edebilirmesela, sunucuya istenilen işlemin tekrar yaptırılması için birkaç kez gönderilmesi gibi. Mesaj değiştirilmeye karşı yeteri kadar sağlam olsa bile, saldırı için kullanılan mesajın kendisi olduğu için (bkz. XML Enjeksiyonu bölümü.), bu saldırı mesajın tamamının ele geçirilmesi ile uygulanabilir. Yeniden yollanan mesajlardan korunmak için kullanılan genel yöntemler, ya mesajda benzersiz tanımlayıcı kullanmak ve işlenenlerin kayıtlarını tutmak veya nispeten daha kısa geçerlilik süresi kullanmaktır. Web Servisleri dünyasında ise, mesajın hazırlandığı zamanın bilgisi genellikle mesaja eklenerek iletilir ve bunun yanında fazladan bilgi de eklenebilir, örneğin mesajın sona erme zamanı veya belirli durumlar gibi. TÜBİTAK UEKAE 39