Pertanyaan Mengapa Google menambahkan saat (1); ke tanggapan JSON mereka?


Mengapa Google menambahkan while(1); ke tanggapan JSON (pribadi) mereka?

Misalnya, inilah tanggapan saat mengaktifkan dan menonaktifkan kalender Kalender Google:

while(1);[['u',[['smsSentFlag','false'],['hideInvitations','false'],
  ['remindOnRespondedEventsOnly','true'],
  ['hideInvitations_remindOnRespondedEventsOnly','false_true'],
  ['Calendar ID stripped for privacy','false'],['smsVerifiedFlag','true']]]]

Saya akan menganggap ini adalah untuk mencegah orang melakukan suatu eval() di atasnya, tetapi yang harus Anda lakukan hanyalah mengganti while dan kemudian Anda akan ditetapkan. Saya akan menganggap pencegahan eval adalah memastikan orang-orang menulis kode penguraian JSON yang aman.

Saya telah melihat ini digunakan di beberapa tempat lain, tetapi lebih banyak lagi dengan Google (Mail, Kalender, Kontak, dll.) Anehnya, Google Docs dimulai dengan &&&START&&& sebagai gantinya, dan Google Kontak tampaknya mulai dengan while(1); &&&START&&&.

Apa yang terjadi di sini?


3483
2018-04-19 18:00


asal


Jawaban:


Ini mencegah Pembajakan JSON.

Contoh yang dibikin: katakanlah Google memiliki URL seperti mail.google.com/json?action=inbox yang mengembalikan 50 pesan pertama dari kotak masuk Anda dalam format JSON. Situs web jahat di domain lain tidak dapat membuat permintaan AJAX untuk mendapatkan data ini karena kebijakan asal yang sama, tetapi mereka dapat menyertakan URL melalui <script> menandai. URL dikunjungi dengan anda cookie, dan oleh mengesampingkan metode konstruktor atau aksesor global mereka dapat memiliki metode yang disebut setiap kali atribut objek (array atau hash) diatur, memungkinkan mereka untuk membaca konten JSON.

Itu while(1); atau &&&BLAH&&& mencegah ini: permintaan AJAX di mail.google.com akan memiliki akses penuh ke konten teks, dan dapat menghapusnya. Tapi a <script> penyisipan tag secara membabi buta mengeksekusi JavaScript tanpa pemrosesan apa pun, menghasilkan loop tak hingga atau kesalahan sintaks.

Ini tidak mengatasi masalah pemalsuan permintaan lintas situs.


3760
2018-04-19 18:11



Ini mencegah pengungkapan tanggapan melalui pembajakan JSON.

Secara teori, konten respons HTTP dilindungi oleh Kebijakan Asal yang Sama: halaman dari satu domain tidak dapat memperoleh informasi apa pun dari halaman di domain lain (kecuali diizinkan secara eksplisit).

Seorang penyerang dapat meminta halaman di domain lain atas nama Anda, mis. dengan menggunakan <script src=...> atau <img>tag, tetapi tidak dapat memperoleh informasi apa pun tentang hasilnya (header, konten).

Jadi, jika Anda mengunjungi halaman penyerang, itu tidak bisa membaca email Anda dari gmail.com.

Kecuali bahwa ketika menggunakan tag skrip untuk meminta konten JSON, JSON dieksekusi sebagai Javascript dalam lingkungan terkontrol penyerang. Jika penyerang dapat mengganti konstruktor Array atau Objek atau metode lain yang digunakan selama konstruksi objek, apa pun di JSON akan melewati kode penyerang, dan diungkapkan.

Perhatikan bahwa ini terjadi pada saat JSON dijalankan sebagai Javascript, bukan pada saat itu diurai.

Ada beberapa tindakan balasan:

Memastikan JSON tidak pernah mengeksekusi

Dengan menempatkan while(1); sebelum data JSON, Google memastikan bahwa data JSON tidak pernah dijalankan sebagai Javascript.

Hanya halaman yang sah yang bisa benar-benar mendapatkan seluruh konten, mengupas while(1);, dan parsing sisanya sebagai JSON.

