鏈接：juejin.cn/post/6859214952704999438
大家學寫程序時，第一行代碼都是 hello world。但是當你開始學習WEB後臺技術時，很多人的第一個功能就是寫的登錄 （小聲：別人我不知道，反正我是）。
但是我在和很多工作經驗較短的同學面試或溝通的時候，發現很多同學雖然都有在簡歷上寫：負責項目的登錄/註冊功能模塊的開發和設計工作，但是都只是簡單的實現了功能邏輯，在安全方面並沒有考慮太多。
這篇文章主要是和大家聊一聊，在設計一個登錄接口時，不僅僅是功能上的實現，在安全方面，我們還需要考慮哪些地方。
還有很多關於接口設計的文章，關注公衆號 Java後端 回覆 666 下載。
暴力破解
只要網站是暴露在公網的，那麼很大概率上會被人盯上，嘗試爆破這種簡單且有效的方式：
通過各種方式獲得了網站的用戶名之後，通過編寫程序來遍歷所有可能的密碼，直至找到正確的密碼爲止
僞代碼如下：
# 密碼字典
password_dict = []
# 登錄接口
login_url = ''
def attack(username):
for password in password_dict:
data = {'username': username, 'password': password}
content = requests.post(login_url, data).content.decode('utf-8')
if 'login success' in content:
print('got it! password is : %s' % password)那麼這種情況，我們要怎麼防範呢？
驗證碼
有聰明的同學就想到了，我可以在它密碼錯誤達到一定次數時，增加驗證碼校驗！比如我們設置，當用戶密碼錯誤達到3次之後，則需要用戶輸入圖片驗證碼纔可以繼續登錄操作：
僞代碼如下：
fail_count = get_from_redis(fail_username)
if fail_count >= 3:
if captcha is None:
return error('需要驗證碼')
check_captcha(captcha)
success = do_login(username, password)
if not success:
set_redis(fail_username, fail_count + 1)僞代碼未考慮併發，實際開發可以考慮加鎖。
這樣確實可以過濾掉一些非法的攻擊，但是以目前的OCR技術來說的話，普通的圖片驗證碼真的很難做到有效的防止機器人（我們就在這個上面喫過大虧）。
當然，我們也可以花錢購買類似於三方公司提供的滑動驗證等驗證方案，但是也並不是100%的安全，一樣可以被破解（慘痛教訓）。
登錄限制
那這時候又有同學說了，那我可以直接限制非正常用戶的登錄操作，當它密碼錯誤達到一定次數時，直接拒絕用戶的登錄，隔一段時間再恢復。比如我們設置某個賬號在登錄時錯誤次數達到10次時，則5分鐘內拒絕該賬號的所有登錄操作。
僞代碼如下：
fail_count = get_from_redis(fail_username)
locked = get_from_redis(lock_username)
if locked:
return error('拒絕登錄')
if fail_count >= 3:
if captcha is None:
return error('需要驗證碼')
check_captcha(captcha)
success = do_login(username, password)
if not success:
set_redis(fail_username, fail_count + 1)
if fail_count + 1 >= 10:
# 失敗超過10次，設置鎖定標記
set_redis(lock_username, true, 300s)umm，這樣確實可以解決用戶密碼被爆破的問題。但是，這樣會帶來另一個風險：攻擊者雖然不能獲取到網站的用戶信息，但是它可以讓我們網站所有的用戶都無法登錄！
攻擊者只需要無限循環遍歷所有的用戶名（即使沒有，隨機也行）進行登錄，那麼這些用戶會永遠處於鎖定狀態，導致正常的用戶無法登錄網站！
IP限制
那既然直接針對用戶名不行的話，我們可以針對IP來處理，直接把攻擊者的IP封了不就萬事大吉了嘛。我們可以設定某個IP下調用登錄接口錯誤次數達到一定時，則禁止該IP進行登錄操作。
僞代碼如下：
ip = request['IP']
fail_count = get_from_redis(fail_ip)
if fail_count > 10:
return error('拒絕登錄')
# 其它邏輯
# do something()
success = do_login(username, password)
if not success:
set_redis(fail_ip, true, 300s)這樣也可以一定程度上解決問題，事實上有很多的限流操作都是針對IP進行的，比如niginx的限流模塊就可以限制一個IP在單位時間內的訪問次數。
但是這裏還是存在問題：
比如現在很多學校、公司都是使用同一個出口IP，如果直接按IP限制，可能會誤殺其它正常的用戶
現在這麼多VPN，攻擊者完全可以在IP被封后切換VPN來攻擊
手機驗證
那難道就沒有一個比較好的方式來防範嗎？ 當然有。 我們可以看到近些年來，幾乎所有的應用都會讓用戶綁定手機，一個是國家的實名制政策要求，第二個是手機基本上和身份證一樣，基本上可以代表一個人的身份標識了。所以很多安全操作都是基於手機驗證來進行的，登錄也可以。
當用戶輸入密碼次數大於3次時，要求用戶輸入驗證碼（最好使用滑動驗證）
當用戶輸入密碼次數大於10次時，彈出手機驗證，需要用戶使用手機驗證碼和密碼雙重認證進行登錄
手機驗證碼防刷就是另一個問題了，這裏不展開，以後再有時間再聊聊我們在驗證碼防刷方面做了哪些工作。
僞代碼如下：
fail_count = get_from_redis(fail_username)
if fail_count > 3:
if captcha is None:
return error('需要驗證碼')
check_captcha(captcha)
if fail_count > 10:
# 大於10次，使用驗證碼和密碼登錄
if dynamic_code is None:
return error('請輸入手機驗證碼')
if not validate_dynamic_code(username, dynamic_code):
delete_dynamic_code(username)
return error('手機驗證碼錯誤')
success = do_login(username, password, dynamic_code)
if not success:
set_redis(fail_username, fail_count + 1)我們結合了上面說的幾種方式的同時，加上了手機驗證碼的驗證模式，基本上可以阻止相當多的一部分惡意攻擊者。但是沒有系統是絕對安全的，我們只能夠儘可能的增加攻擊者的攻擊成本。大家可以根據自己網站的實際情況來選擇合適的策略。
中間人攻擊？
什麼是中間人攻擊
中間人攻擊(man-in-the-middle attack, abbreviated to MITM)，簡單一點來說就是，A和B在通訊過程中，攻擊者通過嗅探、攔截等方式獲取或修改A和B的通訊內容。
舉個栗子：小白給小黃發快遞，途中要經過快遞點A，小黑就躲在快遞點A，或者乾脆自己開一個快遞點B來冒充快遞點A。然後偷偷的拆了小白給小黃的快遞，看看裏面有啥東西。甚至可以把小白的快遞給留下來，自己再打包一個一毛一樣的箱子發給小黃。
那在登錄過程中，如果攻擊者在嗅探到了從客戶端發往服務端的登錄請求，就可以很輕易的獲取到用戶的用戶名和密碼。
HTTPS
防範中間人攻擊最簡單也是最有效的一個操作，更換HTTPS，把網站中所有的HTTP請求修改爲強制使用HTTPS。
爲什麼HTTPS可以防範中間人攻擊？
HTTPS實際上就是在HTTP和TCP協議中間加入了SSL/TLS協議，用於保障數據的安全傳輸。相比於HTTP，HTTPS主要有以下幾個特點：
內容加密
數據完整性
身份驗證
具體的HTTPS原理這裏就不再擴展了，大家可以自行Google
加密傳輸
在HTTPS之外，我們還可以手動對敏感數據進行加密傳輸：
用戶名可以在客戶端使用非對稱加密，在服務端解密
密碼可以在客戶端進行MD5之後傳輸，防止暴露密碼明文
其它
除了上面我們聊的這些以外，其實還有很多其它的工作可以考慮，比如：
操作日誌，用戶的每次登錄和敏感操作都需要記錄日誌（包括IP、設備等）
異常操作或登錄提醒，有了上面的操作日誌，那我們就可以基於日誌做風險提醒，比如用戶在進行非常登錄地登錄、修改密碼、登錄異常時，可以短信提醒用戶
拒絕弱密碼 註冊或修改密碼時，不允許用戶設置弱密碼
防止用戶名被遍歷 有些網站在註冊時，在輸入完用戶名之後，會提示用戶名是否存在。這樣會存在網站的所有用戶名被泄露的風險（遍歷該接口即可），需要在交互或邏輯上做限制
...
後記
現在國家不斷的出臺各種法律，對用戶的數據越來越看重。作爲開發者，我們也需要在保護用戶數據和用戶隱私方面做更多的工作。後面我也會和大家聊一聊，我們在數據安全方面，做了哪些工作，希望可以給到大家一點點幫助。
- END -
更多精彩推薦☞ Google 鼓勵的 13 條代碼審查標準，建議收藏！
☞ 這些SQL錯誤用法，如果經常犯，說明你的水平還很low...☞ 爲啥不能用uuid做MySQL的主鍵？☞ 微信第 1 行代碼曝光！☞ 奇葩公司按代碼行數算工資，員工一個月提成2.6萬遭開除最後，推薦給大家一個有趣有料的公衆號：寫代碼的渣渣鵬,回覆 面試 或 資源 送一你整套開發筆記