一、我們首先通過一個簡單的HTML登陸例子去了解一下用戶的信息是否安全

<form action = "http://localhost:8080/Application/login" method = "POST">用戶名：<input name="username" type="text" />密碼：<input name="password" type="password" /><button type="submit">登陸</button> </form>

form表單會在提交請求時,服務(wù)器會獲取form中input標(biāo)簽存在name、password的屬性，作為HTTP請求的body中的參數(shù)傳遞給后臺，進(jìn)行登錄校驗。

執(zhí)行登陸之后，我們可以通過Chrome或者FireFox開發(fā)者工具捕獲，需開啟Preserve log。

可以發(fā)現(xiàn)即便password字段是黑點，但是本機(jī)仍以明文的形式截獲請求。

?

二、HTTP協(xié)議傳輸直接暴露用戶密碼字段

在網(wǎng)絡(luò)傳輸過程中，被嗅探到的話會直接危及用戶信息安全，以Fiddler或Wireshark為例，發(fā)現(xiàn)捕獲的HTTP報文中包含敏感信息：

?

三、HTTPS能保證用戶信息安全嗎？

https://blog.csdn.net/weixin_41480687/article/details/106327531

?

四、無論HTTP還是HTTPS，密碼必須密文傳輸

想想HTTPS也不能一定保障用戶密碼信息，那么就應(yīng)該考慮在應(yīng)用層之上再繼續(xù)對密碼進(jìn)行保護(hù)，也就是編寫代碼來進(jìn)行控制，而不依賴特定協(xié)議，比較容易想到的就是利用不可逆加密散列函數(shù)MD5(string)，用戶在注冊輸入密碼的時候，就存儲MD5(password)值，并且在WEB端先進(jìn)行MD5(password)，然后將密碼傳輸至后臺，與數(shù)據(jù)庫中的密文進(jìn)行比較（PS：MD5函數(shù)在指定位數(shù)的情況下，對相同字符串運算值相同）。

?

五、HTTP請求被偽造

加密登錄成功了。但是，當(dāng)我們慶祝密碼安全的時候，發(fā)現(xiàn)賬戶的錢突然不翼而飛。這是為什么呢？黑客卻笑的很開心：因為他們并不一定要獲取到你的密碼明文，如果直接截獲你的密碼密文，然后發(fā)送給服務(wù)器不是一樣可以登錄嗎？因為數(shù)據(jù)庫里的不也是MD5(password)的一樣的密文嗎？HTTP請求被偽造，一樣可以登錄成功，從而攫取其他的數(shù)據(jù)或者轉(zhuǎn)走余額。

這怎么辦?其實并不難，有很多種解決方法？其實原理都是類似的：那就是服務(wù)器緩存生成隨機(jī)的驗證字段，并發(fā)送給客戶端，當(dāng)客戶端登錄時，把這個一并字段傳給服務(wù)器，用于校驗。

5.1 方案一：驗證碼

MVC場景。控制器將把數(shù)據(jù)的Model封裝到View中，這種存在Session的連接方式，允許了在Session中存取信息。

那么我們可以利用一些開源的驗證碼生成工具，例如JAVA中的Kaptcha，在服務(wù)端存放生成一個驗證碼值以及一個驗證碼的生成圖片，將圖片以Base64編碼，并返回給View，在View中解碼Base64并加載圖片，并于用戶下次登錄時再進(jìn)行比對。

?

5.2 方案二：token令牌

前后端分離場景?，F(xiàn)在非常流行的前后端分離的開發(fā)模式大大提高了項目的開發(fā)效率。職責(zé)、分工明確。

但是由于HTTP是無狀態(tài)的（就是這一次請求并不知道上一次請求的內(nèi)容），當(dāng)用戶登錄時，根據(jù)用戶的username作為key，生成隨機(jī)令牌（例如UUID）作為value緩存在Redis中，并且將token返回給客戶端，當(dāng)客戶端登錄時，將完成校驗，并且刪除Redis中的那條緩存記錄。

那么每次從服務(wù)器中獲取認(rèn)證的token，確實能保證HTTP請求是由前端傳回來的了，因為token在每次登陸后都會刪除并被重置，會導(dǎo)致黑客嘗試重放賬號密碼數(shù)據(jù)信息來登陸的時候?qū)е聼o法成功登陸。

總而言之，就是我拿到了賬號以及密碼的密文也登陸不了，因為，如果請求不包含后臺認(rèn)證的令牌token，是個非法請求。

?