Hal-hal seperti for(;;); telah dilihat di Facebook misalnya, dengan hasil yang sama.

Memastikan JSON bukan Javascript yang valid

Demikian pula, menambahkan token yang tidak valid sebelum JSON, seperti &&&START&&&, pastikan bahwa itu tidak pernah dieksekusi.

Selalu kembalikan JSON dengan Objek di luar

Ini adalah OWASP cara yang direkomendasikan untuk melindungi dari pembajakan JSON, dan merupakan yang kurang intrusif.

Serupa dengan tindakan balasan sebelumnya, ini memastikan bahwa JSON tidak pernah dieksekusi sebagai Javascript.

Objek JSON yang valid, bila tidak tertutup oleh apa pun, tidak valid dalam Javascript:

eval('{"foo":"bar"}')
// SyntaxError: Unexpected token :

Namun ini JSON yang valid:

JSON.parse('{"foo":"bar"}')
// Object {foo: "bar"}

Jadi, pastikan Anda selalu mengembalikan Objek di tingkat atas respons memastikan bahwa JSON tidak valid Javascript, sementara masih berlaku JSON.

Seperti dicatat oleh @hvd di komentar, objek kosong {} adalah Javascript yang valid, dan mengetahui objek kosong itu sendiri mungkin merupakan informasi yang berharga.

Perbandingan metode di atas

Cara OWASP kurang intrusif, karena tidak perlu perubahan pustaka klien, dan mentransfer JSON yang valid. Tidak pasti apakah bug peramban masa lalu atau masa depan dapat mengalahkan ini. Seperti dicatat oleh @oriadam, tidak jelas apakah data bisa bocor dalam kesalahan parse melalui penanganan kesalahan atau tidak (mis. Window.onerror).

Cara Google membutuhkan perpustakaan klien agar dapat mendukung deretisasi otomatis, dan dapat dianggap lebih aman berkaitan dengan bug browser.

Kedua metode tersebut membutuhkan perubahan sisi server untuk menghindari pengembang mengirimkan JSON rentan secara tidak sengaja.


442
2018-02-02 12:09



Ini untuk memastikan beberapa situs lain tidak dapat melakukan trik jahat untuk mencoba mencuri data Anda. Misalnya, oleh mengganti konstruktor array, lalu termasuk URL JSON ini melalui a <script> tag, situs pihak ketiga yang berbahaya dapat mencuri data dari respons JSON. Dengan meletakkan sebuah while(1); di awal, skrip akan digantung sebagai gantinya.

Permintaan situs yang sama menggunakan XHR dan parser JSON terpisah, di sisi lain, dapat dengan mudah mengabaikan while(1); awalan.


343
2018-05-16 02:08



Itu akan menyulitkan pihak ketiga untuk memasukkan respons JSON ke dalam dokumen HTML dengan <script> menandai. Ingat bahwa <script> tag dikecualikan dari Kebijakan Asal yang Sama.


97
2018-04-19 18:04



Ini mencegahnya digunakan sebagai target yang sederhana <script> menandai. (Yah, itu tidak mencegahnya, tapi itu membuatnya tidak menyenangkan.) Dengan cara itu orang-orang jahat tidak bisa hanya meletakkan tag script itu di situs mereka sendiri dan mengandalkan sesi aktif untuk memungkinkan untuk mengambil konten Anda.

sunting - perhatikan komentar (dan jawaban lainnya). Masalahnya ada hubungannya dengan fasilitas built-in subversi, khususnya Object dan Array konstruktor. Mereka dapat diubah sedemikian rupa sehingga JSON yang tidak berbahaya, ketika diurai, dapat memicu kode penyerang.


65
2018-04-19 18:02



Sejak itu <script> tag dibebaskan dari Kebijakan Asal yang Sama yang merupakan kebutuhan keamanan di dunia web, sementara (1) ketika ditambahkan ke respons JSON mencegah penyalahgunaannya di <script>menandai.


3
2017-08-18 04:14