<!--[if gte mso 9]> Normal 0 21 MicrosoftInternetExplorer4 <![endif]-->

XSS ve XSRF’deki esas problem XSS’in, XSRF açıklarının riskini artırmasıdır. Birlikte kullanıldığında birbirlerini çok iyi tamamlarlar. En büyük risk, birleştirildiklerinde, tarayıcı farklı web sitelerine gidebilir, tek bir siteyle sınırlı kalmaz. XSRF tek başına saldırganın HTTP cevabını okuyabilmesine izin vermediği için saldırının başarılı olup olmadığı bilinemez. Fakat, XSS ile birleştirildiğinde, saldırgan sonuçları kendi seçtiği bir yere yönlendirebilir ve saldırının başarılı olup olmadığını anında görebilir.

Önleme

XSRF’i fixlemek XSS’i, hatta SQL Injection ^{http://www.olympos.org/glossary/term/563 - i} ‘ı fixlemekten daha zor olabilir. Çünkü kötü amaçlı isteği kurban gönderdiğinde, isteğin saldırı olup olmadığını anlamak zor olabilir. XSRF için alınan önlemler, eğer XSS açıkları varsa etkisiz olabilir. XSRF’i engellemek demek aynı zamanda XSS saldırılarını da engellemek demektir. Giriş filtreleme XSRF saldırılarını engellemese de XSS saldırılarını önlemek için mutlaka yapılmalıdır. Giriş filtreleme, kaynağı neresi olursa olsun, uygulama tarafından kabul edilen verilere uygulanmalıdır.

XSRF önleme genelde her web uygulaması özelliğinin ve form’unun tekrar kodlanmasını gerektirir. anti-XSRF token’ları kullanarak veya CAPTCHA implemente ederek XSRF saldırılarını önleyebilirsiniz. İmplementasyonu daha kolay fakat çok etkili olmayan, yine de hiç olmamasından iyi, başka metodlar da var. Birden fazla metodun kombinasyonunun kullanılması genelde tavsiye edilmektedir. Aşağıda her bir metod anlatılmaktadır:

Yardımcı

Kurban

Anti_XSRF Nonce Token

XSRF’i önlemede hiçbir metod kesin değil fakat anti_XSRF nonce token’ları kullanmak riskin büyük bir bölümünü yokeder. Teoride, geçerli bir token saldırgan tarafından tahmin edilebilir, fakat bu gerçekte kolay bir işlem değildir. Dahası, bu metod günümüzde XSRF saldırılarını engellemede en etkili metoddur. Kullanıcı login olduktan sonra bir “giz” yaratarak kullanıcının doğru olup olmadığını kontrol edebilirsiniz. Kullanıcı login olduktan sonra gizli bir hash veya token yaratıp sunucu-tarafı oturumunda depola ve bunu her link ve form’a dahil et. Birbirini takip eden her http isteği bunu içermeli, aksi takdirde kabul edilmemeli ve oturum geçersiz kılınmalı. Eğer XSS açığı varsa “Giz” oturum id’si ile aynı olmamalı. Token’ı herhangi bir oturum değişkeni gibi oluştur. Basit bir koşul ifadesi doğrulanabilir.

Bunu PHP’de yapılışı ile ilgili bir örnek verelim. Bu futbol maçı biletleri sipariş edilebilen bir web uygulaması örneği:

<?php
session_start();
$token = md5(uniqid(rand(),TRUE));
$_SESSION['token'] = $token;
$_SESSION['token_time'] = time();
?>
<form action=”purchase.php” method=”POST”>
<input type=”hidden” name=”token” value=”<?php echo $token; ?>” />
<p>
Item:
<select name=”item”>
<option name=”fieldlevel”>fieldlevel</option>
<option name=”upperdeck”>upperdeck</option>
</select><br/>
Number:<input type=”text” name=”number” /><br/>
<input type=”submit” value=”Purchase” />
</p>
</form>

Token herhangi bir oturum değişkeni gibi yaratılmalı.
<?php
if (!isset($_SESSION['token']))
{
$_SESSION['token'] = md5(uniqid(rand(), TRUE));
}
?>

Token’ı basit bir koşul ifadesi ile kontrol edin:
<?php
if ($_POST['token'] == $_SESSION['token'])
{
/* Valid Token */
}
?>

Token’ın geçerliliğini belirli bir zaman periyoduna kısıtlamak, örneğin dört dakika, güvenliği artıracaktır:
<?php
$token_age = time() – $_SESSION['token_time'];
if ($token_age <= 240)
{
/* Less than four minutes has passed. */
}
?>

CAPTCHA

CAPTCHA implemente etmekde XSRF saldırılarını engelleyebilir. CAPTCHA (Completely Automated Public Turing test to tell Computers and Humans Apart) basitçe kullanıcının karışık fakat okunabilir harf (veya harf rakam kombinasyonu) içeren resimde gösterilenleri girmesini gerektirir. Burdaki fikir bilgisayarın grafikte gizli olan kelimeyi bulamayacağı ve insanların kolaylıkla ayırtedebileceğidir. CAPTCHA kullanımı, kullanıcının spesifik işlemler öncesi resimdeki bilgiyi girmesi ile olur.

Diğer Çözümler

Daha az zaman ve efor gerektiren (fakat daha az etkili olan) diğer çözümlere gelelim. Çoğunlukla gizleme ile güvenlik (security through obscurity) den oluşurlar. Bu da saldırganın açıktan yararlanmasında ek bilgi gerektirir. Fakat, tekrar uyaralım, uygulamanız uzman bir saldırgana bu şekilde karşı koyamaz.

Yönlendirme

XSRF saldırılarını HTTP isteğinin yetkili bir kaynaktan gelip gelmediğini kontrol ederek ve yönlendirme kullanarak önleyebilirsiniz. Eğer Referer başlığı yoksa, veya işlemi gerçekleştirmesi gerekmeyen bir sayfa veya site içeriyorsa, yönlendirme kullanıcıyı başka bir sayfaya yönlendirerek ek işlem yapılmasını engelleyebilir.

<?php
if ($_SERVER['HTTP_REFERER'] != ‘http://www.victim.tld/transfer.html’ )
{
header(”Location: http://www.victim.tld/transfer.html - http://www.victim.tld/transfer.html” );
exit;
}
?>

URL Rewrite

Form-tabanlı kimlik doprulama yaparken diğer bir opsiyon da cookie yerine URL rewrite (özellikle bu opsiyon uygulama sunucusu tarafından transparan olarak yapılabiliyorsa) kullanımıdır. Oturum tanımlayıcısını her URL’ye dahil edildiğinde, bu tanımlayıcı arka arkaya yapılan sayfa isteklerinde ayrıştırılıp oturum bilgisini tanımakta kullanılabilir. Fakat çoğu uygulamada bunun uygulanabilmesi büyük bir çalışma gerektirebilmektedir.

Get yerine Post kullanımı

Uygulamanın objeleri yaratma, değiştirme ve silme gibi durum değişiklikleri için GET yerine POST kullanımına zorlama yapılabilir. Hem HTTP GET, hem de HTTP POST kullanan uygulamalar XSRF açıklarından etkilense de, HTTP GET kullanarak saldırıyı gerçekleştirmek çok daha kolaydır. POST kullanımı resim tag’leri örneğimizdeki saldırıyı etkisiz kılar ve uygulama içerisinde resim link’lerinin paylaşılabilmesine izin verir. Ayrıca bunu implemente etmek çok kolaydır. Ayrıca saldırganların başka hedef aramasına yol açacak kadar caydırıcı olabilir. Fakat yine de çok bilgili bir saldırgan JavaScript kullanarak POST isteklerinden de bu saldırıları yapabilir.

Oturum tanımlayıcılarının gizli form alanları olarak geçirmek

Formlarda hidden alanlarında oturum tanımlayıcılarını kullanabilirsiniz. Bu bilgi web sayfasında görülmez fakat diğer alanlarla birlikte otomatik olarak gönderilir. Gizli form alanlarında oturum tanımlayıcılarını geçirmek, bir sayfadan diğerine geçişte resim linkleri yazı linkleri kullanımından mahrum bırakır, bu sebeple bu pek kullanışlı değil. Ayrıca HIDDEN form alanı değeri web sayfasında görünmese de tarayıcının kaynak görüntüleme seçeneği ile kolayca görülebilir. Bunun içinde gizli veri kriptolanarak sadece gerektiğinde dekriptolanabilir.