OWASP-SM-004: Açıkta Bırakılmış Oturum Değişkenleri

Eğer oturum token'ları açıkta bırakılırsa, saldırganın kurbanı taklit etmesine ve uygulamaya illegal yollarla ulaşmasına olanak tanır. Örneğin token'ların istemci ile sunucu arasındaki taşıma işlemini kulak kabartmalara (eavesdropping) karşı koruma altına almak önemlidir.

İstemci ile sunucu arasında Session ID geçirildiği her durumda:

• Protokol (HTTP, HTTPS gibi)
• Cache
• Özel direktifler (header'lar) ve mesaj gövdesi (POST gibi) incelenmeli.

Black Box Test:

Kriptolama ve oturum token'larının yeniden kullanımı açıklıkları testi:

• Kulak kabartmalara karşı önlem olarak genelde SSL kriptolama kullanılır.
• Adresin başındaki https:// bloğunu http:// ile değiştirip bir denemek gerekir.
• Beklenti: Her başarılı kimlik doğrulamada kullanıcı şunları beklemeli
• Farklı bir oturum token'ı almalı,
• Her talepte oturum token'ı kriptolu bir kanal üzerinden gönderilmeli.

Proxy'ler ve Cache'leme açıklıkları testi:

• Genel yaklaşım olarak oturum token'ları asla açık kanallarda taşınmamalı ve asla cache'lenmemeli.
• HTTP/1.1'in cache kontrol mekanizmaları:
• "Cache-Control:no-cache" proxy herhangi bir veriyi tekrar kullanamaz demektir. HTTP/1.0 bu direktifi tanımaz.
• "Cache-Control:Private" uygun bir direktif gibi görünse de paylaşılmamış proxy'nin veriyi cache'lemesine izin verir. Bu, internet kafe gibi yerlerde açık bir risk.
• Beklenti: Cache'in veriyi açıkta bırakmadığından emin olmak için "Expires=0" ve "Cache-Control:max-age=0" direktifleri kullanılmalı. (Önceki deneyimlerden buraya aktarabileceğimiz: Expires direktifine -1 ya da eski bir tarih de verebiliriz; aynı şekilde Cache-Control direktifine de "no-cache, no-store" değerini verebiliriz.)

GET ve POST açıklıkları testi:

• Genel yaklaşım olarak GET talebi kullanılmamalı, aksi halde Session ID firewall ve proxy loglarına açığa çıkabilir. Dahası, kurbana özel olarak hazırlanmış link göndererek XSS saldırıları rahatça gerçekleştirilebilir.
• POST taleplerinde talebin GET gibi / GET olarak yapılıp yapılamadığı test edilmeli. Örneğin bir login sayfası tarafından gönderilen şu talebe bakalım:

POST http://owaspapp.com/login.asp HTTP/1.1
Host: owaspapp.com 
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.2) Gecko/20030208 Netscape/7.02 Paros/3.0.2b 
Accept: */*
Accept-Language: en-us, en
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66 
Keep-Alive: 300 
Cookie: ASPSESSIONIDABCDEFG=ASKLJDLKJRELKHJG 
Cache-Control: max-age=0 
Content-Type: application/x-www-form-urlencoded 
Content-Length: 34

Login=Username&password=Password&SessionID=12345678

Eğer login.asp kötü implement edilmişse, şöyle bir URL ile login olmak mümkün olabilir:

http://owaspapp.com/login.asp?Login=Username&password=Password&SessionID=12345678

Taşıma açıklıkları testi:
İstemci ile sunucu arasındaki tüm etkileşimler en azından şu test kriterlerine tabi tutulmalı:

• Session ID'ler nasıl transfer ediliyor? GET, POST, form alanları (hidden alanlar dahil) vs
• Session ID'ler her zaman kriptolu bir yolla mı taşınıyor?
• Uygulama, Session ID'leri kriptosuz yollarla taşımak üzere manipüle edilebiliyor mu? Https yerine Http kullanarak mesela.
• Talep ve cevaplar (Request & Response) Session ID geçişlerinde hangi cache-control mekanizmasını kullanıyor?
• Bu direktifler her zaman var mı? Eğer yoksa, aykırı durumlar nerede?
• GET talepleri kullanılan Session ID'yi dahil ediyor mu?
• POST kullanılmışsa, GET ile değiştirilebiliyor mu?