TL; DR - perbaikannya (yang bahkan mungkin tidak Anda perlukan) SANGAT SEDERHANA dan di akhir jawaban ini.
Saya akan mencoba menjawab pertanyaan spesifik Anda, tetapi kesalahpahaman Anda tentang apa PATH_INFO itu membuat pertanyaan itu sendiri sedikit salah.
Pertanyaan pertama harus "Apa bisnis info jalur ini?"
Pertanyaan Anda berikutnya seharusnya: "Bagaimana PHP menentukan apa PATH_INFOdan apa SCRIPT_FILENAME?"
- Versi PHP sebelumnya adalah naif dan secara teknis bahkan tidak mendukung
PATH_INFO, jadi apa yang seharusnya menjadi PATH_INFOmunged SCRIPT_FILENAMEyang, ya, rusak dalam banyak kasus. Saya tidak memiliki versi PHP yang cukup lama untuk diuji, tetapi saya percaya PHP dilihat SCRIPT_FILENAMEsebagai keseluruhan shebang: "/path/to/script.php/THIS/IS/PATH/INFO" dalam contoh di atas (diawali dengan dokumen seperti biasa).
- Dengan cgi.fix_pathinfo diaktifkan, PHP sekarang dengan benar menemukan "/ INI / IS / PATH / INFO" untuk contoh di atas dan memasukkannya ke dalam
PATH_INFOdan SCRIPT_FILENAMEmendapatkan hanya bagian yang menunjuk ke skrip yang diminta (diawali dengan dokumen tentu saja).
- Catatan: ketika PHP benar-benar mendukung
PATH_INFO, mereka harus menambahkan pengaturan konfigurasi untuk fitur baru sehingga orang yang menjalankan skrip yang bergantung pada perilaku lama dapat menjalankan versi PHP baru. Itu sebabnya bahkan ada saklar konfigurasi untuk itu. Seharusnya sudah built-in (dengan perilaku "berbahaya") dari awal.
Tetapi bagaimana PHP tahu bagian mana dari skrip dan apa itu info jalur? Bagaimana jika URI itu seperti:
http://example.com/path/to/script.php/THIS/IS/PATH/INFO.php?q=foo
- Itu bisa menjadi pertanyaan kompleks di beberapa lingkungan. Apa yang terjadi di PHP adalah ia menemukan bagian pertama dari jalur URI yang tidak sesuai dengan apa pun di bawah dokumen server. Untuk contoh ini, ia melihat bahwa di server Anda Anda tidak memiliki "/docroot/path/to/script.php/THIS" tetapi Anda pasti memiliki "/docroot/path/to/script.php" jadi sekarang
SCRIPT_FILENAMEtelah ditentukan dan PATH_INFOmendapat sisanya.
- Jadi sekarang contoh yang baik dari bahaya yang diperinci dengan baik dalam dokumen Nginx dan dalam jawaban Hrvoje Špoljar (Anda tidak bisa cerewet tentang contoh yang jelas seperti itu) menjadi lebih jelas: diberi contoh Hrvoje (" http: // contoh. com / foo.jpg / nonexistent.php "), PHP melihat file di dokumen Anda" /foo.jpg "tetapi tidak melihat apa pun yang disebut" /foo.jpg/nonexistent.php "jadi
SCRIPT_FILENAMEdapatkan" /foo.jpg " (lagi, diawali dengan docroot) dan PATH_INFOmendapat "/nonexistent.php".
Mengapa dan bagaimana itu bisa berbahaya sekarang harus jelas:
- Server web benar-benar tidak bersalah - itu hanya proksi URI ke PHP, yang dengan polos menemukan bahwa "foo.jpg" sebenarnya mengandung konten PHP, jadi itu mengeksekusinya (sekarang Anda sudah dibajak!). Ini TIDAK khusus untuk Nginx per se.
- Masalah NYATA adalah bahwa Anda membiarkan konten yang tidak tepercaya diunggah di suatu tempat tanpa sanitasi dan Anda mengizinkan permintaan sewenang-wenang lainnya ke lokasi yang sama, yang dengan senang hati dieksekusi oleh PHP ketika bisa.
Nginx dan Apache dapat dibangun atau dikonfigurasikan untuk mencegah permintaan menggunakan tipuan ini, dan ada banyak contoh cara melakukannya, termasuk dalam jawaban user2372674 . Artikel blog ini menjelaskan masalahnya dengan baik, tetapi tidak ada solusi yang tepat.
Namun, solusi terbaik adalah memastikan PHP-FPM dikonfigurasi dengan benar sehingga tidak akan pernah mengeksekusi file kecuali diakhiri dengan ".php". Perlu dicatat bahwa versi terbaru PHP-FPM (~ 5.3.9 +?) Memiliki ini sebagai default, jadi bahaya ini tidak begitu banyak masalah lagi.
Solusinya
Jika Anda memiliki versi terbaru PHP-FPM (~ 5.3.9 +?), Maka Anda tidak perlu melakukan apa-apa, karena perilaku aman di bawah ini sudah merupakan default.
Kalau tidak, cari www.conffile php-fpm (mungkin /etc/php-fpm.d/www.conf, tergantung sistem Anda). Pastikan Anda memilikinya:
security.limit_extensions = .php
Sekali lagi, itu standar di banyak tempat hari ini.
Perhatikan bahwa ini tidak mencegah penyerang mengunggah file ".php" ke folder unggahan WordPress dan mengeksekusi yang menggunakan teknik yang sama. Anda masih harus memiliki keamanan yang baik untuk aplikasi Anda.