但是我在和很多工作經(jīng)驗較短的同學(xué)面試或溝通的時候，發(fā)現(xiàn)很多同學(xué)雖然都有在簡歷上寫：負責(zé)項目的登錄/注冊功能模塊的開發(fā)和設(shè)計工作，但是都只是簡單的實現(xiàn)了功能邏輯，在安全方面并沒有考慮太多。

這篇文章主要是和大家聊一聊，在設(shè)計一個登錄接口時，不僅僅是功能上的實現(xiàn)，在安全方面，我們還需要考慮哪些地方。

[[401545]]

安全風(fēng)險

暴力破解!

只要網(wǎng)站是暴露在公網(wǎng)的，那么很大概率上會被人盯上，嘗試爆破這種簡單且有效的方式：通過各種方式獲得了網(wǎng)站的用戶名之后，通過編寫程序來遍歷所有可能的密碼，直至找到正確的密碼為止!

偽代碼如下：

# 密碼字典 
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) 

那么這種情況，我們要怎么防范呢?

①驗證碼

有聰明的同學(xué)就想到了，我可以在它密碼錯誤達到一定次數(shù)時，增加驗證碼校驗!

比如我們設(shè)置，當用戶密碼錯誤達到 3 次之后，則需要用戶輸入圖片驗證碼才可以繼續(xù)登錄操作。

偽代碼如下：

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) 

PS：偽代碼未考慮并發(fā)，實際開發(fā)可以考慮加鎖。

這樣確實可以過濾掉一些非法的攻擊，但是以目前的 OCR 技術(shù)來說的話，普通的圖片驗證碼真的很難做到有效的防止機器人(我們就在這個上面吃過大虧)。

當然，我們也可以花錢購買類似于三方公司提供的滑動驗證等驗證方案，但是也并不是 100% 的安全，一樣可以被破解(慘痛教訓(xùn))。

②登錄限制

那這時候又有同學(xué)說了，那我可以直接限制非正常用戶的登錄操作，當它密碼錯誤達到一定次數(shù)時，直接拒絕用戶的登錄，隔一段時間再恢復(fù)。

比如我們設(shè)置某個賬號在登錄時錯誤次數(shù)達到 10 次時，則 5 分鐘內(nèi)拒絕該賬號的所有登錄操作。

偽代碼如下：

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次，設(shè)置鎖定標記 
     set_redis(lock_username, true, 300s) 

這樣確實可以解決用戶密碼被爆破的問題。但是，這樣會帶來另一個風(fēng)險：攻擊者雖然不能獲取到網(wǎng)站的用戶信息，但是它可以讓我們網(wǎng)站所有的用戶都無法登錄!

攻擊者只需要無限循環(huán)遍歷所有的用戶名(即使沒有，隨機也行)進行登錄，那么這些用戶會永遠處于鎖定狀態(tài)，導(dǎo)致正常的用戶無法登錄網(wǎng)站!

③IP 限制

那既然直接針對用戶名不行的話，我們可以針對 IP 來處理，直接把攻擊者的 IP 封了不就萬事大吉了嘛。

我們可以設(shè)定某個 IP 下調(diào)用登錄接口錯誤次數(shù)達到一定時，則禁止該 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 進行的，比如 Nginx 的限流模塊就可以限制一個 IP 在單位時間內(nèi)的訪問次數(shù)。

但是這里還是存在問題：

• 比如現(xiàn)在很多學(xué)校、公司都是使用同一個出口 IP，如果直接按 IP 限制，可能會誤殺其他正常的用戶。
• 現(xiàn)在這么多虛擬專用網(wǎng)，攻擊者完全可以在 IP 被封后切換虛擬專用網(wǎng)來攻擊。

④手機驗證

那難道就沒有一個比較好的方式來防范嗎?當然有。

我們可以看到近些年來，幾乎所有的應(yīng)用都會讓用戶綁定手機，一個是國家的實名制政策要求，第二個是手機基本上和身份證一樣，基本上可以代表一個人的身份標識了。

