Header HTTP X-Forwarded-For ( XFF ), yang direka untuk mengenal pasti alamat IP asal klien yang menyambung melalui proksi dan pengimbang beban, telah menjadi sumber kelemahan keselamatan yang ketara dalam aplikasi web. Profesional keselamatan melaporkan bahawa penghuraian yang tidak betul bagi header ini menjejaskan sekurang-kurangnya separuh daripada aplikasi web yang mereka audit, mewujudkan peluang untuk pemalsuan IP, pintasan geoblocking, dan juga serangan cross-site scripting.
Kegagalan Pelaksanaan Meluas Melanda Aplikasi Web
Juruaudit keselamatan profesional mendapati corak yang membimbangkan dalam cara aplikasi web mengendalikan header XFF . Kesilapan yang paling biasa melibatkan aplikasi yang mempercayai sebarang nilai header XFF secara membuta tuli tanpa pengesahan yang betul, membenarkan penyerang untuk mengatasi had kadar dan sekatan berasaskan IP dengan mudah. Sebaliknya, sesetengah aplikasi mengabaikan header XFF sepenuhnya apabila mereka sepatutnya menggunakannya, mengakibatkan alamat IP pengimbang beban dihadkan kadarnya dan bukannya pengguna sebenar.
Masalah ini melangkaui salah konfigurasi mudah. Aplikasi yang memaparkan alamat IP pengguna dalam antara muka mereka telah menjadi mangsa serangan cross-site scripting melalui header XFF yang dibuat secara berniat jahat. Ini menunjukkan bagaimana ciri pencatatan yang kelihatan tidak bersalah boleh menjadi kelemahan keselamatan yang serius.
Kelemahan Keselamatan XFF yang Biasa:
- Kepercayaan buta terhadap sebarang nilai header XFF
- Mengabaikan header XFF apabila ia sepatutnya diproses
- Serangan cross-site scripting melalui paparan alamat IP
- Ketidakkonsistenan penghuraian berbilang header
- Serangan suntikan header melalui pemisah yang cacat
Sempadan Kepercayaan dan Pengesahan Rantai Proksi
Cabaran keselamatan teras dengan header XFF terletak pada mewujudkan sempadan kepercayaan yang betul. Apabila permintaan bergerak melalui beberapa proksi sebelum sampai ke pelayan web, setiap proksi sepatutnya menambah alamat IP sendiri ke rantai header XFF . Walau bagaimanapun, klien berniat jahat boleh menyuntik alamat IP sewenang-wenangnya ke dalam rantai ini, menjadikannya sukar untuk menentukan alamat mana yang sah.
Pengimbang beban yang dikonfigurasikan dengan betul akan menggugurkan header ini jika klien menghantarnya, dan kemudian menetapkannya sendiri, dengan ip sambungan permintaan menjadi yang pertama, kemudian ip proksi menjadi yang kedua.
Pakar keselamatan mengesyorkan mengekalkan senarai alamat IP proksi yang dipercayai dan menapis alamat proksi yang diketahui daripada rantai XFF untuk mengenal pasti IP klien sebenar. Pendekatan ini memerlukan konfigurasi yang teliti dan penyelenggaraan berterusan apabila infrastruktur rangkaian berubah.
Format Header XFF:
X-Forwarded-For: client, proxy1, proxy2
Di mana IP paling kiri adalah klien asal dan setiap IP berikutnya mewakili proksi dalam rantai pemajuan.
 |
|---|
| Catatan blog ini menerangkan kerumitan menguruskan sempadan kepercayaan dengan pengepala X-Forwarded-For dalam aplikasi web |
Berbilang Header dan Kerumitan Penghuraian
Satu lagi kelemahan ketara muncul daripada cara aplikasi mengendalikan berbilang header XFF dalam satu permintaan. Walaupun piawaian HTTP membenarkan berbilang contoh header yang sama, banyak aplikasi memprosesnya dengan tidak betul, mewujudkan peluang untuk serangan suntikan header. Sesetengah pelayan secara automatik menggabungkan berbilang header XFF menjadi satu rentetan yang dipisahkan koma, manakala yang lain hanya memproses kejadian pertama sahaja.
Penyerang mengeksploitasi ketidakkonsistenan penghuraian ini dengan menghantar permintaan dengan berbilang header XFF atau menggunakan aksara pemisah yang luar biasa dan rentetan berpetik. Aplikasi yang tidak membersihkan input ini dengan betul menjadi terdedah kepada serangan suntikan kod, terutamanya apabila nilai header dicatatkan atau dipaparkan.
Langkah Keselamatan yang Disyorkan:
- Kekalkan senarai alamat IP proksi yang dipercayai
- Tolak permintaan dengan berbilang pengepala XFF
- Laksanakan had MaxHeaderBytes dalam pelayan HTTP
- Gunakan pemeriksaan konfigurasi runtime dengan amaran
- Pertimbangkan untuk berhijrah kepada piawaian pengepala Forwarded RFC 7239
Alternatif Moden dan Amalan Terbaik
Komuniti keselamatan semakin mengesyorkan beralih daripada header XFF kepada header Forwarded yang diseragamkan yang ditakrifkan dalam RFC 7239 . Piawaian yang lebih baharu ini menyediakan struktur yang lebih baik dan mengurangkan ralat penghuraian, walaupun ia masih memerlukan pertimbangan sempadan kepercayaan yang sama seperti XFF .
Untuk aplikasi yang mesti terus menggunakan header XFF , profesional keselamatan mencadangkan beberapa langkah pertahanan: menolak permintaan dengan berbilang contoh header XFF , melaksanakan had ketat pada saiz bait header, dan mengekalkan pemeriksaan masa jalan yang memberi amaran tentang salah konfigurasi biasa. Langkah-langkah proaktif ini telah terbukti berkesan dalam mengurangkan beban sokongan dan insiden keselamatan.
Kelaziman berterusan kelemahan berkaitan XFF menyerlahkan kepentingan menganggap header HTTP sebagai input yang tidak dipercayai yang memerlukan pengesahan dan pembersihan yang teliti, terutamanya apabila digunakan untuk keputusan kritikal keselamatan seperti had kadar dan kawalan akses.