4.4.3 KİMLİK DOĞRULAMA KURGULARININ ATLATILMASI ÖZET KONU TANIMI KARA KUTU TESTI VE ÖRNEĞİ

Transkript

1 4.4.3 KİMLİK DOĞRULAMA KURGULARININ ATLATILMASI ÖZET Birçk uygulama özel bilgilere erişim veya görevi çalıştırmak için kimlik denetlemesi gerektirirken tüm kimlik dğrulama metdları yeterli seviyede güvenlik sağlamaz. İhmal, bilgisizlik veya basit ve yetersiz kalan güvenlik tehditleri nedeniyle sık sık kimlik denetleme şemaları ve kimlik denetlemelerindeki turum sayfalarını geçmek (bypass yapmak) ve dahili sayfalara direk larak erişildi. Buna ek larak, kimlik denetleme yllarını istekler ve uygulama hileleri ile sıkıştırarak geçip authentice (kimlik dğrulamasını geçmek) mümkün. Bu, URL parametresini mdifiye etmek ya da sahte turum ylu ile biçimde (frm da) ynama yaparak gerçekleştirilebilir. KONU TANIMI Kimlik dğrulama ile ilgili prblemler farklı aşamalardaki yazılım geliştirme çemberinde (sftware develpment life cycle, SDLC) bulunabilir. Mesela tasarım, gelişim ve kurulum aşamalarında. Tasarım hata örnekleri krunan uygulama bölümlerinin yanlış tanımını, güvenli kimlik denetimindeki bilgi alış verişleri için gereken güçlü şifreleme iletişim kurallarının uygulanmamasını içermektedir. Ve dahası.. Gelişim aşamalarındaki prblemler, örneğin giriş naylama fnksiynunun yanlış gerçekleşmesi veya özel dil için en iyi pratik güvenliğin izlenmemesi. Ek larak, uygulama yüklenmesi (kurulum ve cnfigure aktiviteleri) sırasında bazı srunlar var. KARA KUTU TESTI VE ÖRNEĞİ Web uygulaması kullanarak kimlik dğrulamayı atlamanın (baypas etmenin) birkaç ylu var: Direk sayfa isteği (zrla tarama)(frced brwsing) Parametrelerde değiştirme yapmak Oturum kimlik tahmini Sql Enjeksiynu (Sql Injectin) Direk sayfa isteği (Direct page request) Eğer web uygulaması sadece lgin sayfasına erişim denetimini gerçekleştirirse, kimlik dğrulama baypas edilmiş lur. Örneğin; eğer kullanıcı zrla tarama ile (frced brwsing ile) direk larak farklı bir sayfayı çağırırsa, sayfa garantili girişten

2 önce kullanıcının kimliğini dğrulamadan kntrl edilebilir. Tarayıcı adres çubuğu ile krumalı sayfaya direk erişimde bulunarak bu metdu test edebilirsiniz. Parametre Değiştirme Bir diğer srun kimlik dğrulama dizayni ile ilgili ve uygulama başarılı turumu sağladığında parametre değeri sabitlenir. Kullanıcı krumalı alanlara erişim hakkı elde etmek için kimlik dğrulama lmaksızın bu parametreyi mdifiye edebilir. Aşağıdaki örnekte URL içinde bir parametre var, fakat prxy bu parametreyi mdifiye edebilir, özellikle parametre frm elemanlarını pst ettiğinde (gönderdiğinde). /hme $nc 80 GET /page.asp?authenticated=yes HTTP/1.0 HTTP/ OK Date: Sat, 11 Nv :22:44 GMT Server: Apache Cnnectin: clse Cntent-Type: text/html; charset=is <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <HTML><HEAD> </HEAD><BODY> <H1>Yu Are Auhtenticated</H1> (Başarıyla kimlik dğrulama yapıldı!) </BODY></HTML> 2

3 Oturum kimlik tahmini Birçk web uygulaması turum kimlik değeri (sessin id) ile kimlik dğrulamayı yönetiyr. Bu nedenle eğer turum kimliği kötü niyetli kullanıcı için tahmin edilebiliyr ve kullanıcı turum kimliğini bulup uygulamada bir önceki kişinin turumunu taklit ederek izinsiz erişim kazanıyr. Aşağıdaki resimde çerezlerin değerleri düzenli larak artıyr, böylece atak yapan kişinin dğru kimlik turumunu tahmini klaylaşıyr. Aşağıdaki örnekte çerezlerin değerleri kısmen değişiyr, böylece brutefrce atağını kısıtlamayı mümkün kılıyr. 3