六、注意傳輸?shù)臄?shù)據(jù)被篡改！

密碼也加密了，黑客看不到明文了。加上Token了，登陸過程也沒法再被截獲重放了?？墒窍胂脒@種情況，你在進(jìn)行某寶上的網(wǎng)絡(luò)支付，需要賬號，密碼，金額，token這四個字段進(jìn)行操作，然后支付的時候你付了1塊錢買了一袋包郵的小浣熊干脆面，某寶結(jié)算結(jié)束后，你發(fā)現(xiàn)你的賬戶余額被扣了1萬元。這又是怎么回事呢？

因為即便黑客不登錄，不操作，一樣要搞破壞：當(dāng)請求路由到黑客這邊的時候，截獲數(shù)據(jù)包，然后也不需要登錄，反正賬號密碼都是對的，token也是對的，那么把數(shù)據(jù)包的字段改改，搞破壞就可以了，于是把money改成了1萬，再傳給服務(wù)器，作為受害者就莫名其妙踩了這個坑?？蛇@該怎么解決呢？其實原理類似于HTTPS里的數(shù)字簽名機(jī)制，首先科普下什么是數(shù)字摘要以及數(shù)字簽名：

6.1 什么是“數(shù)字摘要”

我們在下載文件的時候經(jīng)常會看到有的下載站點也提供下載文件的“數(shù)字摘要“，供下載者驗證下載后的文件是否完整，或者說是否和服務(wù)器上的文件”一模一樣“。其實，數(shù)字摘要就是采用單項Hash函數(shù)將需要加密的明文“摘要”成一串固定長度（128位）的密文，這一串密文又稱為數(shù)字指紋，它有固定的長度，而且不同的明文摘要成密文，其結(jié)果總是不同的，而同樣的內(nèi)容信息其摘要必定一致。

因此，“數(shù)字摘要“叫”數(shù)字指紋“可能會更貼切一些?！皵?shù)字摘要“是HTTPS能確保數(shù)據(jù)完整性和防篡改的根本原因。

6.2 數(shù)字簽名--水到渠成的技術(shù)

假如發(fā)送方想把一份報文發(fā)送給接收方，在發(fā)送報文前，發(fā)送方用一個哈希函數(shù)從報文文本中生成報文摘要,然后用自己的私人密鑰對這個摘要進(jìn)行加密，這個加密后的摘要將作為報文的”簽名“和報文一起發(fā)送給接收方，接收方首先用與發(fā)送方一樣的哈希函數(shù)從接收到的原始報文中計算出報文摘要，接著再用發(fā)送方的公用密鑰來對報文附加的數(shù)字簽名進(jìn)行解密，如果這兩個摘要相同、那么接收方就能確認(rèn)報文是從發(fā)送方發(fā)送且沒有被遺漏和修改過！

這就是結(jié)合“非對稱密鑰加解密”和“數(shù)字摘要“技術(shù)所能做的事情，這也就是人們所說的“數(shù)字簽名”技術(shù)。在這個過程中，對傳送數(shù)據(jù)生成摘要并使用私鑰進(jìn)行加密地過程就是生成”數(shù)字簽名“的過程，經(jīng)過加密的數(shù)字摘要，就是”數(shù)字簽名“。

因此，我們可以在WEB端對之前案例中提到的username+MD5(password)+token通過簽名，得到一個字段checkCode，并將checkCode發(fā)送給服務(wù)器，服務(wù)器根據(jù)用戶發(fā)送的checkCode以及自身對原始數(shù)據(jù)簽名進(jìn)行運算比對，從而確認(rèn)數(shù)據(jù)是否中途被篡改，以保持?jǐn)?shù)據(jù)的完整性。

?

七、總結(jié)

看似非常簡單的WEB登錄，其實里面也存在著非常多的安全隱患。這些安全完善的過程是在一個實際WEB項目中遇到的，上面的分析演化是在應(yīng)對項目安全的檢查中所提出的解決方案，多少會有很多不足的地方，希望一起交流探討，共同進(jìn)步！

?

參考鏈接：https://mp.weixin.qq.com/s?__biz=MzI4Njc5NjM1NQ==&mid=2247488249&idx=1&sn=b5f6460bec94d5c47d836fa8bb9499de&chksm=ebd62dd5dca1a4c3b42644aa3e7b3e894c0acedef24de8c69c8a2ee377afb8027e267a7f055b&scene=0&xtrack=1#rd

總結(jié)

以上是生活随笔為你收集整理的对Web登录全面认识的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。