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:

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

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

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

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:

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

Cookie

Bagaimanakah Sesi digabungkan dengan Kuki?

, 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

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

Session

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

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

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

网站B

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

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

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

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.

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!