OWASP-DV-001: Reflected XSS

XSS: Cross Site Scripting - Siteler arası betik çalıştırma
Bir XSS saldırısı şu örüntüyü kırar: Input -> Output == Cross-Site Scripting
Uygulama girdiyi doğrulamıyorsa/geçerlemiyorsa (validation) ve bizim kontrolümüzde çıktı üretiyorsa bir XSS zaafiyeti bulduk demektir.

Reflected XSS (Type 1; Non-persistent XSS):
XSS açıklığının en yaygın türüdür.
Tanım: Bir web uygulaması bu açıklığı barındırdığı zaman, talep ile gönderilen doğrulanmamış girdiyi istemciye geçirir.


Yaygın yöntem:

• Bir tasarım adımı vardır: saldırgan bir URL oluşturur ve test eder.
• Bir sosyal mühendislik adımı vardır: Saldırgan kurbanı bu URL'i kendi browser'ında açmaya ikna eder.
• Son adım: saldırgan kodun çalıştırılması - kurbanın kimlik doğrulaması ile tabi.

Genellikle saldırganın kodu Javascript kodu ile yazılır; bazen ActioScript ya da VBScript gibi farklı scripting dilleri ile de yazılır.

Saldırgan genelde işini key logger yükleyerek, kurbanın cookie'lerini çalarak, clipboard'u çalarak ya da sayfanın içeriği ile oynayarak kolaylaştırır.

Karakter encoding önemli bir konudur. Bazen uygulama "<script>" öbeğini filtreliyor fakat "%3cscript%3e" öbeğini geçiriyor olabilir; burada büyük-küçük karakterleri yerine URL encoding kullanılmış oldu.

Black Box Test:

En az 3 fazı vardır:

1. Girdi vektörlerinin belirlenmesi/keşfi.
2. Tüm girdi vektörlerinin potensiyel zaafiyetlerinin analizi. XSS zaafiyeti analizi için girdi vektörlerine özel hazırlanmış, büyük ihtimal zararsız fakat zaafiyeti açıkça gösterecek şekilde cevapları (response) tetikleyen veriler girilir. Veri bir web uygulama fuzzer ile üretilebilir ya da manuel hazırlanabilir.
3. Önceki fazda raporlanan tüm zaafiyetler için uygulamada ciddi etkileri olacak saldırılar gerçekleştirilir.

http://example.com/index.php?user=<script>alert(123)</script>

OWASP-SM-005: CSRF - 3

CSRF - Black Box Test:
Black box testi gerçekleştirebilmek için kısıtlı bölgedeki (kimlik doğrulandıktan sonra girilebilen alan) URL'leri bilmek lazım. Eğer geçerli bir credential varsa hem kurban hem de saldırgan rolleri simüle edilebilir.
Aksi durumda, eğer geçerli bir credential yoksa, legal yollardan sisteme girmiş bir kullanıcıyı hazırladığımız bir linkr tıklamaya ikna ederek gerçek bir saldırı düzenlememiz gerekir.

Her iki durumda da test şu şekilde bina edilebilir:

• "u" test edilecek URL olsun.
• "u"ya bir talep de içeren bir html sayfası hazırlanır. GET talebi için bu düz bir talep olacak, fakat POST talebi için bir takım Javascript koduna başvurmak gerekecek.
• Geçerli kullanıcının sisteme login olduğundan emin olmak gerekir.
• Kullanıcıyı "u"ya talep içeren linke tıklamak için geçerli kullanıcı ikna edilir.
• Sonuç göztlenir, mesela web sunucunun talebi gerçekleştirip gerçekleştirmediği.

CSRF - Gray Box Test

