那难道就没有一个比较好的方式来防范吗? 当然有。 我们可以看到近些年来,几乎所有的应用都会让用户绑定手机,一个是国家的实名制政策要求,第二个是手机基本上和身份证一样,基本上可以代表一个人的身份标识了。所以很多安全操作都是基于手机验证来进行的,登录也可以。
- 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)
我们结合了上面说的几种方式的同时,加上了手机验证码的验证模式,基本上可以阻止相当多的一部分恶意攻击者。但是没有系统是绝对安全的,我们只能够尽可能的增加攻击者的攻击成本。大家可以根据自己网站的实际情况来选择合适的策略。
6 N$ B* h+ c' ?5 D" V二、中间人攻击' j1 A9 O+ j/ F" ~
什么是中间人攻击
+ \/ ]0 h8 B2 l) V' ~' o 中间人攻击(man-in-the-middle attack, abbreviated to MITM),简单一点来说就是,A和B在通讯过程中,攻击者通过嗅探、拦截等方式获取或修改A和B的通讯内容。
) G; u* e2 B- c! `' x' l 举个栗子:小白给小黄发快递,途中要经过快递点A,小黑就躲在快递点A,或者干脆自己开一个快递点B来冒充快递点A。然后偷偷的拆了小白给小黄的快递,看看里面有啥东西。甚至可以把小白的快递给留下来,自己再打包一个一毛一样的箱子发给小黄。
# m* N& X# p9 O9 J& |) T8 M 那在登录过程中,如果攻击者在嗅探到了从客户端发往服务端的登录请求,就可以很轻易的获取到用户的用户名和密码。
& Y2 @8 H( [) bHTTPS$ {2 k! X1 N" g W/ r
防范中间人攻击最简单也是最有效的一个操作,更换HTTPS,把网站中所有的HTTP请求修改为强制使用HTTPS。
2 f7 O/ T+ } A( X9 U% Z
为什么HTTPS可以防范中间人攻击?
- F; z4 j: W5 s
HTTPS实际上就是在HTTP和TCP协议中间加入了SSL/TLS协议,用于保障数据的安全传输。相比于HTTP,HTTPS主要有以下几个特点:
4 L, ~! y% U. w1 T- 内容加密
- 数据完整性: {; K4 u. {* E. q8 V' n: r
身份验证
( X6 ?0 X n. O* C2 Y; h7 z 具体的HTTPS原理这里就不再扩展了,大家可以自行Google
: K. I7 Y/ Q/ f9 N# x5 V
加密传输
: p8 Z7 e/ x* K3 }. P4 |. w/ S 在HTTPS之外,我们还可以手动对敏感数据进行加密传输:
~& v# ?; S2 H9 \8 h. H" w- 用户名可以在客户端使用非对称加密,在服务端解密
- 密码可以在客户端进行MD5之后传输,防止暴露密码明文
+ x, ^! ~8 E; r- y) }
三、其它0 ]# d7 u1 S) x' B; X1 e) b; G7 f
除了上面我们聊的这些以外,其实还有很多其它的工作可以考虑,比如:
/ j. y7 J N* e# v0 N& G+ y* o# Z- 操作日志,用户的每次登录和敏感操作都需要记录日志(包括IP、设备等)
- 异常操作或登录提醒,有了上面的操作日志,那我们就可以基于日志做风险提醒,比如用户在进行非常登录地登录、修改密码、登录异常时,可以短信提醒用户
- 拒绝弱密码 注册或修改密码时,不允许用户设置弱密码
- 防止用户名被遍历 有些网站在注册时,在输入完用户名之后,会提示用户名是否存在。这样会存在网站的所有用户名被泄露的风险(遍历该接口即可),需要在交互或逻辑上做限制- U0 v/ o0 k6 M3 m3 z