安全（1）——登录的设计与攻击

所有的开发当自己能手写web系统的时候，入门的第一课大半是学会自己写个登录的简单的交互。这里梳理下，从简单到实战中的登录差别。

0. 入门新
前端的form表单，属于HTML部分
<form action="/login" method="post">

      <input type="text" name="username" placeholder="Username" required>

      <input type="password" name="password" placeholder="Password" required>

      <input type="submit" value="Login">

</form>
在这里，前端只传递username字段和password密码字段，登录后端。后端拿到username和password，进行验证，通过就表示登录成功，失败就表示登录失败。

1. 验证的加密
   为了防止别人直接看到明文密码，我们需要进行对明文密码加密运算，常用的md5或者sha256加密，其中md5用的比较频繁。而为了让不同人的同样的密码，在后台看不出来一样，我们会额外再user表里面增加一个salt的字段，salt是随机生成的，每个用户注册的时候，都会随机生成一个不同的盐，这样确保登录密码相同情况下，密码也是不同的。一般盐的加密passwd = md5(passwd+salt) 。这样就算拿到了数据库也是不知道用户明文密码的。这是salt字段的由来。

不过在最新的加密验证里面，已经不推荐使用md5进行加密相关验证，使用的是Password_verify 和password_hash 官方库对密码进行对应维护。防止出现时间运算漏洞，暴露密码的相关信息。
 

1. 在验证加密了的情况下，就算数据库不小心被泄露，也不影响用户的账号+密码泄露了。但是攻击者，可以通过HTTP的路由劫持，拿到你post的username和password,这个被称之为中间人攻击，于是我们想到了我们用https证书（这个会导致即使你再信息传输过程中拿到了信息，但是也不知道具体的信息）。这样攻击者拿到你的中途信息是无效的。
   包括最常见的如果不小心使用代理访问网站，数据也会被中途的代理拿到数据，这个时候明文访问的信息是很危险的。
    
2. 加上证书的保护之后，由于网站之前采用的是安全加密访问，攻击者就算拿到了数据信息，也是无效的。攻击者于是开始采用暴力破解手段，首先他们手上有部分常用的密码字典+常用的用户名，然后猜测到你后台的用户名字是admin/root之类的。用代码实现一个模拟提交username+password的脚本。脚本每秒可以提交N个，如果碰巧你的密码是123456789 基本就直接被破解了后台的登录。哪怕你是abc123456这种复杂一点的，他也在字典库里面找到。更何况茫茫网络，很多人手里有一本厚厚的80%人常用的密码字典。于是程序设计的人知道了，提交的时候，额外验证发出服务器端请求的IP，每次超过10次错误，就锁定这个被探测的账号比如admin，该账户直接被封锁24小时。
    
3. 10次就锁定账户的模式，会导致穷举法直接失效。但是他们很可能不需要登录账号，只需要你系统存在某个账号就可以，典型的就是你的用户是手机号为用户名登录的，恶意对手，为了获取你的客户，就把所有可能性手机号一个一个的投喂给你的接口，就等你的接口返回——该账号不存在（继续尝试下个账号）该账号密码错误（表示尝试成功，拿到了你系统内部的客户手机号，这个是最关键的，其他的反而并不是那么重要），这个时候，你限定他尝试错误十次，毫无防御的意义。于是你加了个限制，只允许用户从你的网站提交表单模式，试图限制对方这种一个简单脚本就穿透你防御接口的操作。这样普通直接提交的接口就失效了。你再数据提交的接口新增了reffer来源检测，同时限定了接收的数据格式是表单格式
    
4. 单纯的表单模式提交数据和reffer来源检测，很容易被伪造。于是你想到了再每个页面加入一个随机的token。每次刷新你网站的时候，你都会刷新token，而且该token验证一次就失效。这样远程暴力破解，无法绕过你这个随机参数，必然要每次都获取你这个随机参数。破解的人没有办法，他不能仅仅依靠自己的字典，来跑你接口，必须先取得网站的授权token,然后再开始验证数据，否则直接提示其token错误。这样他验证的成本大幅度上升。
   但是攻击者仍然可以通过反复刷新你页面，通过不同IP，然后伪造头部相关信息，仍然可以像你发出请求。
5. 于是你开始加入验证码。验证码的生成逻辑是有一个外的验证码接口，每次请求之前，随机生成一个验证码，这样客户端会拿到一个随机的验证码，验证码输入通过，才会进行后面操作。跟token的效果类似，但是比token抗拒力加强不少。
   验证码需要进行识别，需要使用到验证码识别库（这个复杂度对于普通探测已经高了很多）。
6. Token+验证码+登录错误报警的模式，已经可以拦截绝大部分非正常访问，但是如果用户是正常登录，但是被人批量群控账号来操作。这个时候，需要对账户的登录IP/登录代理设备信息进行记录，同时加入常见的风险提示库。