Uygulamanın oturum yönetiminin zaafiyet içerip içermediği denetlenir. Eğer oturum yönetimi sadece istemci tarafındaki değerlere dayanıyorsa (browser'a açık bilgi) uygulamada zaafiyet var demektir. "İstemci tarafındaki değerler"dan kasıt, cookie'ler ve HTTP kimlik doğrulama credential'ları (Basic authentication ve diğer HTTP kimlik doğrulamalar; uygulama seviyesi kimlik doğrulama olan form-based authentication DEĞİL). Bir uygulamanın zaafiyet içermiyor olması için URL içinde oturumla ilişkili bilgi içermeli, ki bu bilgiler kullanıcılar tarafından tanımlamamalı ya da tahmin edilememeli.

OWASP-SM-005: CSRF - 2

CSRF, şu maddelere dayanmaktadır:

1. Cookie'ler ve http kimlik denetim bilgileri gibi oturumla ilişkili bilgilerin ele alınması konusundaki web browser davranışı,
2. Saldırganın tarafında geçerli uygulama URL'leri bilgisi,
3. Sadece web browser tarafından bilinen bilgilere dayanan uygulama oturum yönetimi,
4. Varlığı anında bir http(s) kaynağına erişime neden olacak HTML tag'lerinin varlığı, "img" gibi.

İlk 3 madde açıklığın varlığı için zorunlu iken, 4. madde açıklığı exploit etmeye olanak tanır; ama mutlaka gerekli değildir.

4. madde ile ilgili sorun, şu maddelerin varlığından kaynaklanmakta:

• Sayfa içinde varlığı otomatik http taleplerine neden olacak HTML tag'leri var; "img" onlardan biri.
• Browser'a, "img" tarafından referans gösterilen kaynağın gerçekten bir resim olmadığını ve gerçekte legal olmadığını söylemenin bir yolu yoktur.
• Lokasyonu ne olursa olsun -sözde- resim yüklenir; mesela formun kendisi ve resim aynı host'ta, hatta aynı domain'de bile olmak sorunda dağildir.

Cooki'ler bu açıklığa maruz kalan tek örnek değildir; oturum bilgisi tamamen browser'lar tarafından sağlanan web uygulamaları da açıklığa maruzdur. HTTP kimlik doğrulama mekanizmaları bu kategoridedir, her talepte otomatik olarak bilgiler gönderilir. Bir kere beliren oturumla ilişkili bir bilgi üreten form-based kimlik doğrulamalar HARİÇ.

Karşı Önlemler:

Kullanıcı tarafı:

• Bir web uygulamasından iş biter bitmez logoff olunmalı.
• Browser'ın user/pwd bilgisinin kaydetmesine izin vermemeli; uygulamanın "beni hatırla" fonksiyonu kullanılmamalı.
• Hassas işlemlerin yapıldığı uygulamalar ile internette surf amaçlı gezilen uygulamalar aynı browser'da açılmamalı, bu işler için farklı browser'lar kullanılmalı.

Uygulama geliştirici tarafı:

• URL'e oturumla ilgili bilgi eklenmeli.Atağı mümkün kılan gerçek, oturumun unique olarak cookie tarafından (ki bu cookie otomatik olarak browser tarafından gönderiliyor olacak) tanımlanması. URL seviyesinde üretilmiş oturuma özel bilgiye sahip olmak, saldırganın URL'in yapısını bilmesini zorlaştıracak.

Diğer maddeler sorunu çözmeyecek fakat durumu zorlaştıracak tedbirler:

• GET yerine POST kullanılmalı. POST istekleri javascript'ler aracılığıyla simüle edilebilir olsa da saldırıyı daha karmaşık hale getirecektir.
• Konfirmasyon sayfaları (Şu yapılacak, emin misin?). Saldrıgan tarafından aşılabilir, fakat işini zorlaştıracaktır.
• Otomatik logout mekanizması.

OWASP-SM-005: CSRF

CSRF, son kullanıcıyı, login olduğu bir web uygulamasında istemediği fonksiyonları çalıştırmaya zorlayan bir saldırı türüdür. Sosyal mühendisliğin de küçük bir yardımıyla (mail yada chat yoluyla bir link göndermek gibi) saldırgan uygulama kullanıcısını kendi istediği bir fonksiyonu çalıştırmaya zorlayabilir.
Bazen CSRF saldırısı, açıklık bulunan sitede depolanabilir: Stored CSRF. Basitçe HTML kabul eden bir alanda IMG veya IFRAME etiketleri ile, ya da daha karmaşık bir XSS saldırısı ile bu depolama gerçekleştirilebilir.Eğer saldırı sitede depolanabilirse etkisi daha da artar.

ÇalışMAyan önleme teknikleri:

• Gizli bir cookie kullanmak. Tüm cookie'ler, gizli olanlar dahil, her taleple birlikte submit edilecektir.
• Sadece POST talepleri kabul etmek. Yanlış anlama şurada: Saldırgan kötü niyetli bir link oluşturamayacağından CSRF saldırısı da gerçekleştiremez. Maalesef bu kanı yanlış. Saldrıgan, kullanıcıyı POST talebi göndermek için başka yollara da sahip; saldırganın web sitesinde gizli değerler içeren basit bir form içinde mesela.

Saldırı nasıl çalışır:

Bir saldırı geliştirmek için öncelikle kurbanın çalıştıracağı kötü niyetli bir talebin nasıl oluşturulabileceğini anlamamız gerekir. Örnek üzerinde inceleyelim:

Ahmet banka.com'u kullanarak 100 TL transfer etmek istiyor. Ahmet'in oluşturacağı talep yaklaşık şöyle olacaktır:

POST http://banka.com/transfer.do HTTP/1.1
...
...
...
Content-Length: 19;

acct=NURETTIN&amount=100

Saldıray, aynı talebin şu şekilde yapılabileceğini de farkediyor:

GET http://banka.com/transfer.do?acct=NURETTIN&amount=100 HTTP/1.1

Saldıray, Ahmet'i kurban olarak kullanarak bu açıklığı exploit etmeyi düşünüyor. Önce Ahmet'in kendisine 100.000 TL transfer etmesini sağlayacak bir talep oluşturuyor:

http://banka.com/transfer.do?acct=SALDIRAY&amount=100000

Şimdi Ahmet'i bu kötü niyetli talebi submit etmeye ikna etmeli. En basit yol olarak bit html mail ile şöyle bir link gönderir:

<a href="http://banka.com/transfer.do?acct=SALDIRAY&amount=100000">Karı kız resimleri!</a>

Eğer Ahmet bu linke tıkladığında bankaya login olmuş durumdaysa transfer gerçekleşecektir. Ama Saldıray biliyor ki transfer gerçekleştiğinde Ahmet'e transferin gerçekleştiğine dair bir bilgi mesajı verilecek. Bu yüzden Saldıray saldırıyı bir "0-byte image" içine saklıyor:

<img src="http://banka.com/transfer.do?acct=SALDIRAY&amount=100000" width="1" height="1" border="0">

Eğer bu imaj etiketi mail içindeyse, Ahmet sadece browser'ın resmi render edemediğini belirten küçük bir kutu görecek. Bununla birlikte browser talebi banka.com'a gönderecek ve transferin gerçekleştirildiğine dair herhangi bir işaret de olmayacaktır.

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?

OWASP-SM-003: Oturum Sabitleme

Uygulama başarılı login sonrası cookie'yi yenilemiyorsa oturum sabitleme açığından söz edilir. Bu durumda saldırgan kullanıcının oturumunu çalabilir (session hijacking).

Şu durumda oturum sabitleme açıklıkları oluşur:

• Bir web uygulaması kimlik doğrulamayı önce var olan sessionID'yi iptal etmeden yaparsa ve bu nedenle aynı sessionID'yi kullanmaya devam ederse
• Saldırgan kullanıcıyı bildiği bir sessionID'yi kullanmada zorlayabilirse. Böylece kullanıcı login olduktan sonra saldırgan kimlik doğrulaması yapılmış oturumu kullanabilir.

Black Box Test:

Önce sayfayı talep:

GET www.example.com

Şu cevabı alacağız:

HTTP/1.1 200 OK
...
Set-Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1; Path=/; secure
...

Görüyoruz ki uygulama bir JSESSIONID set etti. Eğer şu taleple başarıyla kimlik doğrulamasından geçersek:

POST https://www.example.com/authentication.php HTTP/1.1
...
Cookie: JSESSIONID=0000d8eyYq3L0z2fgq10m4v-rt4:-1
...

Name=Meucci&wpPassword=secret!&wpLoginattempt=Log+in

Ve şu cevabı alırsak:

HTTP/1.1 200 OK
Date: Thu, 14 Aug 2008 14:52:58 GMT
Server: Apache/2.2.2 (Fedora)
X-Powered-By: PHP/5.1.6
Content-language: en
Cache-Control: private, must-revalidate, max-age=0
X-Content-Encoding: gzip
Content-length: 4090
Connection: close
Content-Type: text/html; charset=UTF-8
...
HTML data
...

Başarılı login sonrası yeni bir cookie set edilmediğinden oturum hırsızlığının mümkün olduğunu biliriz.

Sonuçta:

Kurbana geçerli bir SessionID göndeririz, kimlik doğrulama işlemini yapmasını bekleriz, kimlik doğrulaması yapılmış cookie ile sisteme gireriz.

OWASP-SM-002: Cookie Özellikleri Testi

OWASP-SM-002
Cookiler hakkında 1-2 madde:

• Cookie'lerin birinci fonksiyonu, oturum açma / yetki alma token'ı olarak kullanılması ya da geçici bilgilerin taşınmasıdır. İlaveten, HTTP durumsuz olduğundan, birden çok talep içinde durum kontrolü yapmak için kullanılır; buna en güzel örnek online alışveriştir (Kullanıcı sepete birden çok ürün ekler). 
• Response tarafından Set-Cookie direktifi ile set edilir; browser takip eden taleplerde artık bu cookie'yi uygulamaya gönderir.
• Alışveriş örneğinde ürün, fiyat, miktar gibi bilgileri tutar. Tutulan bilgilerin hassasiyetinden ötürü genellikle kodlanmış ya da kriptolu olur.
• Genellikle, takip eden talepler sırasında birden fazla cookie set edilir, ";" ile birbirinden ayrılır. Örn: her bir ürün eklemede yeni bir cookie eklenir.
• Genelde kimlik denetimi için bir cookie set edilir (session token), diğer işlemler için başka cookie'ler buna eklenir.

Cookie Parametreleri:

• Secure: Cookie sadece HTTPS gibi güvenli bir kanal kullanılıyorsa gönderilir.
• HttpOnly: XSS gibi atakları engellemek için kullanılır; cookie'ye istemci tarafı scriptlerle (javascript gibi) erişilmesine izin vermez. Tüm browserların bu fonksiyonu desteklemediği unutulmamalı.
• Domain 
• Path: Örneğin bu parametre web sunucu root'una set edilirse (path=/) uygulama cookie'leri aynı domaindeki tüm diğer uygulamalara da gönderilir.
• Expires: Cookie, set edilen zamana kadar expire olmaz. Bu kalıcı cookie, expire tarihine ulaşıldığında browser tarafından silinir. Eğer bu parametre set edilmezse, cookie sadece o browser oturumu süresince geçerli olur ve oturum sonlandığında silinir.

Black Box Test:

• Secure parametresi: Cookie hassas bilgi içeriyorsa her zaman kriptolu kanallarda taşınmalı. Bu parametre set edilmezse browser cookie'nin kriptosuz kanallarla taşınmasında (HTTP gibi) sakınca olmadığını düşünür.
• HttpOnly parametresi: Her zaman olmalı, browser desteklemiyor olsa bile
• Domain parametresi: Çok gevşek olarak set edilmemeli. Eğer uygulama "app.mysite.com" adresinde yayınlanıyorsa "domain=app.mysite.com" olmalı; "domain=.mysite.com" değil.
• Path parametresi: Domain parametresi gibi bu da çok gevşek set edilmemeli. Domain parametresi olabildiğince sıkı set edilmiş olsa bile path'in root'a set edilmesi, sunucudaki daha az güvenli uygulamalara karşı açıklığa sebep olur. Örneğin uygulama /myapp/ altında yayınlandıysa "path=/myapp/" olmalı, "path=/" yada "path=/myapp" değil (sondaki / işaretine dikkat!).
• Expires parametresi: İleri bir tarihe set edilmişse cookie'nin hassas bir veri içermediğinden emin olmak gerekir.

OWASP-SM-001: Oturum Yönetimi Şeması Testi - 2

Cookie Toplama
Uygulama gezilerek alınan cookielerin, bunları set eden (Set-Cookie) sayfaların listesi çıkarılır.

• Uygulama tarafından kaç cookie kullanılıyor?
• Uygulamanın hangi parçaları cookie üretiyor yada değiştiriyor? Hangi olaylar cookieyi değiştiriyor?
• Hangi sayfalar erişebilmek ve fonksiyonlarını kullanabilmek için cookieye gereksinim duyuyor? Sayfaya eriş, sonra cookie bilgisini silerek tekrar dene.

Token Yapısı ve Bilgi Sızıntıları

• Session ID'nin hangi parçaları statik?
• Session ID içinde hangi gizli bilgiler açık-metin taşınıyor? Kullanıcı adı, IP adresi vs.
• Kolayca decode edilebilen hangi gizli parçalar var?
• Session ID yapısından hangi bilgiler elde edilebiliyor?
• Aynı login bilgileri karşısında Session ID'nin hangi parçaları statik?

Cookie Tahmini ve Rastgelelik Durumu

• Session ID tamamen rastgele mi? Mesela sonuç değerleri tekrar üretilebilir mi?
• Müteakip taleplerde aynı girdi şartları aynı Session ID'yi mi üretiyor?
• Session ID'lerin hangi elemanları zamana bağlı?
• Session ID'lerin hangi parçaları tahmin edilebilir?
• Eğer ID üretme algoritmasının tam bilgisine ve önceki Session ID'lere sahipsek bir sonraki Session ID'yi oluşturabilir miyiz?

Cookie Tersine Mühendisliği

Bir cookie'nin değişik saldırılara karşı taşıması gereken bazı karakteristik özellikleri olmalı:

1. Tahmin edilemezlik. Rastgele değerler ve/veya kriptoloji kullanılabilir.
2. Kurcalamalara dayanıklılık. IsAdmin=NO içeren bir cookieyi kurcalamak zor mu?
3. Süresi dolma (Expiration)
4. "Secure" flag. Sadece kriptolanmış kanalda taşınması için.

OWASP-SM-001: Oturum Yönetimi Şeması Testi

OWASP Testing Guide V3 - OWASP-SM-001
Kısaca özetlersek, HTTP uygulamaları durumsuzdur (stateless); bunun anlamı, bir talebin bir önceki ile hiçbir ilgisi yoktur, birbirini etkileyen zincirleme işlemler yapılamaz. Bu durum karşısında USER ID ya da COOKIE'ler kullanılarak "oturum" kavramı geliştirilmiştir. Bir kullanıcı, hareketlerin izlerini tutmak zorunda olan ve talebi yapan kullanıcıyı bilmek zorunda olan bir uygulamaya girdiğinde sunucu bir (ya da birden çok) cookie üretir ve bunu istemciye gönderir. İstemci sonraki taleplerinde bu cookie bilgisini sunucuya geri gönderir, oturum sonlanana kadar bu durum devam eder.
Bu testte istemcilere gönderilen cookielerin legal bir kullanıcı gibi sistemi kullanmaya çalışan geniş çaplı ataklara karşı dayanıklılığı test edilir. Ana hedef, uygulamanın geçerli olduğunu düşündüğü sahte bir kullanıcı cookiesi oluşturmak ve uygulama kabiliyetlerine izinsiz erişebilmek.

Genelde bir atak örüntüsünün ana adımları şunlardır:

• Cookie toplama (Yeter sayıda geçerli cookieler toplamak)
• Cookie üzerinde tersine mühendislik (Cookie üretim algoritması analizi)
• Cookie menipülasyonu (Geçerli bir cookienin sahtesini oluşturmak - çok sayıda deneme gerektirebilir)

Black-Box Test:

İstemci ile uygulama arasında en azından şu kriterler test edilmeli:

• Tüm "Set-Cookie" direktifleri "Secure" olarak işaretlenmiş mi?
• Herhangi bir cookie operasyonu kriptolanmamış bir yolda taşınmış mı?
• Cookie, kriptolanmamış bir yolla taşınmaya zorlanabilir mi?
• Eğer zorlanabilirse, uygulama güvenlik bakımını nasıl yapmalı?
• Kalıcı cookieler var mı?
• Kalıcı cookielerde nasıl bir "Expires=zaman" kullanılmış. Bu kullanımların geçerli bir açıklaması var mı?
• Geçici olması beklenen cookieler nasıl konfigüre edilmiş?
• Cookieyi korumak için hangi Cache-Control ayarları kullanılmış? Hem HTTP/1.1, hem HTTP/1.0 için.

OWASP: Test Teknikleri

Manüel araştırma ve gözden geçirmeler.
Avantajları:

• Teknoloji desteklenmesi gerekliliği yoktur
• Farklı gruptan şartlara uygulanabilir
• Esnektir
• Takım çalışmasına uygundur
• SDLC'nin (Software Development Life Cycle => Define-Design-Develop-Deploy-Maintain) erken zamanlarında kullanılır.

Dezavantajları:

• Zaman alabilir
• Her zaman destekleyen materyal yoktur
• İnsanın etkili düşünmesi ve yeteneği önemlidir.

Tehdit Modelleme

Sistem tasarımcılarına sistemlerinin karşılaşabileceği güvenlik tehditleri üzerinde düşünmede yardımcı olmak için popülerlik kazanmıştır. Bu nedenle uygulamalar için risk değerlendirme gibi görünür. SDLC'nin mümkün olan en erken dönemlerinde model çıkarılmalı ve döngünün her döneminde tekrar gözden geçirilmelidir.

Avantajları:

• Sisteme saldırgan gözüyle bakılır
• Esnektir
• SDLC'nin erken zamanlarında kullanılır.

Dezavantajları:

• Göreceli olarak yeni bir teknik
• İyi model iyi yazılım anlamına gelmiyor!

Kaynak Kod İnceleme

Avantajları:

• Bütünlük ve geçerlilik
• Kesinlik
• Hız (Deneyimli ve becerikli inceleyiciler çaısından)

Dezavantajları

• Yüksek yetenekte güvenlik geliştiricileri gerektirir
• Derlenmiş kütüphanelerdeki durumlar gözden kaçırılabilir
• Run-time hataları kolayca anlaşılamaz
• Deploy edilen kod, incelenenden farklı olabilir

Sızma Testi

Avantajları:

• Hızlı (ve bu sayede ucuz) olabilir
• Kaynak kod incelemeye göreceli olarak daha düşük yetenek seviyesi gerektirir
• Yayınlanan kodlar test edilir

Dezavantajları:

• SDLC içinde çok geç bir zamanda yapılır
• Sadece ön çarpma testi yapılır.

Web'deki BÜYÜK Tehlike: CSRF - Ulusal Bilgi Güvenliği Kapısı

Web'deki BÜYÜK Tehlike: CSRF - Ulusal Bilgi Güvenliği Kapısı

Yusuf Çeri tarafından hazırlanmış ve https://www.bilgiguvenligi.gov.tr sitesinde yayınlanmış CSRF makalesi:

Günümüzde, İnternet kullanımı hayatımızın önemli bir parçası haline geldi ve günlük hayatta yapılan işlerin birçoğu İnternet üzerinden yapılıyor. Bu işler arasında bankacılık işlemleri, alışverişler, mail gönderimleri gibi kişisel bilgi içeren önemli işlemler örnek gösterilebilir. İnternet'in kullanımının önem kazanmasıyla beraber bu uygulamaların geliştirilmesi sırasında yapılan hatalardan faydalanma teknikleri de ortaya çıktı. Bu tekniklerden biri de kullanıcıların bilgilerini çalınmasına, değiştirilmesine neden olan bir saldırı yöntemi olan CSRF(Cross-Site Request Forgery)’dir. CSRF saldırısı, web uygulamalarının geliştirilmesi aşamasında yapılan basit bir hatadan faydalanılmasıyla oluşur.

CSRF nedir?

CSRF, “siteler arası istek sahteciliği” anlamında olup “Cross Site Request Forgering” deyiminin baş harflerinin kısaltılmış halidir. Saldırı, herhangi bir son kullanıcının, kullandığı uygulamada isteği dışında işlemler yaptırtılmasıyla gerçekleştirilir. CSRF saldırıları, “Sleeping-giant” yani uyuyan dev olarak adlandırılıyor[1] çünkü İnternet'te bulunan birçok sitede, bu saldırıya karşı herhangi bir koruma mevcut değildir, geliştiriciler ve web güvenlikçileri tarafından arka plana bırakılmış[2] oluşturabileceği zaafiyetler önemsenmemiştir. Fakat, bu açıklığın bulunduğu bir site kolayca ortaya çıkarılıp çok kolay bir şekilde saldırı gerçekleştirilebilir ve sonuçları da ağır olabilir. CSRF, Daha önce yapılan farkındalık anketlerinde en az bilinen web saldırı çeşidi olarak karşımıza çıkmaktadır[3]. Kullanıcıların İnternet banka hesabından para transferi, email hesabının ayarlarını değiştirme, e-posta gönderme CSRF saldırısı ile yapılabilecekler arasındadır. Buna karşın saldırıyı önlemek için uygulanması gereken teknikler de basittir [2].

Güvensiz kod yazımı ve CSRF’den Faydalanma

Sitelerdeki CSRF saldırısına neden olan zaafiyetin temelinde geliştiricilerin uygulamayı geliştirme aşamasında, istemci tarafından gelen her isteğin gerçekten kullanıcıdan geldiğini düşünmeleri yatıyor. PHP ile hazırlanmış örnek bir alışveriş sitesiyle saldırı daha iyi anlaşılacaktır. Site ulaşım için aşağıdaki adresi kullanıyor olsun;

http://ww.shopping.com

Sitede bir kullanıcı, hesabıyla oturum açıp alışveriş yapabilsin. Alışveriş sırasında sepete ekleme yapılabilsin ve sepettekiler silinebilsin. Sepettekilerin silinebilmesi için aşağıdaki gibi bir kod parçacığıyla itemciden istek geldiği düşünülsün.

<form action="admin.php" method="GET">
<input type="hidden" name="cmd" value=”deleteall”/>
<input type="submit" value="delete" />
</form>

Burada GET isteği ile sunucuya, kullanıcı alışveriş sepetindekileri silmesini isteyen parametre gönderiliyor. Sunucu tarafında oturum kontrolü yapılıyor ve geçerli bir oturumdan geldiği için istek yerine getiriliyor. 

Bir saldırgan burada bulunan açıklıktan faydalanmak için bir web sitesi hazırlıyor. Hazırlamış olduğu sayfa içerisine açıklığın bulunduğu alışveriş sitesine istek yapmayı sağlayan “<img>” etiketi koyuyor. Kaynak değeri olarak alışveriş sitesinde kullanıcı sepetini boşaltan istek adresi konuyor. “<img>” etiketi, “width” ve “height” değerleri ayarlanarak sayfada gösterilmiyor. Sonuçta sayfa açıldığında alışveriş sitesine kullanıcı sepetini sil isteği gönderilecektir. İstek, geçerli kullanıcı hesabından gelmemişse herhangi bir işlem yapılmayacak, geçerli bir kullanıcı hesabından gelmişse işlem yapılacaktır. Saldırganın hazırlamış olduğu sitenin adresi

http://www.attacker.com/index.html

olsun. Sayfa içerisine aşağıdaki kod parçacığı konulsun:

<html>    
    ...

<img src=www.shopping.com/admin?cmd=deleteall width=0 height=0 />
    ...
<html>

CSRF için bir saldırı senaryosu şu şekilde gerçekleşecektir; bir kullanıcı alışveriş sitesinde kendi hesabıyla oturum açıyor ve sitede gezinmeye başlıyor ve sepetine bazı şeyler ekliyor. Bu sırada saldırganın hazırlamış olduğu betik içeren sayfayı açıyor. Saldırganın hazırlamış olduğu sayfada bulunan <img> etiketi ile sepetindekileri silecek istek alışveriş sitesine gönderiliyor ve kullanıcı sepeti boşalıyor. Burada kullanıcının oturum bilgisi isteğin oturum bilgisi olarak isteğe eklendiğinden yetkilendirme ile ilgili bir problem ortaya çıkmayacaktır ve silme işlemi gerçekleşip işlem devam edecektir.

Şekil 1: CSRF Saldırısı

Kullanıcının bu gönderilen istekten haberi yoktur. Burada saldırgan ciddi sonuçlar elde edebilecek başka betikler de hazırlayabilirdi. Bunun yanında bu örnekte bir “GET” isteği üretilerek saldırı gerçekleştirildi. Fakat sayfa nın “GET” isteklerini kabul etmeyip “POST” isteklerini kabul etmesi saldırının gerçekleştirilemeyeceği anlamına gelmiyor[4]. Bu durumda XMLHTTP nesnesi kullanılarak saldırı gerçekleştirilebilirdi. Buna örnek olarak her türlü güvenlik önlemi alınan İnternet ortamındaki bazı önemli denebilecek sitelerdeki CSRF zafiyeti örnek gösterilebilir. Bunların arasında, New York Times (nytimes.com), ING Direct, Metafilter ve YouTube gibi çok kullanılan siteler mevcuttur. Fakat şu anda bu sitelerdeki açıklık kapatılmış durumdadır[2]. ING Direct bankasında bulunan zaafiyet ile kullanıcı hesabından saldırgan hesabına para transferi yapılabiliyordu. Aynı şekilde saldırgan YouTube kullanıcısının favori videolarına istediği videoları ekleyebiliyor hatta kullanıcının sadece ailesinin ve arkadaşlarının izlemesine izin verdiği videolara erişebiliyordu.

CSRF Zafiyetinin Farkına Varmak

Web geliştiricileri ya da web güvenlik testi yapanlar, bir sitede CSRF saldırısına karşı bir zaafiyetin olup olmadığını anlamaları için şu şekilde bir yol takip edebilirler: Paros, Burp Suite gibi web proxy kullanılarak siteden sabit url ve POST ile yapılan istekler kaydedilir. Daha sonra kaydedilen bu istekler proxy’deki repeater özelliği ile tekrarlandığında daha önce karşılaşılan aynı sonuçlar alınıyorsa sitenin ilgili kısmında CSRF saldırısına karşı zaafiyet vardır sonucu çıkarılabilir. Bu sitenin tüm sayfaları için ya da kullanıcı için önemli sayfalarda denenerek sitedeki tüm açıklıklar bulunabilir.

CSRF Açıklıklarının Önlemleri

CSRF saldırısı yetkili kullanıcıların yapacağı aktivitelerde başarıya ulaşırsa çok daha etkili olacaktır. Bu saldırının uygulamada yetkilendirilmiş kullanıcı sayfaları için gerçekleştirildiğini düşünerek alınabilecek önlemler çıkarılabilir. Bazıları tam olarak korumasa da korumaya yardımcı bir etken olarak kullanılabilir. Bunun yanında bu metotların avantajları ya da dezavantajları vardır. Geliştirici uygulamanın kritikliğine, performansına, metodun uygulanabilirliğine göre uygun koruma metodunu seçebilir. Bu bağlamda kullanıcı oturum kontrolü saldırıyı engellemeyecektir. Çünkü, istemci tarafından zorla üretilen isteğe kullanıcının o andaki oturum bilgisi eklenecek ve geçerli oturum bilgisiyle gönderilecektir. Her sayfada, kullanıcıdan hesap bilgilerinin girilmesinin beklenmesi uygulamanın kullanım verimliliğini ciddi şekilde etkileyecektir. Sunucu tarafında alınabilecek önemler şu sekilde sıralanabilir:

1. HTTP “referer” başlığı ile sitenin kendisinden üretilen istekle istemcinin haberi olmadan başka bir site üzerinden zorla ürettiği istek ayırt edilebilir[5]. Fakat “referer” kullanılması site sahibinin arama sitelerinde daha iyi bir yer edinebilmesini sağlaması açısından faydalı olmasına karşın kullanıcıların özel bilgilerini ortaya çıkaracaktır. Bu durum da site kullanıcılarını rahatsız edebilir[6]. Bunun yanında HTTPS bağlantılarında “referer” kullanımı daha etkilidir. HTTP bağlantılarında “referer” saldırgan tarafından kullanıcı tarayıcısında kullanımını egelleyebileceğinden çok da etkili olmayacaktır.
2. GET metodunu sadece veri okunan kısımda kullanmak, verileri değiştiren isteklerde kullanmamak. Böylece IMG etiketi ve diğer GET ile yapılan saldırı yollarından korunulabilecektir. Ama POST isteği ile gelen saldırılara karşı hala zaafiyet vardır.
3. Bütün POST isteklerinde rasgele üretilen kriptografik değer üretilir. Üretilen bu değeri cookie bilgisi içinde kullanıcı bilgisayarında saklanır. Kullanıcı tarafından yapılan form gönderimlerinde form değerini ve kullanıcı cookie değerini alarak bu değerlerin aynı olması beklenir. Çünkü saldırgan sadece form değerini istedği gibi değiştirebilir bunun yanında cookie değerini bilemeyecektir, ancak tahmin etmek durumunda kalacaktır. Bu önlemin dezavantajı bir pencerede açılan aynı form sekmelerinde, açılan son formun işlem görecek olmasıdır. İlk form yeni değerin oluşturulmasıyla, değerleri eşit olamayacağından işlem yapılamayacaktır.
4. Kullanıcı oturumunda tutulan rasgele değer üretmek, bu değeri oturum bilgisinde saklamak ve istemci tarafında “hidden” değer olarak göndermek. İstemci tarafından gelen bu değerin oturumda tutulan değerle aynı olması beklenir. Aşağıda istemci tarafında gönderilen değerin kullanımı şu şekilde olabilir:

<form ...>
<input type="hidden" name="csrf value"value="8dcb5e56904d9b7d4bbf333afdd154ca">