it-swarm-id.com

Bagaimana seharusnya pengembang aplikasi web bertahan melawan pembajakan JSON?

Apa pertahanan terbaik melawan pembajakan JSON ?

Adakah yang bisa menyebutkan pertahanan standar, dan menjelaskan kekuatan dan kelemahan mereka? Berikut adalah beberapa pertahanan yang saya lihat disarankan:

  1. Jika respons JSON berisi data rahasia/non-publik, hanya melayani respons jika permintaan diautentikasi (mis., Disertai dengan cookie yang menunjukkan sesi yang diautentikasi).
  2. Jika data JSON berisi sesuatu yang bersifat rahasia atau non-publik, Hostkan itu di URL rahasia yang tidak dapat diakses (mis., URL yang berisi nomor acak crypto berkualitas 128-bit), dan hanya bagikan URL rahasia ini dengan pengguna/klien yang berwenang untuk melihat data.
  3. Letakkan while(1); di awal respons JSON, dan minta klien melepasnya sebelum mem-parsing JSON.
  4. Mintalah klien mengirim permintaan untuk data JSON sebagai POST (bukan GET)), dan minta server mengabaikan permintaan GET untuk data JSON.

Apakah ini semua aman? Adakah alasan untuk memilih salah satu dari ini? Apakah ada pertahanan lain yang saya lewatkan?

42
D.W.

Pertahanan pertama adalah untuk tetap pada spesifikasi dengan menggunakan JSON yang valid yang membutuhkan objek sebagai entitas tingkat atas . Semua serangan yang diketahui didasarkan pada fakta bahwa jika objek tingkat atas adalah array, responsnya valid Java Kode skrip yang dapat diuraikan menggunakan tag <script>.

Jika respons JSON berisi data rahasia/non-publik, hanya melayani respons jika permintaan diautentikasi (mis., Disertai dengan cookie yang menunjukkan sesi yang diautentikasi).

Itulah prasyarat untuk serangan , bukan mitigasi. Jika browser memiliki cookie untuk situs A, itu akan memasukkannya dalam semua permintaan ke situs A. Ini benar bahkan jika permintaan dipicu oleh tag <script> di situs B.

Jika data JSON berisi sesuatu yang bersifat rahasia atau non-publik, Hostkan itu di URL rahasia yang tidak dapat diakses (mis., URL yang berisi nomor acak crypto berkualitas 128-bit), dan hanya bagikan URL rahasia ini dengan pengguna/klien yang berwenang untuk melihat data.

URL tidak dianggap sebagai fitur keamanan . Semua mesin pencari umum memiliki add-on/toolbar browser yang melaporkan setiap URL yang dikunjungi kembali ke vendor mesin pencari. Meskipun mereka hanya melaporkan URL yang dikunjungi secara eksplisit, saya juga tidak akan mengambil risiko untuk URL JSON.

Mintalah klien mengirim permintaan untuk data JSON sebagai POST (bukan GET)), dan minta server mengabaikan permintaan GET untuk data JSON.

Ini akan mencegah termasuk <script>.

Taruh sementara (1); di awal respons JSON, dan minta klien menghapusnya sebelum mem-parsing JSON.

Saya menyarankan versi modifikasi dari pendekatan ini: Tambahkan </* Di awal . while(1) bermasalah karena dua alasan: Pertama kemungkinan memicu pemindai maleware (pada klien, proksi, dan mesin pencari). Kedua itu dapat digunakan untuk serangan DoS terhadap CPU dari web surfer. Serangan-serangan itu jelas berasal dari server Anda.

28

Google menggunakan " cruft yang tidak dapat diparsing " untuk mempertahankan diri dari serangan jenis ini. Kerentanan ini diperbaiki di firefox . Kerentanan muncul dari bagaimana browser mengimplementasikan spesifikasi JSON.

3
rook

1) Jika respons JSON berisi data rahasia/non-publik, hanya sajikan respons jika permintaan diautentikasi (mis., Disertai dengan cookie yang menunjukkan sesi yang diautentikasi). 2) Jika data JSON berisi sesuatu yang bersifat rahasia atau non-publik, Hostkan itu di URL rahasia yang tidak dapat diakses (mis., URL yang berisi nomor acak crypto berkualitas 128-bit), dan hanya bagikan URL rahasia ini dengan pengguna/klien yang berwenang untuk lihat datanya.

Tidak ada alasan untuk melakukan keduanya (1) dan (2).

Yang pertama adalah ABAC dan yang kedua adalah ZBAC. Mencoba untuk mendapatkan pertahanan mendalam dengan menggunakan beberapa skema kontrol akses adalah hal-hal yang terlalu rumit.

3) Letakkan while(1); pada awal respons JSON, dan minta klien melepasnya sebelum mem-parsing JSON.

4) Minta klien mengirim permintaan untuk data JSON sebagai POST (bukan GET)), dan minta server mengabaikan permintaan GET untuk data JSON.

Ini kedengarannya seperti ide bagus dan menambah pertahanan karena membantu memastikan kredensial tidak dapat disalahgunakan.

Selain itu,

5) Hanya melayani JSON dengan data sensitif melalui SSL atau saluran aman lainnya.

untuk mencegah kebocoran data melalui MITM.

2
Mike Samuel