Web登錄實例分析

本文小編為大家詳細介紹“Web登錄實例分析”，內容詳細，步驟清晰，細節處理妥當，希望這篇“Web登錄實例分析”文章能幫助大家解決疑惑，下面跟著小編的思路慢慢深入，一起來學習新知識吧。

正文

1. 一個簡單的HTML例子看看用戶信息安全

標準的HTML語法中，支持在form表單中使用<input></input>標簽來創建一個HTTP提交的屬性，現代的WEB登錄中，常見的是下面這樣的表單：

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

form表單會在提交請求時,會獲取form中input標簽存在name的屬性，作為HTTP請求的body中的參數傳遞給后臺，進行登錄校驗。

例如我的賬號是user1，密碼是123456，那么我在提交登錄的時候會給后臺發送的HTTP請求如下（Chrome或者FireFox開發者工具捕獲，需開啟Preserve log）：

可以發現即便password字段是黑點，但是本機仍以明文的形式截獲請求。

2. HTTP協議傳輸直接暴露用戶密碼字段

在網絡傳輸過程中，被嗅探到的話會直接危及用戶信息安全，以Fiddler或Wireshark為例，發現捕獲的HTTP報文中包含敏感信息：

3. 使用加密算法能保證密碼安全嗎？

WEB前端可以通過某種算法，對密碼字段進行加密后，在將密碼作為Http請求的內容進行提交，常見的包括對稱和非對稱加密。

對稱加密：采用對稱密碼編碼技術，它的特點是文件加密和解密使用相同的密鑰加密。

非對稱加密：需要兩個密鑰，公開密鑰（publickey）和私有密鑰（privatekey）。公開密鑰與私有密鑰是一對，如果用公開密鑰對數據進行加密，只有用對應的私有密鑰才能解密；如果用私有密鑰對數據進行加密，那么只有用對應的公開密鑰才能解密。

3.1 使用對稱加密

加密解密在前后臺協商后，似乎是個不錯的辦法，比如，前臺使用一個字符串位移+字符串反轉的簡單方法（舉個例子，當然不能這么簡單）。那么，如果原密碼123456先移位：

123456-->456123

再進行反轉：

456123-->321654

那么這樣簡單的方法似乎可以混淆原密碼，并且輕松由后臺進行相反操作復原。但是這有兩個缺點：

前后端加密解密需要同時修改代碼；

前端加密無非是寫在JS里，但是JS有風險被直接破解從而識別加密方法。

3.2 非對稱加密HTTPS就一定是安全的嗎？

非對稱加密有著公鑰私鑰的存在，公鑰可以隨意獲取，私鑰是用來對公鑰解密的本地存儲，通過公私鑰的機制似乎可以保證傳輸加密并且乃至現在還在使用的HTTPS就是基于這個原理。

但是HTTPS就一定安全嗎？HTTP存在兩種可能的風險：

HTTPS可以保證傳輸過程中的信息不被別人截獲，但是細細思考下，HTTPS是應用層協議，下層采用SSL保證信息安全，但是在客戶端和服務端，密文同樣是可以被截獲的；

HTTPS報文在傳輸過程中，如果客戶端被惡意引導安裝“中間人”的WEB信任證書，那么HTTPS中的“中間人攻擊”一樣會將明文密碼泄露給別人。

4. 結論是，無論HTTP還是HTTPS，密碼必須密文傳輸

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

保證了用戶數據庫內部的密碼信息安全；

傳輸過程中無論如何都不會使得用戶的密文被破解出原密碼；

簡單高效，執行以及編碼難度都不大，各種語言都提供MD5支持，開發快。

5. 那太好了！這樣可以省下HTTPS的錢了，真是這樣嗎？

回到開頭的例子：用戶輸入的用戶名是：user1，密碼是：123456，那么不管在什么協議之下，可以看到實際發送的HTTP/HTTPS報文在MD5處理后是這樣的：

Web 登錄其實沒你想的那么簡單

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

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

5.1 方案一：驗證碼

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

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

5.2 方案二：token令牌

前后端分離場景。現在非常流行的前后端分離的開發模式大大提高了項目的開發效率。職責、分工明確。

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

那么每次從服務器中獲取認證的token，確實能保證HTTP請求是由前端傳回來的了，因為token在每次登陸后都會刪除并被重置，會導致黑客嘗試重放賬號密碼數據信息來登陸的時候導致無法成功登陸。

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

6. 太不容易了！可是還別高興的太早，當心數據被篡改

密碼也加密了，黑客看不到明文了。加上Token了，登陸過程也沒法再被截獲重放了。可是想想這種情況，你在進行某寶上的網絡支付，需要賬號，密碼，金額，token這四個字段進行操作，然后支付的時候你付了1塊錢買了一袋包郵的小浣熊干脆面，某寶結算結束后，你發現你的賬戶余額被扣了1萬元。這又是怎么回事呢？

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

6.1 什么是“數字摘要”

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

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

6.2 數字簽名--水到渠成的技術

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

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

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

讀到這里，這篇“Web登錄實例分析”文章已經介紹完畢，想要掌握這篇文章的知識點還需要大家自己動手實踐使用過才能領會，如果想了解更多相關內容的文章，歡迎關注億速云行業資訊頻道。