Pertama, di muka, saya tidak tahu apa yang penyerang coba capai. Mungkin ada skrip PHP atau versi PHP di luar sana yang rentan terhadap beberapa serangan ID sesi yang aneh, saya tidak tahu. Anda mungkin tidak perlu khawatir.
Server Anda berperilaku tepat seperti yang diharapkan. 200 adalah kode yang diharapkan dalam situasi tertentu karena bagaimana Apache mengartikan URL yang diteruskan ke sana.
Pertama, http://allrequestsallowed.comdiperlakukan seperti header 'Host:' yang lebih biasa ( perhatikan bahwa saya tidak berpikir ini ditentukan dalam RFC dan server lain mungkin tidak menafsirkannya dengan cara ini saya salah, ini ditentukan dalam RFC 2616 di bagian 5.1. 2, meskipun klien tampaknya jarang menggunakan formulir itu. Maaf, saya harus memperbaiki implementasi server HTTP yang saya tulis beberapa waktu lalu ...).
Sekarang, mungkin Anda tidak memiliki situs bernama 'allrequestsallowed.com'. Jadi apa yang terjadi ketika Apache mendapat Host:tajuk (atau setara) untuk nama host yang tidak dikenali? Ini mengambil host virtual pertama sebagai default. Ini adalah perilaku yang terdefinisi dan terdokumentasi dengan baik untuk Apache. Jadi apa pun virtual host pertama Anda (atau hanya konfigurasi server utama jika tidak ada vhosts) mengambil alih, apa pun namanya.
Sekarang, sisa URL yang diberikan terdiri dari dua bagian - path /,, dan parameter GET ( ?PHPSESSID...bit).
Sekarang, path /harus ada pada hampir semua server web di luar sana. Dalam kebanyakan kasus, ini memetakan ke sesuatu seperti index.htmlatau mungkin sebuah index.phpskrip, meskipun Anda dapat mengabaikan semua ini tentu saja.
Jika peta ke file HTML statis, sama sekali tidak ada yang tidak biasa terjadi - konten file dikembalikan, dan hanya itu, parameternya diabaikan. (Dengan asumsi Anda tidak memiliki arahan konfigurasi lanjutan tertentu yang ditetapkan, dan Anda hampir pasti tidak.)
Di sisi lain, jika itu semacam skrip, PHPSESSIDvariabel itu akan diteruskan ke skrip. Jika skrip benar-benar menggunakan variabel itu (dalam kasus khusus ini, hanya skrip PHP yang menggunakan penanganan sesi bawaan PHP yang cenderung), perilakunya akan tergantung pada konten.
Namun, dalam kemungkinan besar, bahkan jika Anda /memetakan ke skrip PHP menggunakan sesi, tidak ada yang luar biasa yang akan terjadi. ID sesi mungkin tidak akan ada, dan akan diabaikan, atau skrip akan menampilkan kesalahan.
Dalam kasus yang tidak mungkin bahwa ID sesi memang ada, well, penyerang dapat membajak sesi orang lain. Itu akan buruk, tetapi itu sebenarnya bukan lubang keamanan itu sendiri - lubang itu akan berada di mana pun penyerang mendapatkan informasi sesi ID dari (mengendus jaringan nirkabel adalah kandidat yang baik jika Anda tidak menggunakan HTTPS). Mereka sebenarnya tidak akan bisa melakukan apa pun yang tidak bisa dilakukan oleh pengguna yang sesi yang awalnya dibuatnya.
Sunting: Selain itu, '% 5C' di dalam SESSIONID memetakan ke karakter backslash. Ini tampaknya menjadi ujian untuk serangan direktori traversal pada host windows.
curl -v http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP -x www.example.com:80. Konfigurasi default tampaknya mengembalikan halaman "Selamat datang di nginx" tanpa konten yang berarti, di sistem ubuntu kami. Jadi ini adalah tanggapan 200, tapi ini adalah halaman tangkap sederhana - kami sebenarnya tidak memproksi permintaan di tempat lain atau semacamnya.