Pembelajaran nod bercakap tentang prinsip kerja pengesahan log masuk Cookie-Session

Pada masa ini, kebanyakan sistem amat diperlukan untuk fungsi pengesahan log masuk Ini terutamanya untuk menyimpan status pengguna dan mengehadkan pelbagai tingkah laku pengguna dan berkesan untuk mengawal kebenaran pengguna. Sebagai contoh, apabila pengguna log masuk ke Weibo, operasi penyiaran, mengikuti dan mengulas harus dilakukan di bawah status pengguna selepas log masuk.

Terdapat dua cara utama untuk melaksanakan pengesahan log masuk: Cookie&Session dan JWT Dalam bahagian ini, kami akan memberikan pengenalan terperinci kepada prinsip kerja Cookie&Session, dan kemudian Artikel akan berturut-turut menerangkan JWT dan cara menggunakan Cookie&Session dan JWT untuk menambah baik sistem pengurusan pengguna mudah yang kami bina dalam bahagian sebelumnya. [Pengesyoran tutorial berkaitan: tutorial video nodejs]

1️⃣ Cookie&Session

Kami tahu bahawa HTTP adalah tanpa status. Dalam erti kata lain, status antara peminta HTTP dan responden tidak boleh dikekalkan, dan semuanya adalah satu kali Ia tidak tahu apa yang berlaku dalam permintaan sebelumnya dan seterusnya. Tetapi dalam beberapa senario, kita perlu mengekalkan keadaan. Contoh yang paling biasa ialah apabila pengguna log masuk ke Weibo, dia boleh menyiarkan, mengikuti dan mengulas di bawah status pengguna selepas log masuk.

Pada masa ini, anda boleh memperkenalkan Cookie dan Session untuk menyimpan status log masuk pengguna.

Artikel ini terutamanya memperkenalkan prinsip kerja Cookie-Session menggunakan untuk pengesahan log masuk Untuk pengenalan terperinci Cookie dan Session, sila rujuk Artikel bos ini. : Penjelasan terperinci tentang Kuki dan Sesi

Mengapa tidak menggunakan kuki sahaja?

Cookie disimpan dalam penyemak imbas Anda boleh membuka 控制台 dalam penyemak imbas, pilih 应用 dan cari 存储 dalam Cookie untuk melihat:

<.>

Apabila klien menghantar permintaan rangkaian kepada pelayan, penyemak imbas akan

secara automatik menambah pada Cookie pengepala permintaan , supaya perkhidmatan Anda boleh mendapatkan ini pada pelanggan, seperti berikut: Cookie

Setelah mengetahui prinsip ini, kita boleh berfikir bahawa jika pengguna log masuk ke sistem: pelanggan terdiri daripada bahagian maklumat Log masuk pengguna (seperti

, username, dsb.) menjana id dan menyimpannya dalam penyemak imbas, maka setiap permintaan rangkaian seterusnya akan membawa Cookie secara automatik. Selepas Cookie

, biarkan pelayan menentukan sama ada pengguna telah log masuk berdasarkan sama ada permintaan itu membawa

dan sama ada Cookie yang dibawa mengandungi Cookie dan username yang sah dengan cara ini, milik pengguna Bukankah status log masuk disimpan? id

Kembali ke contoh Weibo yang kami nyatakan di atas Menurut proses ini, apabila pengguna log masuk,

telah disimpan pada masa ini, pengguna perlu log masuk untuk menerbitkan, mengikuti, mengulas , dsb. Apabila menggunakan operasi, kami boleh menentukan terlebih dahulu sama ada Cookie wujud Jika ia wujud dan Cookie mengandungi Cookie pengguna, maka kami boleh membenarkan operasi pengguna ini (operasi ini biasanya memerlukan , anda boleh mendapatkannya daripada id pada masa ini). Sebaliknya, jika id tidak wujud atau Cookie tidak sah, maka operasi pengguna akan dilarang. CookieCookieBercakap tentang perkara ini, anda mungkin bertanya:

Memandangkan

boleh mencapai kesan yang kita inginkan, mengapa kita perlu menggunakan ? CookieSessionIni kerana

mudah dipalsukan! , jika kami tahu bahawa maklumat yang disimpan dalam Cookie ialah dan Cookie (walaupun kami tidak tahu, kami masih boleh mencari username dalam badan permintaan permintaan rangkaian selepas log masuk ), maka kami pasti boleh menyimpan id palsu secara manual dalam penyemak imbas tanpa log masuk: CookieCookie

Setelah berkata demikian, anda sepatutnya dapat memahami mengapa

tidak boleh digunakan sendiri, kan?

Cookie

Bagaimanakah Sesi digabungkan dengan Kuki?

sebenarnya dilaksanakan berdasarkan

, dan Session disimpan dalam memori atau pangkalan data pelayan. Cookie

Apabila pengguna berjaya log masuk, pengesahan log masuk menggunakan Cookie&Session akan melaksanakan operasi berikut:

• dijana oleh pelayan Session dan SessionId; >

  >

  biasanya dijana berdasarkan maklumat log masuk pengguna, seperti nama pengguna, Session, dsb. id Jika
  dibandingkan dengan kunci, maka Session adalah bersamaan dengan kunci kunci. SessionId

• Pelayan akan menyimpan

  dalam memori atau pangkalan data Session

• Pelayan akan menyimpan

  dalam yang diminta; Medan SessionId dalam pengepala respons (response objek) dihantar kepada klien Set-Cookie