4 Sql Enjeksiyn (HTML Frmunda Kimlik Dğrulama) SQL Enjeksiyn en çk bilinen atak tekniğidir. Bu bölümde tekniği detayları ile açıklamıyrum. Bazı bölümlerde sql enjeksiyn tekniği açıklanmıştır. Aşağıdaki resim basit sql enjeksiynunu gösteriyr. Frmu kimlik dğrulama ile baypas etmek mümkün. GRI KUTU TESTI VE ÖRNEĞİ Bu bölümde atak yapan kişinin explit yöntemi ile ya da web depsundan (açık kaynak uygulamalar) uygulamanın kaynak kdları alabildiğini ve kimlik dğrulamaya karşı temiz atakların gerçekleşmesinden bahsedicem. Aşağıdaki örnekte (PHPBB Kimlik dğrulama açığı) 5. sıradaki unserialize() fnksiynu kullanıcının temin ettiği çerezi ve $rw dizisindeki değeri ayrıştırıyr. 10. sırada kullanıcı veritabanına md5 şifresini alıyr ve karşılaştırma yapıyr. 1. if ( isset($http_cookie_vars[$ckiename. '_sid']) 2. { 3. $sessindata = isset( $HTTP_COOKIE_VARS[$ckiename. '_data'] )? unserialize(stripslashes($http_cookie_vars[$ckiename. '_data'])) : array(); $sessinmethd = SESSION_METHOD_COOKIE; 8. } if( md5($passwrd) == $rw['user_passwrd'] && $rw['user_active'] ) 11. 4

5 12. { 13. $autlgin = ( isset($http_post_vars['autlgin']) )? TRUE : 0; 14. } PHP de In PHP a cmparisn between a string value and a blean value (1 "TRUE") is always "TRUE", s supplying the fllwing string (imprtant part is "b:1") t the userialize() functin is pssible t bypass the authenticatin cntrl: a:2:{s:11:"autlginid";b:1;s:6:"userid";s:1:"2";} REFERANSLAR Dökümanlar Mark Rxberry: "PHPBB vulnerability" David Endler: "Sessin ID Brute Frce Explitatin and Predictin" Araçlar WebScarab: WebGat: DİZİN KARŞITI/DOSYA İÇERİĞİ ÖZET Birçk web uygulaması günlük işlemleri için dsyaları kullanır yada yönetir. Girdi dğrulama methdu kullanılarak dizayn edilemez ya da yerleştirme yapılamaz, saldırgan sistemi explit edebilir, kuma/yazma dsyaları ki bunlar kabul edilmezler, değişik durumlarda gelişi güzel kd ile ya da sistem kmutları ile çalıştırmak mümkün. KONU TANIMI Web sunucuları ve web uygulamaları kimlik dğrulama mekanizmasını dsya ve kaynakların erişim kntrl sırasına göre gerçekleştirirler. Web sunucuları kullanıcıların kök (rt) dizinindeki dsyaların içini ve ya web döküman dizinini (web dcument rt) sınırlandırır ki bu dizin fiziksel dsya sistemidir. Kullanıcı web uygulamasında hiyerarşik yapıdaki temel dizin lan bu dizini dikkate alır. Access Cntrl Lists (ACL) (giriş kntrl listesi), sunucudaki özel dsyalara tanımlanmış kullanıcı ve kullanıcı grupları erişebilir, mdifiye ya da çalıştırma yapılabilir anlamına gelir. Bu mekanizma hassas dsyalara kötü niyetli kullanıcının (Linux'teki genel /etc/passwd gibi) erişimini ve sistem kmutlarını çalıştırmasını engellemek için dizayn edilmiştir. Web uygulamaları farklı içerikteki dsyalarda sunucu taraflı betikleri (server side scripts) kullanır. Genel larak bu metd grafikleri yönetmek, şablnlar (templates), statik yazı yükleme ve bunun gibi işlemleri kullanır. Malesefki, bu uygulamalar eğer dğru girdi parametreleri (frm parametreleri, çerez değerleri (frm parameters, ckie values)) lmazsa güvenlik açıklarının patlamasına neden luyr. Web sunucularında ve web uygulamalarında bu tarz prblemler dizin dlaşımı/dsya içeriği ataklarını yükseltir. Bu gibi açıkları explit etmek saldırgana dizini kuyabilme ve nrmalde izni lmayan bilgilere dışarıdan erişebilme sağlar. 5

6 OWASP Testing Guide'ın amacı, web uygulamaları ve web sunucuları tehditlerini göz önünde bulundurur ve kuyuculara bundan dahada ötesini sağlar. Bu tür atak (dt dt slash../ larak bilinir), yl gezimi, dizinlere çıkış, geri izlemedir. Dt dt slash, path traversal, directry climbing, backtracking. Değerlendirme süresince directry traversal'ı ve file include kusurlarını keşfedicez. Bunun için 2 farklı aşamaya ihtiyacımız var: (a) Input Vectrs Enumeratin (her girdi vectrünü sistematik eleme) (b) Testing Techniques (her atak tekniğini ve saldırganın kullandığı açığı explit etmeyi sistemli eleme) KARA KUTU TESTİ VE ÖRNEĞİ (a) Input Vectrs Enumeratin Input validatin bypassing'de (Girdi Dğrulama Baypasında) uygulamanın hangi parçasının açığının lduğunu bulmak için test eden kişi tüm parçaları tek tek numaralandırır ve hangisinin içeriğinin kullanıcı tarafından kabul edildiğine bakar. Bu ayrıca HTTP GET ve POST queryleri içerir ve dsya yüklemelerindeki ve HTML frmlarındaki genel ayarlardır. Bu aşamadaki örneklerinin içeriği: HTTP isteklerindeki dsya ilişkileri parametreleri tanımak. Garip dsya uzantıları İlginç değişken isimleri Web uygulamalarındaki dinamik nesilli sayfa ya da şablnlar için tanımlanmış çerezleri kullanmak mümkün mü? Ckie: ID=d9ccd3f4f9f18cc1:TM= :LM= :S=3cFpqbJgMSSPKVMV:TEMPLATE=flwer Ckie: USER=1826cc8f:PSTYLE=GreenDtRed (b) Deneme Teknikleri Bir snraki test aşaması web uygulamasındaki giriş dğrulama fnksiynlarının analizi. Bir önceki örneği tekrar inceleyelim. Dinamik sayfa çağırılıyr. GetUserPrfile.jsp statik bilgileri dsyadan yüklüyr ve içeriği kullanıcıya gösteriyr. Saldırgan kötü niyetli kdu girebiliyr../../../../etc/passwd ve bu Linux/Unix sisteminin şifre dsyasını içerir. Böyle bir atak açıkçası mümkün, fakat sadece ve sadece dğrulama nktası başarısız lursa. Tabi dsya sisteminin uygun lması ve web uygulamasının kendi kendine dsyayı kuyabilmesi gerekli. Testin başarılı lması için, testi yapanın sistem hakkında bilgili lması ve dsya isteklerinin yerini bilmesi gerekir. /etc/passwd için ISS web sunucusunda bir istek nktası yktur. 6

7 Bu çerez örneği: Ckie: USER=1826cc8f:PSTYLE=../../../../etc/passwd Bu ek larak dsya içerikleri, sciptler ve harici websitesindeki yerlerini öğrenmeyede lanak sağlar. Bu örnek CGI bileşeni ile kaynak kdun nasıl gösterilebileceğini path traversal kullanmadan yapılabileceğini ispatlıyr. Bileşen main.cgi nrmal HTML statik dsyaları gibi aynı dizinde bulunur. Bazı bölümlerde test yapan özel karakterler kullanarak (., dt, %00, null gibi) istekleri şifreme ihtiyacı duyar. Bunu dsya uzantılasını kntrl etmek yada script çalışmasını durdurmak için yapar. İpucu: Geliştiricilerin yaptığı genel hata, her frmun kdlanacağını (frm encding) beklememek ve sadece basit kdlamaları dğrulamak. Eğer uyguladığınız test stringi başarılı lamıyrsa farklı kdlama şemaları deneyin. Her işletim sistemi farklı karakter yl ayırıcaları kullanır. Unix-like OS: rt directry: "/" directry separatr: "/" Windws OS: rt directry: "<drive letter>:\" directry separatr: "\" but als "/" (Usually n Win, the directry traversal attack is limited t a single partitin) Classic Mac OS: rt directry: "<drive letter>:" directry separatr: ":" URL kdlaması ve çift URL kdlaması %2e%2e%2f represents../ %2e%2e/ represents../..%2f represents../ %2e%2e%5c represents..\ %2e%2e\ represents..\..%5c represents..\ %252e%252e%255c represents..\..%255c represents..\ and s n. Unicde/UTF 8 Kdlaması (Sadece fazla uzun lan UTF 8 karakter kdlamasını kabul eden sistemlerde çalışır)..%c0%af represents../..%c1%9c represents..\ GRI KUTU TESTI VE ÖRNEĞİ Gray Bx (Gri kutu) yaklaşımlı analiz gerçekleştiğinde, bizde aynı methdu Black Bx (Siyah Kutu) testinde izlemeliyiz. Buna rağmen, kaynak kda tekrar baktığımızda girdi vektörlerini klayca ve kesin larak aratabiliyruz. Kaynak kdu tekrar 7

8 gözden geçirirken uygulama kdunda, bir arama yada bir şabln (biçim) aramasında basit araçlar (grep kmutu gibi) kullanabiliriz: buna fnksiynlar ve methdlar lmak üzere dsya sistemi perasynlarıda dahildir. PHP: include(), include_nce(), require(), require_nce(), fpen(), readfile(),... JSP/Servlet: java.i.file(), java.i.filereader(),... ASP: include file, include virtual,... Çevrimiçi kd arama mtrları (Ggle CdeSearch[1], Kders[2]) açıkkaynak yazılımlardaki dizin dlaşım açıklarını (directry traversal flaws) bulmaya ve bunları internette açıklamaya lanak sağlar. PHP için aşağıdakini kullanabiliriz: lang:php (include require)(_nce)?\s*['"(]?\s*\$_(get POST COOKIE) Gray Bx Test metdunu kullanarak açıkları bulabiliriz. Ki bunların bulunması ldukça zrdur ya da mümkün lsa bile Black Bx değerlendirmesi sırasında bulunabilir. Bazı web uygulamaları veritabanında değerler ve parametreler saklayarak dinamik sayfalar üretirler. Bu directry traversal stringine özel terim eklenmesine lanak sağlayabilir. Tabi uygulama bilgileri kaydettiğinde. Bu tür güvenlik açıklarını ve eklenen fnksiynların içeriği ve güvenliğindeki parametreleri bulmak kadar zrdur. Aksi takdirde mümkün değildir. Ek larak, kaynak kd tekrar gözden geçirildiğinde, fnksiynları analiz etmek ve geçersiz girdileri yakalamak mümkündür. Bazı geliştiriciler geçersiz girdiyi geçerli lacak şekilde değiştirirler, bu uyarı ve hatalardan kaçınmak içindir. Bu fnksiynlar genelde güvenlik açıkları için dayanıksızdır. Web uygulamasının aşağıdaki bilgileri içerdiğini varsayalım: filename = Request.QueryString( file ); Replace(filename, /, \ ); Replace(filename,..\, ); Testing fr the flaw is acheived by: file=...//...//bt.ini file=...\\...\\bt.ini file=..\..\bt.ini REFERANSLAR Dökümanlar Security Risks f gram 0007.html[3] phpbb Attachment Md Directry Traversal HTTP POST Injectin 12/0290.html[4] Araçlar Web Prxy (Burp Suite[5], Pars[6], WebScarab[7]) Encnding/Decding tls String searcher "grep" ŞİFRE HATIRLAMA AÇIĞI VE ŞİFRE SIFIRLAMA 8

9 ÖZET Birçk web uygulaması kullanıcının şifresini unuttuğu zaman sıfırlamasına izin verir. Bu genellikle e psta adresine şifre sıfırlama isteğinin gitmesi ya da güvenlik srusunun cevabı srularak yapılır. Bu testte bu fnksiynun gerçekleşmesini ve kimlik dğrulama şemasında bir kusur lmadığını görücez. Ayrıca uygulamanın kullanıcıya şifresini kaydetmesini (şifremi hatırla seçeneğini (remember passwrd)) kntrl edicez. KONU TANIMI Web uygulamalarının büyük çğunluğu kullanıcı şifresini unuttuğunda veya kaybettiğinde, şifresini kurtarmasını ya da sıfırlamasını sağlar. Esas prsedür değişikliği farklı uygulamalarda ldukça ağırdır ve güvenlik seviyesine bağlıdır. Fakat bu yaklaşım kullanıcının kimlik dğrulamasında her zaman alternatif bir yl larak kullanılır. En basit ve en çk kullanılan yaklaşım kullanıcının e psta adresinin istenmesi ve eski şifre ya da yeni şifrenin bu adrese gönderilmesidir. Bu şema varsayım üzerindedir ve bu kullanıcının e pstası tehlikeye atılmaz. Buda gayet güvenli bir yöntemdir. Buna ek larak, uygulama kullanıcıya gizli srusunu srabilir. Gizli sru kullanıcı tarafından belirlenen ve uygulamanın geliştiricisi tarafından belirlenen srulardır. Bu güvenlik şeması farklı bir kişinin gelip bu sruya farklı birşeyler yazarak ya da cevabı tahmin ederek kendisini kişi gibi tanıtıp bilgilere bakmasını sağlar. Mesela çk klay lan bir güvenlik srusu: annenizin kızlık syadı, ççukluk arkadaşınız..vs gibi cevabı çk klay tahmin edilebilir srular. Bunlar saldırgan tarafından çk zrlanmadan yapabileceği bir iş. Örneğin daha iyi bir sru şu labilir. favri öğretmeniniz. Bu en azından saldırganı biraz daha uğraştırabilecek ve sizin hakkınızda daha fazla bilgi sahibi lmasını gerektirecek türden bir srudur. Bir diğer genel özellik, kullanıcıya klaylık sağlamaktır. Buda şifrenin önbelleğe (cache) yerleştirilmesi ve tekrar tekrar şifre girmek zrunda kalınmamasıdır. Bu kullanıcılar için büyük bir klaylıktır. Fakat aynı makinada farklı bir kullanıcınında gelip çk rahat bir şekilde bilgilerinize erişebilmesi anlamınada gelir. KARA KUTU TESTI VE ÖRNEĞİ Şifre Sıfırlama İlk adım gizli sruyu kullanarak kntrl yapmak. E psta adresine şifrenin gizli sru srulmadan gönderilmesi demek e psta'nın %100 güvenli lduğu anlamına itimat ediyr. Eğer uygulama yüksek seviyede güvenlik istiyrsa elverişli değildir. Bir diğer değişle, gizli sru kullanılırsa bir snraki önemli adıma geçiyr. İlk nktada şifrenin sıfırlanması için kaç tane srunun cevaplanacağına ihtiyaç vardır. Uygulamaların çğu sadece kullanıcının tek bir sruyu cevaplamasına ihtiyaç duyar. Fakat bazı kritik uygulamalarda iki ya da daha fazla sru cevaplar. Tabi dğru lacak şekilde. İkinci adımda, sruları analiz etmeliyiz. Self reser sistemleri sık sık birden fazla srunun seçilmesini önerir. Saldırgan lduğunuzu varsayarak bunu yaptığınızı düşünün. Bu iyi bir imzadır. Aşağıda adım adım self reset araçlarının nasıl işlediğine bakalım. Birden fazla sru tavsiye ediliyr mu? 9

10 Eğer evetse, cevabı basit lan genel bir sru seçin. Sru: Dğum tarihiniz / Cevap: 1983 gibi. Her zaman srunuzu harfi harfine uyacak cevabı lanları seçin ve cevabınızda aynı şekilde lsun. Srunuza bakın ve ilk arabanız nedir? gibi çk seçenekli sruları seçin. Saldırgan bunun için ufak bir liste yapıcaktır fakat şanslı ise hedefi tutturur. Ne kadar tahminde bulunabileceğinizi belirleyin. Şifre sıfırlama isteği limitsiz yapılabiliyr mu? Belli bir yanlış cevaptan snra sistem kilitleniyr mu (lckut)? Lckut yani sistemi kilitlemek ya da sistemin belli bir yanlış cevaptan snra artık kullanıcının girişini kitlemesi. Bu sistem kendi içerisinde güvenlik srunları yaratabilir. Bu explit edilebilir ve Denial s Service'a neden labilir. Uygun bir sru seçin ve sruyu seçerken yukarıdaki kriterleri göz önünde bulundurun. Şifre sıfırlama aracı nasıl hareket eder? Anında değişikliğe izin veriyr mu? Eski şifreyi gösteriyr mu? Önceden tanımlanan e psta adresine şifreyi gönderiyr mu? En iyi tehlikeli senary, eğer şifre sıfırlama aracı size şifreyi gösteriyrsa; bu saldırgana hesaba giriş yapabilme yetkisi verir, ve uygulama en sn giriş bilgilerini ağlar, kurban hesabının ya da bilgilerinin tehlikede lduğunu bilmez. Daha az tehlikeli lan senary, eğer şifre sıfırlama aracı kullanıcı tarafından zrlanırsa hemen şifreyi değiştirir. Fakat ilk senary kadar tehlikeli ve çalınabilir değildir. Saldırganın erişim kazanmasına ve gerçek kullanıcıyı sistemden atmasına izin verir. En iyi güvenlik; eğer şifre sıfırlama yapıldı ise kayıtlı lduğu e psta'ya gönderilir ya da başka bir e psta adresine; bu deneme saldırganın sadece hangi e psta lduğunu tahmin etmesi değil aynı zamanda hesaptan uzaklaşmasına ve kntrlü kaybetmesine neden lur. Anahtar başarıyla explit ediliyr ve sru ile cevabı yerleştirilerek şifre sıfırlama baypas ediliyr. Her zaman size göre istatiksel larak en iyi lan ve cevabı çk değişkenli lan srulara bakın. (tabi cevabında klay lmaması durumunda). Sn larak şifre sıfırlama aracı sadece en zayıf srunun en güçlüsüdür. Küçük bir nt larak, eğer uygulama eski şifreyi size açık text larak gönderir ya da gösterirse bu demek luyr ki şifre hash frmunda saklanmıyrdur. Buda uygulamanın kendi srunudur. Şifre Hatırlama Şifremi hatırla mekanizması aşağıdaki 2 şekilde gerçekleşir: 10

11 1. Web tarayıcısının cache passwrd dediğimiz şifreyi bellekte saklamaya izin vermesiyle. Buna rağmen uygulama mekanizması direk larak bunu yapmaz, buna sizin izin vermeniz gerekir. Yani web tarayıcınızdan bunu yasaklayıp izin verebilirsiniz. 2. Kalıcı çerez larak saklanabilir. Şifre şifrelenmeli ya da açık metin (cleartext) larak gösterilmemelidir. İlk methda göre, aşağıdaki giriş sayfası HTML kdunu kntrl edin ve tarayıcının şifreyi hatırlama kısmının devredışı lduğunu görün. <INPUT TYPE="passwrd" AUTOCOMPLETE="ff"> Otmatik şifre tamamlama her zaman devredışı lmalıdır., özellikle hasas uygulamalarda, saldırgan eğer tarayıcı belleğine erişebiliyrsa şifreyi açık metin larak (lduğu gibi) görebilir. İkinci methdu kntrl ettiğimizde saklanan çerez tarayıcı tarafından incelenir. Kimlik dğrulaması açık metin larak saklanmaz, ama hashlanır, yani bzulur (kırılmaması için). Hash mekanizmasını inceleyelim: eğer açık larak görünüysa hashlanmış şifre, bunun güçlülüğü kntrl edilir. Kendi hash fnksiynları birkaç kullanıcı adı deneyerek klayca tahmin edilecek bir fnksiyn lup lmadığını kntrl eder. Ek larak, turum açma sırasında kimlik bilgileri dğrulanır ve uygulama her istek için hepsini beraber gönderir. GRI KUTU TESTI VE ÖRNEĞİ Bu test sadece fnksiynel özellikli uygulamadır ve HTML kdu her zaman client'in içindedir. Gray Bx (Gri kutu) testi aynı ana hatlarda bir önceki paragrafı izliyr. Kural dışı tek durum çerezdeki şifre şifrelenmiştir. Bu aşağıdaki linkte tanımlanmıştır. Ckie and Sessin Tken Manipulatin OTURUM KAPATMA VE TARAYICI BELLEK YÖNETİM TESTİ ÖZET Bu bölümde turum kapatma fnksiynunun işleyişini ve turum kapandıktan snra tekrar kullanılıp kullanılmadığını kntrl ediyruz. Ayrıca uygulamanın kullanıcının belli bir süre aktiflik göstermediğinde tmatik turum kapatmasını ve tarayıcı belleğinde herhangi bir hassas bilginin kalıp kalmadığını kntrl edicez. KONU TANIMI Web turumunun snunda genellikle 2 lay başlar: 11

12 Kullanıcı turum kapatır. Kullanıcı belli bir süre aktiflik göstermediğinde uygulamanın tmatik larak turum kapatır. İki durumda dikkatli gerçekleşmelidir ve zayıflık hakkında bilgilendirmeden kaçınmak gerekir ki bu durum saldırgan tarafından explit edilebilir ve erişim hakkı kazandırabilir. Daha özele inersek turum kapatma fnksiynu tüm turum belirtilerini (en basitinden çerezleri) yketmeli ya da kullanılamaz yapmalıdır. Ayrıca sunucu tarafınında bu belirtilerin tekrar kullanılmasını yasaklaması gerekir. Nt: En önemli şey sunucu tarafında uygulamanın geçersiz kılınmasıdır. Şu demek luyr: Kd kendine uygun metdu çağırır, mesela Java'daki HttpSessin.invalidate() veya.net'teki Sessin.abandn() gibi. Tarayıcıdan çerezler silinir ama tam anlamıyla gerektiği gibi silinmez. Fakat bu sunucu tarafında turum için yine geçersizdir ve tarayıcının çerezleri tutması saldırganın hiçbir işine yaramaz. Eğer bazı laylar yerine getirilmezse saldırgan bu turum belirtilerini tekrarlatabilir. Buna ckie replay attack (ressurrect) yani yeniden canlandırmak denir. Böylece yasal kullanıcının turumunu neredeyse aynı turum gibi taklit ederek geri getirir. Tabiki, hafifletici faktör saldırganın bu çerez gibi belirtilere gereksinim duydugu erişim. (ki bu belirtiler kurbanın bilgisayarında saklanır.) Ama bu değişik durumlarda çk zr değil malesef. Bu atak için en genel senary açık bilgisayarın bazı özel bilgileri içeren yerlere giriş yetkisinin lmasıdır. Örnek larak, webmail, bankacılık, nline işlemler..vs: kullanıcı bunu bitirdiğinde uygulama turumu kapatır, eğer turum kapatma işlemi düzgün şekilde işlemiyrsa devamında gelen kullanıcı aynı hesaba tekrar erişim yapabilir. Örneğin; basit bir butn gibi görünü geri butnu (back buttn). Farklı bir senary larak çapraz site açığından (Crss Site Scripting vulnerability) ya da %100 krunmayan SSL böyle bir laya neden labilir. Kusurlu turum kapama fnksiynu uzun süreli çerezlerin çalınmasına neden lur ve hayatı saldırgan için klaylaştırır. Bu knunun 3. testi, uygulamanın tarayıcı belleğindeki hassas bilgileri yasaklamasını, ve bunların kullanıcının uygulamaya genel bir bilgisayardan erişerek tekrar tehlikeli davranışlarda bulunmasını kntrl ediyr. KARA KUTU TESTI VE ÖRNEĞİ Oturum kapatma fnksiynu: İlk adım turum kapatma fnksiynunun varlığının test edilmesi. Oturum kapatma butnunu ve bu butnun görülebilir lduğunu kimlik denetimi isteyen tüm sayfalarda kntrl edin. Ya da sadece bazı güvenilir sayfalarda lduğunu kntrl edin. Çünkü açıkça görünür lmayan butn eğer kullanıcı turumunu snlandırmayı unutursa güvenlik riski luşturabilir. İkinci adım turum belirtilerinin kullanıcı lgut butnunu çağırdığında ne lduğunu kntrl etmeye dayanır. Örneğin, çerezler uygun şekilde kullanıldığında yeni set ckie direktifi ile tüm turum çerezleri silinir. Set ckie direktifi çerezlerin değerini değersiz hale getirir (null (bş) ya da başka bir değer yapar). Ve eğer çerez devamlı (sürekli) ise bitiş tarihi geçmiş bir zamana ayarlanır ve tarayıcıya bu çerezden vazgeçmesi söylenir. Böylece eğer kimlik dğrulama sayfası rjinal çerezi aşağıdaki yl ile yerleştirirse: Set-Ckie: SessinID=sjdhqwy938eh1q; expires=sun, 29-Oct :20:00 GMT; path=/; dmain=victim.cm turum kapama fnksiynu aşağıdaki isteği başlatmalıdır: 12

13 Set-Ckie: SessinID=nauth; expires=sat, 01-Jan :00:00 GMT; path=/; dmain=victim.cm İlk ve basit lan test bu nktada turum kapatmaya ve snra tarayıcının geri butnuna basmaya dayanır. Kntrl için hala kimlik dğrulamış lmamız gerekir. Eğer öyleysek, bu demek luyrki turum kapama butnu güvensiz şekilde çalışıyr, ve turum ID'sini yketmiyr. Bu bazen uygulamaların devamlı lmayan çerezler kullanması ile lur ve çerezlerin etkili şekilde hafızadan silinmesi için kullanıcının tarayıcıyı kapatması gerekir. Bazı uygulamalar kullanıcıyı uyarır, tarayıcıyı kapatmalarını önerir. Fakat bu çözüm tamamen kullanıcının davranışına güvenir. Snuçlar aşağı seviye güvenlikte ykedilen çerezler ile karşılaştırılır. Diğer uygulamalar JavaScript kullanarak kapatmaya çalışabilirler, ama snuç yine istemcinin davranışına güvenir. Dğal larak bu, istemci tarayıcının çalışacak scriptlere limit kyarak knfigüre etmesi ile daha az güvenlik demek. Üstelik bu çözümün geçerliliği tarayıcı yapana, versiyna ve ayarlarına bağlıdır. (mesela, JavaScript kdunun IE'yi başarıyla kapatıp Firefx'u bu kadar başarılı kapataması.) Eğer geri tuşuna basılınca bir önceki sayfaya giriş yapabiliyrsak (ama yeni lana değil), basit larak tarayıcı hafızasınada erişim sağlarız. Eğer sayfa önemli bilgiler içeriyrsa bu demektir ki uygulama tarayıcının hafızalamasını yasaklamıyr. Geri butnu tekniğini denedikten snra, biraz sfistike şeyler yapmanın zamanı geldi: tekrar çerezleri rjinal değerleri ile yerleştirebiliriz ve hala kimlik dğrulamasını geçtiğimiz uygulamaya erişebilirliği kntrl ederiz. Eğer erişebiliyrsak, bu aktif ya da aktif lmayan çerezlerin sunucu taraflı bir mekanizma lmadığını gösterir. Ama bu, çerezlerinde dğru bilgiler içerip içermediğini ve erişim garantisi vermez. Kararlı çerez yerleştirmek (saptamak) için WebScarab kullanıyruz ve uygulamanın isteğini durdurur ve istediğimiz değerde Set Ckie başlığı ekleriz: Alternatif larak Ckie Editr'de yükleyebiliriz. Mesela Firefx için N Edit Ckies deneyebilirsiniz: 13

14 Dikkate değer örnek dizaynı ASP.NET FrmsAuthenticatin sınıfında kullanıcıya ait çerezin sunucu taraflı bir kntrl lmadığıdır. Çerezin temel larak nerede şifrelendiğini ve kullanıcının dğrulama versiynun çözülüğünü, ayrıca sunucu tarafından kntrl edilip edilmeğini gösterir. Bu çerezin kurcalanmasını engellemek için çk etkilidir, aslında sunucu, dahili kayıtlı turum durumuna bakmaz. Yani yasal kullanıcı turum kapattıktan snra ckie replay (çerez tekrarı) atak yapılmasını mümkün kılar. Bu da çerezin henüz geçersiz kılınmamasını sağlar. Bu test sadece turum çerezlerine uygulanmalıdır ve devamlı (sürekli) çerez sadece kullanıcı tercihlerine göre saklanmalıdır. Oturum kapandığında silinmezse güvenlik riski yaratmaz. Zaman aşımı turum kapanması: Zaman aşımı ile turum kapanmasını bir önceki bölüme benzer yaklaşım ile inceliyruz. Ayarlanan zaman aşımı turum kapatma güvenlik (kısa turum kapanma zamanı) ve kullanılırlık (uzun turum kapanma zamanı) ile uyumlu lmalıdır. Ağırlıklı larak uygulamadaki bilgi yürütülmesinin kritikliğine bağlıdır. Genel frumlarda turum kapanma süresi 60dk'dır. Fakat bazı banka uygulamalarında bu süre daha uzundur. Her uygulama zaman aşımını güvenli şekilde yerine getirmez, sadece adresleme davranışı gibi özel fnksiyn gerektirmezlerse. Test metdu bir önceki ile çk benzerdir. İlk larak zaman aşımının varlığı kntrl edilir, bunuda turum açıp herhangi birşeyi kuyarak ve ya zaman öldürerek yapabiliriz. Oturum kapatma butnunda lduğu gibi, zaman aşımı tüm turumlardaki ykedilmesi gereken ya da kullanılamayan belirtileri geçer. Ayrıca zaman aşımının istemci tarafından mı uygulandığını yksa sunucu tarafından mı yksa ikisi tarafındanda uygulandığını anlamamız gerekir. Çerez örneğimize geri dönecek lursak, eğer turum çerezi devamlı değilse zaman aşımının sunucu tarafından yapıldığına emin labiliriz. Eğer turum belirtileri bazen ilgili bilgiler içeriyrsa (turum zamanı, sn turum zamanı, devamlı çerezin bitiş zamanı..vb) istemci (client) zaman aşımında karışır. Bu durumda belirtileri (kalıntılar=tken) mdifiye etmemiz gerekir. Tabi eğer şifrelenmemişse. Mdifiyeden snra kendi turumumuzda ne lduğunu görebiliriz. Örneğin; çerezin süresini ileri bir zamana ayarlayabiliriz ve kendi turumumuzun süresini uzatabiliriz. Genel kurala göre, herşey sunucu taraflı kntrl edilmelidir ve turum çerezinin bir önceki değere göre yeniden ayarlanması, mdifiye edilmesi ve uygulamaya tekrar erişmek mümkün lmamalıdır. Hafızaya alınan sayfalar: Uygulamadan çıkmak tarayıcı hafızasında saklanan hassas bilgileri temizlemeyebilir. Bu yüzden, başka bir test uygulanır ve 14

15 uygulamamızın tarayıcı hafızasından herhangi kritik bilgi sızdırıp sızdırmadığı kntrl edilir. Bunu sırasıyla yapıcaz ve ilk larak WebScarab kullanıcaz ve turumumuza ait sunucu yanıtlarını aratıcaz. İkinci larak her sayfa için hassas bilgiler içeren sunucu talimatlarını kntrl edicez. HTTP yanıt başlıkları şu şekilde lur: HTTP/1.1: Cache-Cntrl: n-cache HTTP/1.0: Pragma: n-cache Expires: <past date r illegal value (e.g.: 0)> Alternatif larak, aynı etki HTML seviyesinedede bulunur. Her sayfa aşağıdaki kddaki gibi hassas bilgiler içerir: HTTP/1.1: <META HTTP-EQUIV="Cache-Cntrl" CONTENT="n-cache"> HTTP/1.0: <META HTTP-EQUIV="Pragma" CONTENT="n-cache"> <META HTTP-EQUIV= Expires CONTENT= Sat, 01-Jan :00:00 GMT > Örneğin; eğer e cmmerce yani elektrnik ticaret uygulaması test edersek kredi kartı numarası, finansal bilgiler içeren tüm sayfalara bakmalıyız ve bu sayfaların hafızaya saklanmadığının talimatının verilip verilmediğini kntrl etmeliyiz. Bir başka deyişle, eğer kritik bilgiler içeren bir sayfa bulursak ama tarayıcının içerikleri hafızaya almada başarısız lduğunu öğrenmemiz bu kritik bilgilerin disk üzerinde saklandığını gösterir. Bilgilerin esas yerinin nerede saklandığı istemci işletim sistemine ve kullanılan tarayıcıya bağlıdır. Örnekle gösterecek lursak eğer: Mzilla Firefx: Unix/Linux: ~/.mzilla/firefx/<prfile id>/cache/ Windws: C:\Dcuments and Settings\<user_name>\Lcal Settings\Applicatin Data\Mzilla\Firefx\Prfiles\<prfile id>\cache> Internet Explrer: C:\Dcuments and Settings\<user_name>\Lcal Settings\Temprary Internet Files> GRİ KUTU TESTİ VE ÖRNEĞİ Grikutu testi (greybx testing) karakutu (blackbx testing) testine benzer. Oturum yönetimi hakkında biraz bilgi sahibi lduğunuzu varsayıyruz ve turum kapatma ve zaman aşımı fnksiynlarını anlamanız için yardımcı lacağını düşünüyruz. Genel kural larak şunları kntrl ediyruz: Oturum kapama fnksiynu etkili şekilde tüm turum kalıntılarını ykeder ya da en azından kullanılamaz hale geririr. Sunucu turum durumu kntrlünü gerçekleştirir, saldırganın bazı kalıntıları yeniden düzenlemesine izin vermez. 15

16 Zaman aşımı uygulanır ve sunucu tarafından gerekli şekilde kntrl edilir. Eğer sunucu bitiş zamanlarını kullanırsa bu turum kalıntılarını kur ve istemciye gönderir. Kalıntılar şifrelenmiş şekilde krunmalıdır. Güvenli hafıza testi için, metd karakutu testine eşittir. Tıpkı 2 senaryda lduğu gibi sunucu yanıt başlıklarına ve HTML kduna tam erişimimiz lur. REFERANSLAR Dökümanlar ASP.NET Frms Authenticatin: "Best Practices fr Sftware Develpers" "The FrmsAuthenticatin.SignOut methd des nt prevent ckie reply attacks in ASP.NET applicatins" us; Araçlar Add N Edit Ckies (Firefx estensin): Dökümanın Aslı : OWASP TESTING GUIDE v2 Çeviri : Kadir Avcı avcikadir@gmail.cm 16

Daha göster