web 登录验证机制的攻与防

学习打卡计划是信安之路知识星球开启的 “每天读书一小时，挑战打卡一百天” 主题活动，能够坚持学习打卡 100 天的同学可以获得信安之路提供的百分成就徽章和证书，学习书籍可以自选，主要目的是养成每日读书学习的好习惯，并将自己的学习心得分享出来供大家学习。

下图为目前星球成员的最新打卡内容，还有目前打卡活动的排行榜，坚持学习是一件非常难的事情，随着时间的推移，坚持的人越来越少，但这就是真实的情况，能够坚持到最后的一定是少数。

打卡一：web 实战 P210-248

这部分内容主要讲关于验证机制的安全问题，在学习这个之前，首先要知道关于验证都有哪些功能，对于不同的功能又有不同的安全风险和问题。验证登录的目的是对用户做区分，根据用户的登录信息来确定用户的访问权限，这块设计几个方面：登录、注册、重置/忘记密码、会话保持，下面根据不同的功能来总结不同的安全问题。

登录功能，这里涉及用户的账号密码，通常用户的账户信息都存在于数据库中，用户提交账号和密码到后端服务进行验证，服务器验证时可能由于程序员代码问题，将账号和密码直接通过拼接字符串的方式代入验证，从而导致万能密码的问题，通过构造 payload：admin or 1=1-- 就可以完成认证。排除代码本身的问题，普遍存在暴力破解的问题，重复提交账号密码进行认证，通常的防御措施是采用强验证码，从而引出验证码识别绕过的问题，既然涉及密码问题，就会存在因为用户安全意识问题导致的弱口令。防御暴力破解还有登录次数限制，由于登录次数的记录在客户端的 cookie 中从而导致这个策略失效，验证次数的统计还是需要在后端记录，不能相信客户端提交的任何数据。

注册功能，由于系统内有高权限的账户，比如 admin，在注册时如果没有验证用户名是否已经存在，那么就可以注册 admin 账户，从而达到越权的目的，注册还有一个问题就是垃圾注册，导致大量僵尸账户注册，成为别人薅羊毛的工具，防垃圾注册主要方式也是强验证码，还有就是限制单个手机号只能注册一个账户，来限制垃圾注册问题。

重置和忘记密码功能主要用来在用户忘记自己的密码时进行重置，重置密码通常要验证多个因素，比如短信验证码、账号和原始密码、邮件验证等，这里主要出现过的安全问题包括：验证码可枚举、验证链接不失效、验证码绕过、验证因素可预测等。

会话保持，通常使用 cookie 来记录用户的会话信息，这里的安全问题主要来自信任客户端提交的 cookie，cookie 中如果有明显的象征身份的信息，比如 admin=1 表示管理员，admin=0 表示普通用户，那么攻击者就可以修改 cookie 的值来进行越权。

还有些安全问题时认证信息被劫持，比如未使用 https 的网站，登录时使用明文的形式，通过抓包的方式就可以获取用户提交的数据，对于认证而言，post 的方式相对是比较安全的，如果是用 get 方式提交账户信息，那么敏感信息就有可能被劫持，或者被默认记录与网站的日志中，造成敏感数据的二次泄漏。

关于验证是如今网站的核心安全功能，也是最容易出安全问题的地方，之前有个小伙伴在群里说，一个登录口，由于登录错误的提示比较详细，比如用户名错误时提示用户名错误，密码错误时提示密码错误，他不认为是个安全问题，其实也算安全风险，因为可以让攻击者先猜测用户名，枚举用户名，然后再根据已知用户名进行密码破解，大大的降低了攻击难度。

关于登录这块的安全学习，在这里留两个实际操作的作业：

作业一：通过搜索以前寻找登录口，收集一些常用弱口令字典，使用 burp 来对该登录口进行暴力破解操作，字典至少 100 个，最终目标是找出一个存在的用户名，并且尝试密码 100 次，爆破过程使用 burp 实现。