• Selepas klien menerima

  , ia akan menukar nilai (juga, Set-Cookie) disimpan dalam Set-Cookie; setiap permintaan rangkaian selepas SessionIdCookie

akan
• secara automatik

  membawa , iaitu membawa ini ; CookieSessionId

Apabila pelayan menerima permintaan seterusnya, ia memperoleh
• pada permintaan, iaitu, ia memperoleh

  , dan kemudian bertanya dan mengesahkan ia melalui CookieSessionId SessionId yang disimpan di bahagian pelayan Jika pengesahan berjaya, menunjukkan bahawa ini sah, permintaan akan diluluskan. SessionSessionId

Imej:

2️⃣ Kecacatan Kuki&Sesi

Isu storan

Untuk menyimpan status log masuk pengguna, kami perlu menjana dan menyimpan

untuk setiap pengguna log masuk, yang pasti akan menyebabkan masalah berikut:

Session

Jika

disimpan dalam memori, maka apabila pelayan dimulakan semula, semua
• dalam memori akan dikosongkan, maka status log masuk semua pengguna akan tamat tempoh, dan apabila bilangan pengguna adalah besar Apabila ia besar, penggunaan memori yang berlebihan pasti akan menjejaskan prestasi pelayan. SessionSessionJika
disimpan dalam pangkalan data, walaupun ia boleh menyelesaikan masalah tamat tempoh status log masuk pengguna akibat server restart, apabila bilangan pengguna ramai, penyelenggaraan pangkalan data ini akan menjadi agak sukar.
• SessionJika antara muka yang dipanggil di halaman hadapan datang daripada dua pelayan (iaitu dua set pangkalan data), untuk merealisasikan perkongsian
antara kedua-dua pelayan,
• biasanya disimpan dalam pangkalan data yang berasingan ini menjadikan keseluruhan projek lebih kompleks dan lebih sukar untuk diselenggara. SessionSession
  

Masalah CSRF

CSRF

bermaksud pemalsuan permintaan silang tapak. Pemalsuan permintaan merentas tapak, tapak web yang menggunakan untuk pengesahan akan menghadapi ancaman besar atau kecil Kami menggunakan contoh tapak web bank untuk memperkenalkan prinsip serangan CSRF: CookieCSRFAndaikan sebuah bank

menggunakan

untuk pengesahan log masuk, dan 网站A yang digunakan untuk menjalankan operasi pemindahan Cookie&Session di tapak web ialah: Api地址http://www.grillbankapi.com/?account=AccoutName&amount=1000

Parameter:

mewakili nama akaun, api mewakili jumlah pindahan. accountamount

Kemudian, penyerang berniat jahat boleh meletakkan kod berikut pada

yang lain:

网站B

<img  alt="Pembelajaran nod bercakap tentang prinsip kerja pengesahan log masuk Cookie-Session" >

Nota:

teg

ialah img ialah src operasi pemindahan dan parameter 网站A ialah Ailjx, dan api地址 ialah 1000. Maksudnya, ini account bersamaan dengan amount yang dipanggil apabila nama akaun ialah Ailjx dan memindahkan 1000. api地址api

Jika pengguna dengan nama akaun Ailjx baru sahaja melawat

tidak lama dahulu, maklumat log masuk belum tamat tempoh (

daripada 网站A wujud dan sah). 网站ACookie Kemudian apabila Ailjx mengakses

berniat jahat ini, teg

di atas akan dimuatkan, dan penyemak imbas secara automatik akan meminta laluan 网站B teg img, iaitu permintaan img (Kami merekodkan permintaan ini sebagai src), dan kerana http://www.grillbankapi.com/?account=Ailjx&amount=1000 disimpan dalam penyemak imbas dan penyemak imbas secara automatik akan membawa 请求Q apabila menghantar permintaan, jadi Cookie akan membawa Ailjx secara automatik dalam Cookie 请求Qsijil, hasilnya 网站ACookie ini akan lulus, kemudian Ailjx akan 请求Qkehilangan 1000 dana.

URL hasad jenis ini boleh mengambil pelbagai bentuk dan disembunyikan di banyak tempat di halaman web. Selain itu, penyerang tidak perlu mengawal tapak web yang mengehos URL berniat jahat. Contohnya, dia boleh menyembunyikan alamat ini dalam forum, blog atau mana-mana tapak web lain dengan kandungan yang dijana pengguna. Ini bermaknajika tiada langkah pertahanan yang sesuai di bahagian pelayan, pengguna masih berisiko diserang walaupun mereka melawati tapak web yang biasa dan dipercayai.

Seperti yang anda boleh lihat daripada contoh, penyerang tidak boleh terus mengawal akaun pengguna melalui serangan CSRF, dan dia juga tidak boleh mencuri sebarang maklumat pengguna secara langsung. Apa yang boleh mereka lakukan ialah menipu penyemak imbas pengguna untuk menjalankan operasi bagi pihak pengguna.

Ini adalah masalah dengan menggunakan Cookie&Session untuk pengesahan log masuk, jadi bagaimana kita menyelesaikan masalah ini? Ini memerlukan pengenalan konsep JWT dan menggunakan token untuk pengesahan log masuk, yang akan kami terangkan dalam artikel seterusnya.

Untuk lebih banyak pengetahuan berkaitan nod, sila lawati: tutorial nodejs!

Atas ialah kandungan terperinci Pembelajaran nod bercakap tentang prinsip kerja pengesahan log masuk Cookie-Session. Untuk maklumat lanjut, sila ikut artikel berkaitan lain di laman web China PHP!