Apakah Saya Terlalu Banyak Teknik Jika Saya Mempertimbangkan Kesalahan Pengguna?


12

Apakah ini rekayasa berlebihan jika saya menambahkan perlindungan terhadap kesalahan yang disengaja pengguna (dengan kata lain), jika bahaya yang dapat ditimbulkan pengguna tidak terkait dengan kode saya?

Untuk memperjelas, saya memaparkan layanan JSON RESTful sederhana seperti ini:

GET /items - to retrieve list of user's items
PUT /items/id - to modify an item
POST /items - to add a new item

Layanan itu sendiri tidak dimaksudkan untuk digunakan melalui browser, tetapi hanya dari aplikasi pihak ketiga, yang dikendalikan oleh pengguna (seperti aplikasi telepon, aplikasi desktop, dll.). Juga, layanan itu sendiri harus stateless (yaitu sesi-kurang).

Otentikasi dilakukan dengan Otentikasi Dasar melalui SSL.

Saya berbicara tentang satu kemungkinan perilaku "berbahaya" seperti ini:

Pengguna memasukkan url GET di browser (tanpa alasan tapi ...). Browser meminta otentikasi dasar, memprosesnya, dan menyimpan otentikasi untuk sesi browsing saat ini. Tanpa menutup browser, pengguna mengunjungi situs web jahat, yang memiliki javascript CSRF / XSRF berbahaya yang membuat POST untuk layanan kami.

Skenario di atas sangat tidak mungkin, dan saya tahu bahwa dari perspektif bisnis saya tidak perlu terlalu khawatir. Tetapi demi memperbaiki situasi, apakah Anda berpikir bahwa jika nama pengguna / kata sandi diperlukan dalam data JSON POST juga, akan membantu?

Atau haruskah saya menghentikan Auth Dasar sama sekali, menyingkirkan GET, dan hanya menggunakan POST / PUT dengan informasi otorisasi di dalamnya? Karena informasi yang diambil melalui GET juga bisa sensitif.

Di sisi lain, apakah menggunakan header kustom dianggap sebagai implementasi REST murni? Saya bisa menghapus Auth Dasar, dan menggunakan header kustom. Dengan begitu, setidaknya serangan CSRF dari browser dapat dihindari, dan aplikasi yang menggunakan layanan akan mengatur nama pengguna / kata sandi di heather khusus. Buruk untuk pendekatan ini adalah, bahwa sekarang layanan tidak dapat dikonsumsi dari browser.


3
Seperti halnya jawaban saya, saya juga ingin meninggalkan pernyataan ini, saya pikir ini mungkin akan lebih baik dijawab di SO atau Keamanan
Jeff Langemeier

1
Saya pikir Anda telah mengganti PUT dan POST seperti yang didefinisikan oleh RFC 2616 ( tools.ietf.org/html/rfc2616#section-9.5 ).
Svante

Jawaban:


6

Rekayasa berlebihan? Tidak semuanya. Tindakan anti-XSRF adalah bagian penting dari aplikasi atau layanan web yang aman. Ini mungkin atau mungkin tidak "sangat tidak mungkin" bahwa seseorang akan memilih untuk menyerang Anda, tetapi itu tidak membuat perangkat lunak Anda kurang aman.

Sistem umumnya telah diserang menggunakan XSRF, dan meskipun hasilnya kurang segera - jelas buruk daripada SQL-injection atau XSS, mereka cukup buruk untuk kompromi semua fitur yang dapat berinteraksi dengan pengguna.

Itu berarti Anda tidak dapat memiliki antarmuka TENANG "murni" di mana satu - satunya parameter adalah properti panggilan itu sendiri. Anda harus memasukkan sesuatu dalam permintaan yang tidak dapat ditebak oleh penyerang. Itu bisa menjadi pasangan username-password, tetapi itu jauh dari satu-satunya pilihan yang mungkin. Anda dapat memiliki nama pengguna bersama dengan token yang dihasilkan dari hash kata sandi asin. Anda dapat memiliki token yang dikeluarkan oleh layanan itu sendiri pada waktu otentikasi (yang dapat diingat dalam sesi, atau diverifikasi secara kriptografis).

saya harus menyingkirkan GET

Tidak, permintaan GET digunakan untuk permintaan baca yang tidak memiliki operasi penulisan aktif (mereka "idempoten"). Hanya operasi tulis yang memerlukan perlindungan XSRF.


Bagaimana jika permintaan GET dapat mengungkapkan informasi sensitif?
Sunny

@ Sunny: Apa yang Anda pertimbangkan data sensitif?
Chris

2
Chris, jika saya menjadi paranoid, setiap data sensitif, jika itu diterima oleh pengguna "salah" :). Ini teoretis.
Sunny

tolong, tinjau perubahan dalam pertanyaan yang saya tambahkan.
Sunny