所以很多安全操作都是基于手機驗證來進行的，登錄也可以：

• 當用戶輸入密碼次數(shù)大于3次時，要求用戶輸入驗證碼(最好使用滑動驗證)。
• 當用戶輸入密碼次數(shù)大于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) 

我們結(jié)合了上面說的幾種方式的同時，加上了手機驗證碼的驗證模式，基本上可以阻止相當多的一部分惡意攻擊者。

但是沒有系統(tǒng)是絕對安全的，我們只能夠盡可能的增加攻擊者的攻擊成本。大家可以根據(jù)自己網(wǎng)站的實際情況來選擇合適的策略。

中間人攻擊?

什么是中間人攻擊?中間人攻擊(man-in-the-middle attack，abbreviated to MITM)，簡單一點來說就是，A 和 B 在通訊過程中，攻擊者通過嗅探、攔截等方式獲取或修改 A 和 B 的通訊內(nèi)容。

舉個例子：小白給小黃發(fā)快遞，途中要經(jīng)過快遞點 A，小黑就躲在快遞點 A，或者干脆自己開一個快遞點 B 來冒充快遞點 A。

然后偷偷的拆了小白給小黃的快遞，看看里面有啥東西。甚至可以把小白的快遞給留下來，自己再打包一個一毛一樣的箱子發(fā)給小黃。

那在登錄過程中，如果攻擊者在嗅探到了從客戶端發(fā)往服務(wù)端的登錄請求，就可以很輕易的獲取到用戶的用戶名和密碼。

①HTTPS

防范中間人攻擊最簡單也是最有效的一個操作，更換 HTTPS，把網(wǎng)站中所有的 HTTP 請求修改為強制使用 HTTPS。

為什么 HTTPS 可以防范中間人攻擊?HTTPS 實際上就是在 HTTP 和 TCP 協(xié)議中間加入了 SSL/TLS 協(xié)議，用于保障數(shù)據(jù)的安全傳輸。

相比于 HTTP，HTTPS 主要有以下幾個特點：

• 內(nèi)容加密
• 數(shù)據(jù)完整性
• 身份驗證

具體的 HTTPS 原理這里就不再擴展了，大家可以自行 Google。

②加密傳輸

在 HTTPS 之外，我們還可以手動對敏感數(shù)據(jù)進行加密傳輸：

• 用戶名可以在客戶端使用非對稱加密，在服務(wù)端解密。
• 密碼可以在客戶端進行 MD5 之后傳輸，防止暴露密碼明文。

其他

除了上面我們聊的這些以外，其實還有很多其他的工作可以考慮，比如：

• 操作日志，用戶的每次登錄和敏感操作都需要記錄日志(包括 IP、設(shè)備等)。
• 異常操作或登錄提醒，有了上面的操作日志，那我們就可以基于日志做風(fēng)險提醒，比如用戶在進行非常登錄地登錄、修改密碼、登錄異常時，可以短信提醒用戶。
• 拒絕弱密碼，注冊或修改密碼時，不允許用戶設(shè)置弱密碼。
• 防止用戶名被遍歷，有些網(wǎng)站在注冊時，在輸入完用戶名之后，會提示用戶名是否存在。這樣會存在網(wǎng)站的所有用戶名被泄露的風(fēng)險(遍歷該接口即可)，需要在交互或邏輯上做限制。
• ...

后記

現(xiàn)在國家不斷的出臺各種法律，對用戶的數(shù)據(jù)越來越看重。作為開發(fā)者，我們也需要在保護用戶數(shù)據(jù)和用戶隱私方面做更多的工作。

后面我也會和大家聊一聊，我們在數(shù)據(jù)安全方面，做了哪些工作，希望可以給到大家一點點幫助。

作者：噠噠噠噠打代碼

編輯：陶家龍

出處：juejin.im/post/6859214952704999438