Bagaimanakah kuki tapak yang sama boleh digunakan untuk mengurangkan serangan CSRF?
Kuki tapak yang sama ialah mekanisme keselamatan penting yang boleh digunakan untuk mengurangkan serangan Pemalsuan Permintaan Silang Tapak (CSRF) dalam aplikasi web. Serangan CSRF berlaku apabila penyerang memperdaya mangsa untuk melakukan tindakan yang tidak diingini pada tapak web di mana mangsa disahkan. Dengan mengeksploitasi sesi mangsa, penyerang boleh melakukan tindakan bagi pihak mangsa tanpa persetujuan mereka.
Kuki tapak yang sama membantu menghalang serangan CSRF dengan mengehadkan skop kuki kepada asal yang sama. Asal ditakrifkan oleh gabungan protokol (cth, HTTP atau HTTPS), domain dan nombor port. Apabila kuki ditetapkan dengan atribut "SameSite", ia menentukan sama ada kuki itu harus dihantar dalam permintaan merentas tapak.
Terdapat tiga nilai yang mungkin untuk atribut "SameSite":
1. "Strict": Apabila atribut "SameSite" ditetapkan kepada "Strict", kuki hanya dihantar dalam permintaan yang berasal dari tapak yang sama. Ini bermakna bahawa kuki tidak akan dihantar dalam permintaan merentas tapak, dengan berkesan menghalang serangan CSRF. Contohnya, jika pengguna disahkan pada "example.com" dan melawat tapak berniat jahat yang cuba melakukan serangan CSRF, penyemak imbas tidak akan memasukkan kuki tapak yang sama "Ketat" dalam permintaan, sekali gus menghalang serangan itu.
2. "Lax": Apabila atribut "SameSite" ditetapkan kepada "Lax", kuki dihantar dalam permintaan merentas tapak yang dianggap selamat, seperti apabila permintaan itu dicetuskan oleh navigasi peringkat atas daripada pengguna. Walau bagaimanapun, kuki tidak dihantar dalam permintaan yang dimulakan oleh tapak web pihak ketiga, seperti apabila imej atau teg skrip dimuatkan daripada domain lain. Ini memberikan keseimbangan antara keselamatan dan kebolehgunaan. Contohnya, pengguna yang melawat tapak berniat jahat melalui pautan tidak akan mencetuskan serangan CSRF kerana kuki tapak yang sama "Lax" tidak akan disertakan dalam permintaan.
3. "Tiada": Apabila atribut "SameSite" ditetapkan kepada "Tiada", kuki dihantar dalam semua permintaan merentas tapak, tanpa mengira asalnya. Walau bagaimanapun, untuk memastikan keselamatan penggunaan "Tiada", kuki juga mesti ditandakan sebagai "Secure", yang bermaksud ia hanya akan dihantar melalui sambungan HTTPS. Gabungan ini membolehkan aplikasi web menyokong fungsi merentas tapak sambil masih melindungi daripada serangan CSRF. Perlu diingatkan bahawa nilai "Tiada" hanya boleh digunakan apabila perlu, kerana ia meningkatkan permukaan serangan dan potensi kelemahan CSRF.
Untuk menggambarkan penggunaan kuki tapak yang sama dalam mengurangkan serangan CSRF, pertimbangkan senario berikut: tapak web perbankan yang membenarkan pengguna memindahkan dana. Tanpa kuki tapak yang sama, penyerang boleh membuat tapak web berniat jahat yang termasuk borang tersembunyi yang secara automatik menyerahkan permintaan pindahan dana ke tapak web perbankan apabila dilawati oleh pengguna yang disahkan. Jika penyemak imbas pengguna memasukkan kuki sesi dalam permintaan, pemindahan akan dilaksanakan tanpa kebenaran pengguna. Walau bagaimanapun, dengan menetapkan kuki sesi sebagai kuki tapak yang sama dengan atribut "Ketat", penyemak imbas tidak akan memasukkan kuki dalam permintaan merentas tapak, dengan berkesan menghalang serangan CSRF.
Kuki tapak yang sama ialah mekanisme keselamatan yang berharga untuk mengurangkan serangan CSRF dalam aplikasi web. Dengan mengehadkan skop kuki kepada asal yang sama, kuki ini menghalang penyerang daripada mengeksploitasi sesi pengguna untuk melakukan tindakan yang tidak dibenarkan. Nilai "Ketat" memastikan bahawa kuki hanya dihantar dalam permintaan yang berasal dari tapak yang sama, manakala nilai "Lax" membenarkan kuki dihantar dalam permintaan merentas tapak yang selamat. Nilai "Tiada", digabungkan dengan atribut "Secure", mendayakan fungsi merentas tapak sementara masih melindungi daripada serangan CSRF.
Soalan dan jawapan terbaru lain mengenai Asas Keselamatan Aplikasi Web EITC/IS/WASF:
- Adakah pelaksanaan Do Not Track (DNT) dalam pelayar web melindungi daripada cap jari?
- Adakah HTTP Strict Transport Security (HSTS) membantu melindungi daripada serangan penurunan taraf protokol?
- Bagaimanakah serangan pengikat semula DNS berfungsi?
- Adakah serangan XSS yang disimpan berlaku apabila skrip berniat jahat disertakan dalam permintaan kepada aplikasi web dan kemudian dihantar semula kepada pengguna?
- Adakah protokol SSL/TLS digunakan untuk mewujudkan sambungan yang disulitkan dalam HTTPS?
- Apakah pengepala permintaan metadata ambil dan bagaimana ia boleh digunakan untuk membezakan antara permintaan asal dan merentas tapak yang sama?
- Bagaimanakah jenis yang dipercayai mengurangkan permukaan serangan aplikasi web dan memudahkan semakan keselamatan?
- Apakah tujuan dasar lalai dalam jenis yang dipercayai dan bagaimana ia boleh digunakan untuk mengenal pasti tugasan rentetan yang tidak selamat?
- Apakah proses untuk mencipta objek jenis dipercayai menggunakan API jenis dipercayai?
- Bagaimanakah arahan jenis yang dipercayai dalam dasar keselamatan kandungan membantu mengurangkan kelemahan skrip merentas tapak (XSS) berasaskan DOM?
Lihat lebih banyak soalan dan jawapan dalam Asas Keselamatan Aplikasi Web EITC/IS/WASF