Header HTTP X-Forwarded-For ( XFF ), yang dirancang untuk mengidentifikasi alamat IP asli dari klien yang terhubung melalui proxy dan load balancer, telah menjadi sumber kerentanan keamanan yang signifikan dalam aplikasi web. Para profesional keamanan melaporkan bahwa parsing yang salah dari header ini mempengaruhi setidaknya setengah dari aplikasi web yang mereka audit, menciptakan peluang untuk IP spoofing, bypass geoblocking, dan bahkan serangan cross-site scripting.
Kegagalan Implementasi yang Meluas Melanda Aplikasi Web
Auditor keamanan profesional menemukan pola yang mengkhawatirkan dalam cara aplikasi web menangani header XFF . Kesalahan paling umum melibatkan aplikasi yang secara membabi buta mempercayai nilai header XFF apa pun tanpa validasi yang tepat, memungkinkan penyerang untuk dengan mudah melewati rate limiting dan pembatasan berbasis IP. Sebaliknya, beberapa aplikasi mengabaikan header XFF sepenuhnya ketika seharusnya mereka menggunakannya, mengakibatkan alamat IP load balancer dibatasi rate-nya alih-alih pengguna sebenarnya.
Masalah ini meluas melampaui kesalahan konfigurasi sederhana. Aplikasi yang menampilkan alamat IP pengguna di antarmuka mereka telah menjadi korban serangan cross-site scripting melalui header XFF yang dibuat dengan jahat. Ini menunjukkan bagaimana fitur logging yang tampaknya tidak berbahaya dapat menjadi kerentanan keamanan yang serius.
Kerentanan Keamanan XFF yang Umum:
- Kepercayaan buta terhadap nilai header XFF apa pun
- Mengabaikan header XFF ketika seharusnya diproses
- Cross-site scripting melalui rendering alamat IP
- Inkonsistensi parsing header berganda
- Serangan injeksi header melalui separator yang tidak valid
Batas Kepercayaan dan Validasi Rantai Proxy
Tantangan keamanan inti dengan header XFF terletak pada penetapan batas kepercayaan yang tepat. Ketika permintaan berjalan melalui beberapa proxy sebelum mencapai server web, setiap proxy harus menambahkan alamat IP-nya sendiri ke rantai header XFF . Namun, klien jahat dapat menyuntikkan alamat IP sewenang-wenang ke dalam rantai ini, sehingga sulit untuk menentukan alamat mana yang sah.
Load balancer yang dikonfigurasi dengan benar akan menghapus header ini jika klien mengirimkannya, dan kemudian mengaturnya sendiri, dengan IP koneksi permintaan menjadi yang pertama, kemudian IP proxy menjadi yang kedua.
Para ahli keamanan merekomendasikan untuk memelihara daftar alamat IP proxy yang terpercaya dan menyaring alamat proxy yang dikenal dari rantai XFF untuk mengidentifikasi IP klien yang sebenarnya. Pendekatan ini memerlukan konfigurasi yang cermat dan pemeliharaan berkelanjutan seiring perubahan infrastruktur jaringan.
Format Header XFF:
X-Forwarded-For: client, proxy1, proxy2
Di mana IP paling kiri adalah klien asli dan setiap IP berikutnya mewakili proxy dalam rantai penerusan.
 |
|---|
| Artikel blog ini menjelaskan kompleksitas mengelola batas kepercayaan dengan header X-Forwarded-For dalam aplikasi web |
Multiple Header dan Kompleksitas Parsing
Kerentanan signifikan lainnya muncul dari cara aplikasi menangani beberapa header XFF dalam satu permintaan. Meskipun standar HTTP memungkinkan beberapa instance dari header yang sama, banyak aplikasi memprosesnya dengan salah, menciptakan peluang untuk serangan header injection. Beberapa server secara otomatis menggabungkan beberapa header XFF menjadi satu string yang dipisahkan koma, sementara yang lain hanya memproses kemunculan pertama.
Penyerang mengeksploitasi inkonsistensi parsing ini dengan mengirim permintaan dengan beberapa header XFF atau menggunakan karakter pemisah yang tidak biasa dan string yang dikutip. Aplikasi yang tidak membersihkan input ini dengan benar menjadi rentan terhadap serangan code injection, terutama ketika nilai header dicatat atau ditampilkan.
Langkah-Langkah Keamanan yang Direkomendasikan:
- Pertahankan daftar alamat IP proxy terpercaya
- Tolak permintaan dengan beberapa header XFF
- Implementasikan batas MaxHeaderBytes pada server HTTP
- Gunakan pemeriksaan konfigurasi runtime dengan peringatan
- Pertimbangkan migrasi ke standar header Forwarded RFC 7239
Alternatif Modern dan Praktik Terbaik
Komunitas keamanan semakin merekomendasikan untuk beralih dari header XFF menuju header Forwarded yang distandarisasi yang didefinisikan dalam RFC 7239 . Standar yang lebih baru ini menyediakan struktur yang lebih baik dan mengurangi kesalahan parsing, meskipun masih memerlukan pertimbangan batas kepercayaan yang sama seperti XFF .
Untuk aplikasi yang harus terus menggunakan header XFF , para profesional keamanan menyarankan beberapa langkah defensif: menolak permintaan dengan beberapa instance header XFF , menerapkan batas ketat pada ukuran byte header, dan memelihara pemeriksaan runtime yang memperingatkan tentang kesalahan konfigurasi umum. Langkah-langkah proaktif ini telah terbukti efektif dalam mengurangi beban dukungan dan insiden keamanan.
Prevalensi berkelanjutan dari kerentanan terkait XFF menyoroti pentingnya memperlakukan header HTTP sebagai input yang tidak terpercaya yang memerlukan validasi dan sanitasi yang cermat, terutama ketika digunakan untuk keputusan kritis keamanan seperti rate limiting dan kontrol akses.
Referensi: What is X-Forwarded-For and when can you trust it?