作业二：使用自己擅长的语言，编写一个登录页面，后端使用数据库，用户密码在数据库中使用 md5 存储，也可以使用其他加密手段，最终目标是实现可访问的登录口，并使用 burp 进行撞库操作，撞库的原理是使用其他网站的账号密码库来进行尝试，这个可以自己使用脚本生成一个账号和密码对应的字典库。

以上作业，大家可以将过程编写成报告或者录制成小视频在圈子内进行分享，涉及代码可以贴出来让大家审计，说不定有惊喜，期待大家的成果。

打卡二：web 实战 P249-260

这部分主要讲了三点，一是认证代码缺陷，在验证登录时将账号和密码一起带入数据库查询语句，判断是否可以查询出内容，如果查询出数据则认为认证成功，否则为失败，还做了异常处理，正常来说出异常为失败才对，而代码中写的是异常之后则为成功，那么就存在问题，我们可以通过构造畸形的参数，来触发异常，从而实现认证成功。

二是多步骤认证的实现，比如先进行账号和密码的认证，然后再根据用户名，这里的用户名是通过隐藏表单来提交，这里通过数据包可以修改，从而导致越权问题的出现，用一个普通账号认证成功，然后第二步伪造任意用户名认证，获取任意用户的数据。

三是存入数据库的密码加密方式的问题，以前都是明文存储，只要存在 SQL 注入的问题，就能获取所有用户的明文密码的问题，后来出现了 md5、sha1 等，为了对抗破解，出现二次 md5、加 salt 加密等。

打卡三：web 实战 P261-272

这部分内容主要讲如何针对验证机制做安全防御，安全往往与用户体验成反比，越安全的系统，使用起来越繁琐，安全的目标是要平衡与业务的关系，找到平衡点，在不那么影响业务的前提下，实现安全防御的最优解，所有安全策略比一定都要在业务系统上实现，选择适合当前系统的即可。

1、限制用户密码的设置规范：大于 8 位必须包含大小字母和数字特殊字符（这是大部分网站的设置）、用户名唯一（避免注册时用户身份被冒用）、默认密码要足够随机（一些系统注册时不是自己设置，而是给初始化密码，很多情况是默认相同的密码或者密码按一定规律生成，这样容易被恶意猜解）。

2、认证信息安全传输：全站 HTTPS、提交使用 POST 不用 GET 或 Cookie、存入数据库的密码要进行加密（sha256、md5+salt）、定期修改密码（办公网经常 3 月强制失效改一次）、存在初始化密码的系统，首次登录强制修改密码、密保问题使用下拉框来抵御键盘记录器。

3、密码认证安全：区分大小写，不过滤和修改字符，不截取字段、异常处理，清除所有会话数据、多阶段认证信息禁止由客户端提供数据。

4、防止信息泄漏：对于数据提交返回的错误信息一致，无区分（防止通过返回信息判断是用户名还是密码错误）、对于达到错误次数锁定的功能，可能因为锁定这个功能来枚举有效用户、注册时给用户生产唯一用户名，如果是使用邮箱注册，已注册和未注册返回同样的信息，避免出现不一样的信息来让攻击者可枚举有效账户。

5、防止暴力破解：设置登录失败阈值、使用强验证码、对同一 IP 来源设置登录阈值

6、防止密码修改功能问题：只能在已通过验证的会话中访问该功能、不能直接出现用户名、要求重新输入当前密码、新密码要输入两次一致、失败次数设置阈值、修改成功通过邮箱或者手机短信来提示用户。

7、防止忘记密码功能问题：不使用密码提示、改密链接具有时限（通常为一天），使用之后即失效，改密 token 随机不可预测、多因素验证（用户名、手机号等）

8、日志留存：所有用户相关操作均留下详细的日志，供事后溯源和大数据分析。

登录验证是出问题最多的地方，希望大家可以好好学习思考。这部分内容可以结合之前的作业，改善自己的代码，做到尽可能少的安全问题出现。

本文始发于微信公众号（信安之路）：web 登录验证机制的攻与防