1
Tidak apa-apa jika respons (apakah GET atau metode lain) mengandung data yang hanya harus dilihat pengguna. Serangan XSRF hanya memungkinkan penyerang membuat pengguna membuat permintaan tertentu, itu tidak memungkinkan mereka untuk membaca respons yang muncul dari permintaan itu. Kecuali jika skrip target dibuat dengan cara khusus untuk memungkinkan halaman pihak ketiga untuk membacanya dari <script>tag, baik sengaja ("JSONP") atau tidak sengaja ( JSON tidak dilindungi ).
bobince

32

Jangan pernah percaya apapun. Setiap permintaan adalah serangan. Setiap pengguna adalah seorang hacker. Jika Anda berkembang dengan pola pikir ini, aplikasi Anda akan jauh lebih aman, stabil, dan kecil kemungkinannya akan dibajak oleh pengguna jahat. Yang diperlukan hanyalah satu orang pintar untuk menemukan jalan keluar keamanan Anda agar Anda berada dalam masalah serius dengan data Anda (salah satu sumber daya Anda yang paling berharga ).

Jika Anda telah mengidentifikasi lubang keamanan di aplikasi Anda, lakukan semua yang Anda pikir perlu Anda lakukan untuk menyumbat celah. API Anda, khususnya, harus menjadi perangkat lunak yang paling tidak dapat dipercaya yang ada. Saya akan membutuhkan kredensial dan pergi dengan permintaan Posting.


4
YAY untuk paranoia! Anda memang punya musuh! (Dan +1 untuk Setiap permintaan adalah serangan )
Treb

0

Jika kode dibuat dan dipelihara, kasus tepi harus dilihat dan ditangani berdasarkan kasus per kasus.

MEMPERBAIKI AKIBAT BEBERAPA KESALAHAN PADA BAGIAN SAYA:

GET masih harus digunakan sebagai bagian dari layanan RESTful yang tepat, otentikasi harus tetap ada dalam hal apa pun. Apa yang saya coba duga adalah bahwa untuk tujuan keamanan, GET hampir sama dengan POST tetapi postingannya berfungsi tanpa meletakkan informasi di address bar, yang cenderung menjadi perbedaan keamanan yang besar (dan mengapa saya tidak suka GET), tetapi sebagai diposting oleh @Lee,

GET requests are used to retrieve resources, and PUT/POST are used to add/update 
resources so it would be completely against expectations for a RESTful API to use
PUT/POST to get data. 

Karena ini akan digunakan oleh aplikasi pihak ketiga, seseorang harus mengikuti praktik yang baik untuk layanan RESTful sehingga pelaksana akhir tidak akan bingung pada bagian ini.


3
Apa bedanya GET dari POST dalam hal keamanan? Keduanya dikirim secara polos melalui transportasi (HTTP atau HTTPS), satu-satunya perbedaan adalah bahwa string GET terlihat di bilah alamat.
tdammers

1
@Sunny: POST sama terbuka dengan GET dalam hal ini. Nyalakan telnet dan bicara ke server web jika Anda tidak percaya.
tdammers

1
@ Jeff: Alasan saya membawa telnet (atau curl, wget, atau sniffer kuno yang bagus) adalah karena ia memungkinkan Anda untuk melihat aliran data lengkap. Ya, HTTPS menyembunyikan informasi ini dari eavesdropper, tetapi siapa pun di kedua ujung koneksi SSL dapat melihat dengan tepat apa yang dilihat telnet.
tdammers

1
@Jeremy: POST tidak menampilkan parameter di bilah alamat, tetapi karena data hanya terlihat di aliran HTTP yang sebenarnya, Anda benar secara keseluruhan.
tdammers

7
Permintaan GET digunakan untuk mengambil sumber daya, dan PUT / POST digunakan untuk menambah / memperbarui sumber daya sehingga akan sepenuhnya bertentangan dengan harapan untuk RESTful API untuk menggunakan PUT / POST untuk mendapatkan data.
Lee

0

Anda harus mempertimbangkan semua kemungkinan yang masuk akal, termasuk pengguna yang secara aktif jahat dan (berhasil) merekayasa balik segala hambatan "keamanan karena ketidakjelasan".

Tetapi pada saat yang sama, Anda harus menilai dampak peretasan yang berhasil, dan kemungkinan upaya yang dilakukan. Contohnya:

  • Layanan internal yang dilindungi oleh firewall yang solid cenderung tidak dapat diserang daripada layanan di internet publik.

  • Dampak seseorang menjatuhkan forum diskusi pelanggan kurang dari dampak mereka mencuri kartu kredit pelanggan.


Maksud saya adalah "keamanan total" adalah "sangat mahal" ... dan praktis tidak bisa diraih. Idealnya Anda harus membuat keputusan tentang di mana harus menarik garis berdasarkan analisis biaya-manfaat yang menyeluruh.


Terima kasih. Pertanyaannya bukan tentang melindungi "dari" pengguna, tetapi melindungi pengguna itu sendiri jika mereka bertindak secara tidak bertanggung jawab. Tetapi jawaban Anda membuat beberapa poin bagus.
Sunny
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.