前言
大家學(xué)寫程序時(shí),第一行代碼都是hello world
。但是當(dāng)你開始學(xué)習(xí) WEB 后臺(tái)技術(shù)時(shí),很多人的第一個(gè)功能就是寫的登錄 (小聲:別人我不知道,反正我是)。
但是我在和很多工作經(jīng)驗(yàn)較短的同學(xué)面試或溝通的時(shí)候,發(fā)現(xiàn)很多同學(xué)雖然都有在簡歷上寫:負(fù)責(zé)項(xiàng)目的登錄/注冊(cè)功能模塊的開發(fā)和設(shè)計(jì)工作
,但是都只是簡單的實(shí)現(xiàn)了功能邏輯,在安全方面并沒有考慮太多。這篇文章主要是和大家聊一聊,在設(shè)計(jì)一個(gè)登錄接口時(shí),不僅僅是功能上的實(shí)現(xiàn),在安全方面,我們還需要考慮哪些地方。
安全風(fēng)險(xiǎn)
暴力破解!
只要網(wǎng)站是暴露在公網(wǎng)的,那么很大概率上會(huì)被人盯上,嘗試爆破這種簡單且有效的方式: 通過各種方式獲得了網(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)
那么這種情況,我們要怎么防范呢?
驗(yàn)證碼
有聰明的同學(xué)就想到了,我可以在它密碼錯(cuò)誤達(dá)到一定次數(shù)時(shí),增加驗(yàn)證碼校驗(yàn)!比如我們?cè)O(shè)置,當(dāng)用戶密碼錯(cuò)誤達(dá)到 3 次之后,則需要用戶輸入圖片驗(yàn)證碼才可以繼續(xù)登錄操作:
偽代碼如下:
fail\_count = get\_from\_redis(fail\_username)
if fail\_count >= 3:
if captcha is None:
return error('需要驗(yàn)證碼')
check\_captcha(captcha)
success = do\_login(username, password)
if not success:
set\_redis(fail\_username, fail\_count + 1)
偽代碼未考慮并發(fā),實(shí)際開發(fā)可以考慮加鎖。
這樣確實(shí)可以過濾掉一些非法的攻擊,但是以目前的 OCR 技術(shù)來說的話,普通的圖片驗(yàn)證碼真的很難做到有效的防止機(jī)器人(我們就在這個(gè)上面吃過大虧)。當(dāng)然,我們也可以花錢購買類似于三方公司提供的滑動(dòng)驗(yàn)證等驗(yàn)證方案,但是也并不是 100% 的安全,一樣可以被破解(慘痛教訓(xùn))。
登錄限制
那這時(shí)候又有同學(xué)說了,那我可以直接限制非正常用戶的登錄操作,當(dāng)它密碼錯(cuò)誤達(dá)到一定次數(shù)時(shí),直接拒絕用戶的登錄,隔一段時(shí)間再恢復(fù)。比如我們?cè)O(shè)置某個(gè)賬號(hào)在登錄時(shí)錯(cuò)誤次數(shù)達(dá)到 10 次時(shí),則 5 分鐘內(nèi)拒絕該賬號(hào)的所有登錄操作。
偽代碼如下:
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('需要驗(yàn)證碼')
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è)置鎖定標(biāo)記
set\_redis(lock\_username, true, 300s)
umm,這樣確實(shí)可以解決用戶密碼被爆破的問題。但是,這樣會(huì)帶來另一個(gè)風(fēng)險(xiǎn):攻擊者雖然不能獲取到網(wǎng)站的用戶信息,但是它可以讓我們網(wǎng)站所有的用戶都無法登錄! 攻擊者只需要無限循環(huán)遍歷所有的用戶名(即使沒有,隨機(jī)也行)進(jìn)行登錄,那么這些用戶會(huì)永遠(yuǎn)處于鎖定狀態(tài),導(dǎo)致正常的用戶無法登錄網(wǎng)站!
IP 限制
那既然直接針對(duì)用戶名不行的話,我們可以針對(duì) IP 來處理,直接把攻擊者的 IP 封了不就萬事大吉了嘛。我們可以設(shè)定某個(gè) IP 下調(diào)用登錄接口錯(cuò)誤次數(shù)達(dá)到一定時(shí),則禁止該 IP 進(jìn)行登錄操作。
偽代碼如下:
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)
這樣也可以一定程度上解決問題,事實(shí)上有很多的限流操作都是針對(duì) IP 進(jìn)行的,比如 niginx 的限流模塊就可以限制一個(gè) IP 在單位時(shí)間內(nèi)的訪問次數(shù)。 但是這里還是存在問題:
- 比如現(xiàn)在很多學(xué)校、公司都是使用同一個(gè)出口 IP,如果直接按 IP 限制,可能會(huì)誤殺其它正常的用戶
- 現(xiàn)在這么多 VPN,攻擊者完全可以在 IP 被封后切換 VPN 來攻擊
手機(jī)驗(yàn)證
那難道就沒有一個(gè)比較好的方式來防范嗎? 當(dāng)然有?!∥覀兛梢钥吹浇┠陙恚瑤缀跛械膽?yīng)用都會(huì)讓用戶綁定手機(jī),一個(gè)是國家的實(shí)名制政策要求,第二個(gè)是手機(jī)基本上和身份證一樣,基本上可以代表一個(gè)人的身份標(biāo)識(shí)了。所以很多安全操作都是基于手機(jī)驗(yàn)證來進(jìn)行的,登錄也可以。
- 當(dāng)用戶輸入密碼次數(shù)大于 3 次時(shí),要求用戶輸入驗(yàn)證碼(最好使用滑動(dòng)驗(yàn)證)
- 當(dāng)用戶輸入密碼次數(shù)大于 10 次時(shí),彈出手機(jī)驗(yàn)證,需要用戶使用手機(jī)驗(yàn)證碼和密碼雙重認(rèn)證進(jìn)行登錄
手機(jī)驗(yàn)證碼防刷就是另一個(gè)問題了,這里不展開,以后再有時(shí)間再聊聊我們?cè)隍?yàn)證碼防刷方面做了哪些工作。
偽代碼如下:
fail\_count = get\_from\_redis(fail\_username)
if fail\_count > 3:
if captcha is None:
return error('需要驗(yàn)證碼')
check\_captcha(captcha)
if fail\_count > 10:
# 大于10次,使用驗(yàn)證碼和密碼登錄
if dynamic\_code is None:
return error('請(qǐng)輸入手機(jī)驗(yàn)證碼')
if not validate\_dynamic\_code(username, dynamic\_code):
delete\_dynamic\_code(username)
return error('手機(jī)驗(yàn)證碼錯(cuò)誤')
success = do\_login(username, password, dynamic\_code)
if not success:
set\_redis(fail\_username, fail\_count + 1)
我們結(jié)合了上面說的幾種方式的同時(shí),加上了手機(jī)驗(yàn)證碼的驗(yàn)證模式,基本上可以阻止相當(dāng)多的一部分惡意攻擊者。但是沒有系統(tǒng)是絕對(duì)安全的,我們只能夠盡可能的增加攻擊者的攻擊成本。大家可以根據(jù)自己網(wǎng)站的實(shí)際情況來選擇合適的策略。
中間人攻擊?
什么是中間人攻擊
中間人攻擊 (man-in-the-middle attack, abbreviated to MITM),簡單一點(diǎn)來說就是,A 和 B 在通訊過程中,攻擊者通過嗅探、攔截等方式獲取或修改 A 和 B 的通訊內(nèi)容。
舉個(gè)栗子: 小白
給小黃
發(fā)快遞,途中要經(jīng)過快遞點(diǎn) A,小黑
就躲在快遞點(diǎn) A,或者干脆自己開一個(gè)快遞點(diǎn) B 來冒充快遞點(diǎn) A。然后偷偷的拆了小白
給小黃
的快遞,看看里面有啥東西。甚至可以把小白
的快遞給留下來,自己再打包一個(gè)一毛一樣的箱子發(fā)給小黃
。
那在登錄過程中,如果攻擊者在嗅探到了從客戶端發(fā)往服務(wù)端的登錄請(qǐng)求,就可以很輕易的獲取到用戶的用戶名和密碼。
HTTPS
防范中間人攻擊最簡單也是最有效的一個(gè)操作,更換 HTTPS,把網(wǎng)站中所有的 HTTP 請(qǐng)求修改為強(qiáng)制使用 HTTPS。
為什么 HTTPS 可以防范中間人攻擊? HTTPS 實(shí)際上就是在 HTTP 和 TCP 協(xié)議中間加入了 SSL/TLS 協(xié)議,用于保障數(shù)據(jù)的安全傳輸。相比于 HTTP,HTTPS 主要有以下幾個(gè)特點(diǎn):
- 內(nèi)容加密
- 數(shù)據(jù)完整性
- 身份驗(yàn)證
具體的 HTTPS 原理這里就不再擴(kuò)展了,大家可以自行 Google
加密傳輸
在 HTTPS 之外,我們還可以手動(dòng)對(duì)敏感數(shù)據(jù)進(jìn)行加密傳輸:
- 用戶名可以在客戶端使用非對(duì)稱加密,在服務(wù)端解密
- 密碼可以在客戶端進(jìn)行 MD5 之后傳輸,防止暴露密碼明文
其它
除了上面我們聊的這些以外,其實(shí)還有很多其它的工作可以考慮,比如:
- 操作日志,用戶的每次登錄和敏感操作都需要記錄日志(包括 IP、設(shè)備等)
- 異常操作或登錄提醒,有了上面的操作日志,那我們就可以基于日志做風(fēng)險(xiǎn)提醒,比如用戶在進(jìn)行非常登錄地登錄、修改密碼、登錄異常時(shí),可以短信提醒用戶
- 拒絕弱密碼 注冊(cè)或修改密碼時(shí),不允許用戶設(shè)置弱密碼
- 防止用戶名被遍歷 有些網(wǎng)站在注冊(cè)時(shí),在輸入完用戶名之后,會(huì)提示用戶名是否存在。這樣會(huì)存在網(wǎng)站的所有用戶名被泄露的風(fēng)險(xiǎn)(遍歷該接口即可),需要在交互或邏輯上做限制
- ...
后記
現(xiàn)在國家不斷的出臺(tái)各種法律,對(duì)用戶的數(shù)據(jù)越來越看重。作為開發(fā)者,我們也需要在保護(hù)用戶數(shù)據(jù)和用戶隱私方面做更多的工作。后面我也會(huì)和大家聊一聊,我們?cè)跀?shù)據(jù)安全方面,做了哪些工作,希望可以給到大家一點(diǎn)點(diǎn)幫助。
以上就是W3Cschool編程獅
關(guān)于你的登錄接口真的安全嗎?的相關(guān)介紹了,希望對(duì)大家有所幫助。