Alat pengembang · URL encoder & decoder
Pengkodean URL bukan sanitasi: parameter yang didekodekan masih perlu di-escape
· Mengapa itu penting
pengkodean url keamanan xss
Pengkodean persen melindungi struktur URL, bukan HTML, SQL, atau shell Anda. Posting ini menjelaskan mengapa nilai yang dikodekan dengan benar menjadi berbahaya lagi saat didekodekan, dan nilai pelolosan mana yang menjadi miliknya.
Mengapa pengkodean URL saja tidak dapat menghentikan serangan XSS
Parameter "aman" dapat menjalankan skrip jika dikodekan untuk transmisi tetapi didekodekan sebelum rendering. Pertimbangkan muatan XSS seperti tag img dengan pengendali onerror yang dikodekan persen sebagai %3Cimg%20src%3Dx%20onerror%3Dalert%281%29%3E. Jika ini berjalan di URL dan didekodekan oleh kode aplikasi sebelum dimasukkan ke HTML, browser akan melihat markup asli dan mengeksekusi handler. Pengkodean persen adalah lapisan representasi; tidak mengubah ancaman mendasar.
Payload aman hanya selama transmisi, ketika string tersebut dikodekan tanpa arti khusus ke parser HTTP atau URL. Saat diterjemahkan, menjadi berbahaya lagi karena kembali ke bentuk aslinya. Setiap konteks hilir harus menerapkan aturan pelolosan sendiri yang sesuai dengan cara penggunaan data. Pengkodean URL tidak menggantikan pelolosan HTML, parameterisasi SQL, atau penanganan argumen shell.
Untuk apa pengkodean persen — menjaga pembatas tetap jelas, tidak lebih
Apa yang dilakukan pengkodean persen adalah melindungi struktur URL dengan tepat. Ampersand tetap menjadi bagian dari sintaksis string kueri, tidak ditafsirkan ulang sebagai pembatas. Garis miring tidak menjadi pemisah jalur. Tanda tanya tidak dimulai dengan fragmen. Dengan menyandikan karakter yang dicadangkan sebagai %XX, parser memperlakukannya sebagai data, bukan sintaksis. Ini berfungsi untuk satu pekerjaan: menjaga struktur URL tidak ambigu pada kabel.
Penguraian kode justru membalikkan jalan satu arah itu. Byte yang dipulihkan persis seperti yang dikodekan, tidak lebih dan tidak kurang. HTML-string berbahaya tetap berbahaya, SQL-vektor injeksi tetap berbahaya, dan perintah shell tetap berbahaya. Pengkodean persen bukanlah validasi masukan, bukan sanitasi, dan bukan batas keamanan. Ini hanya format representasi.
Decoding mengembalikan byte asli — sehingga setiap konteks hilir melihat nilai mentahnya lagi
Pelarian yang spesifik pada konteks adalah tempat perlindungan nyata diterapkan. HTML konteks membutuhkan entitas: kurang dari menjadi <, lebih besar dari menjadi >, tanda kutip menjadi ", ampersand menjadi &. Konteks SQL memerlukan kueri berparameter yang memisahkan struktur dari data, mencegah penyerang keluar. Konteks shell memerlukan susunan argumen untuk menghindari pemisahan kata dan penggumpalan sepenuhnya.
Setiap konteks memiliki karakter berbahaya yang berbeda dan aturan pelarian yang berbeda pula. Entitas HTML tidak berbahaya dalam kueri SQL tetapi tidak berguna untuk perlindungan di sana. Garis miring terbalik mencegah injeksi SQL di beberapa database tetapi tidak di database lain. Pelarian Shell bergantung pada gaya kutipan. Pengembang harus memahami tujuan sebelum memilih cara menangani data.
Pelokalan spesifik konteks — entitas HTML untuk markup, kueri berparameter untuk SQL, susunan argumen untuk shell
Contoh praktis: mengikuti muatan dari tautan ke log ke halaman mengungkapkan di mana pengkodean dan pelolosan harus terjadi. Tautan berisi muatan XSS yang dikodekan sebagai parameter kueri. Server menerimanya dengan masih dikodekan dalam badan permintaan HTTP. Aplikasi menerjemahkan parameter kueri untuk menampilkannya di halaman. Tanpa pelolosan keluaran, browser merender muatan sebagai HTML dan menjalankannya.
Jika parameter yang sama masuk ke file, entri log berisi muatan yang didekodekan dengan jelas. Aplikasi kedua membaca log, mendekode lagi, memasukkannya ke halaman HTML tanpa keluar. Payload dijalankan untuk kedua kalinya. Pada setiap langkah, konteks menentukan apa yang aman. Penguraian kode URL aman. Penyimpanan file aman. Namun keluaran HTML tanpa pelolosan berakibat fatal.
Contoh praktis: mengikuti satu payload dari link ke log ke halaman — di mana ia dikodekan, di mana ia didekodekan, di mana ia harus di-escape
Pengkodean sebagai alat penghindaran filter menunjukkan mengapa penyerang melakukan pengkodean ganda dan mencampur huruf hex secara signifikan. Jika firewall mencari tag img, penyerang mengirimkan %3Cimg dan berharap aplikasi mendekode satu kali tetapi firewall tidak. Jika validasi menolak %3Cimg tetapi mengizinkan kasus berbeda, byte yang sama akan didekodekan ke payload yang sama. Keamanan yang bergantung pada pencocokan pola masukan yang dikodekan rapuh.
Penguraian kode harus benar-benar tepat dan dapat diprediksi. Bentuk kanonik (huruf kecil hex, pengkodean yang dikenal) memungkinkan kebijakan yang konsisten tetapi tidak menyelesaikan masalah mendasar. Hanya pendekatan yang andal yang mengizinkan penguraian kode jika diperlukan dan menerapkan pelolosan keluaran konteks spesifik segera sebelum digunakan. Penguraian kode tidak pernah aman; hanya diperlukan untuk transmisi.
Pengkodean sebagai alat penghindaran filter — mengapa penyerang melakukan pengkodean ganda dan mencampur huruf hex, dan mengapa penguraian kode harus tepat
Pertahanan XSS yang penuh memerlukan pemahaman tentang aliran data secara lengkap, konteks yang dilaluinya pada setiap langkah, apa yang diperlukan untuk keluar dari setiap konteks. Pengkodean URL hanyalah satu bagian kecil: mempertahankan struktur selama transmisi saja. Namun satu bagian bukanlah pertahanan yang berdiri sendiri. Banyak pengembang yang menyamakan pengkodean dengan sanitasi karena keduanya melibatkan penggantian karakter, tetapi melakukan pekerjaan penting yang sangat berbeda.
Firewall Aplikasi Web dapat mendeteksi pola dalam muatan permintaan, namun pengkodean dengan mudah menghindari teknik pencocokan pola sederhana. Penyetelan WAF rumit dan melampaui pengkodean URL. Pertahanan yang andal adalah pelolosan keluaran dalam kode aplikasi, dipasangkan dengan validasi masukan yang masuk akal untuk konteks dan kebutuhan spesifik Anda.
Apa yang tidak tercakup di sini — panduan pertahanan XSS lengkap atau penyetelan firewall aplikasi web
Pertahanan XSS penuh memerlukan pemahaman aliran data secara lengkap, konteks yang dilaluinya pada setiap langkah, apa yang diperlukan untuk keluar dari setiap konteks di seluruh aplikasi. Pengkodean URL hanyalah satu bagian kecil: mempertahankan struktur selama transmisi saja. Namun satu bagian bukanlah pertahanan yang berdiri sendiri. Banyak pengembang yang menyamakan pengkodean dengan sanitasi karena keduanya melibatkan penggantian karakter, namun melakukan tugas penting yang sangat berbeda sepanjang pengembangan.
Uji payload secara end-to-end untuk melihat di mana pengkodean dan pelolosan benar-benar penting di seluruh proses. Rekatkan %3Cimg%20src%3Dx%20onerror%3Dalert%281%29%3E ke decoder URL dan lihat menjadi string yang tampak seperti markup. Kemudian tempelkan hasilnya ke escaper entitas HTML untuk melihat bagaimana menjadi teks aman. Dua alat menunjukkan lapisan terlihat jelas.
Kesimpulan: enkode untuk URL, escape untuk output — bagaimana encoder & decoder URL dan escaper entitas HTML ditempatkan berdampingan dalam satu produk untuk dua pekerjaan berbeda
Kesimpulannya adalah bahwa pengkodean dan pelolosan adalah masalah yang terpisah pada lapisan yang berbeda secara keseluruhan. Pengkodean URL hanya melindungi struktur yang dikirimkan. Keluaran yang keluar melindungi konten yang dirender. Nilai yang dikodekan dengan benar masih memerlukan pelolosan keluaran saat mencapai HTML. String yang lolos dengan benar tidak memerlukan pengkodean URL jika tidak dimasukkan ke URL.
Terapkan pertahanan yang tepat di lapisan kanan dengan sungguh-sungguh. Jangan mengandalkan pengkodean URL untuk menghentikan serangan XSS. Jangan mengandalkan pelolosan HTML untuk mempertahankan struktur URL. Pahami aliran data Anda dan terapkan transformasi yang sesuai di setiap langkah. Pembuat enkode URL membantu Anda melihat fungsi pengkodean; lalu gunakan escaper entitas HTML untuk langkah keluaran.