前言

验证机制是应用程序防御恶意攻击的中心机制。它处在防御未授权访问的最前沿，如果用户能够突破那些防御，他们通常能够控制应用程序的全部功能，自由访问其中保存的数据。缺乏安全稳定的验证机制，其他核心安全机制（如会话管理和访问控制）都无法有效实施。

验证技术

下面是一些常见的验证机制

1. 用户名密码登录；
2. 多因素认证，如组合型密码和物理令牌；
3. 客户端SSL证书或智能卡；
4. HTTP基本和摘要验证；
5. 使用NTLM或Kerberos整合Windows的验证；
6. 生物特征，如指纹，人脸认证
7. 验证服务
8. 第三方登录，经常使用的是OAuth
9. SSO登录

验证机制设计缺陷

与Web应用程序常用的任何其他安全机制相比，验证功能中存在着更多设计方面的薄弱环节。即使在基于用户名和密码验证用户这种非常简单的标准化模型中，其中包含的设计缺陷也容易导致应用程序被非法访问。

验证机制通常包括的内容

登录

忘记密码

注册功能

修改密码

记住我

密码保密性不强（爆破）

许多Web应用程序没有或很少对用户密码的强度进行控制。应用程序常常使用下列形式的密码：

• 非常短或空白密码
• 以常用的字典词汇名称为密码
• 密码和有用户名完全相同
• 仍然使用默认密码
• 可以用来爆破其它用户密码。

问题：如果应用程序仅通过客户端控件实施密码强度规则，这本身并不是一个安全问题，因为普通用户仍然受到保护。虽然诡计多端的攻击者可为自己分配脆弱密码，但这通常并不会给应用程序造成威胁。

首先要了解用户密码的安全策略

目前常用的密码策略：

1）多因素认证

2）密码要求8位以上，包括大小写字母，数字，特殊符号

3）定期更换密码

4）定期匹配密码是否在网上已经泄露

因此密码字典一定要找符合系统密码安全策略的密码进行爆破，如果不知道其安全策略那就只能用常见的密码进行爆破。

暴力破解

登录功能的公开性往往诱使攻击者试图猜测用户名和密码，从而获得未授权访问应用程序的权力。如果应用程序允许攻击者使用不同的密码重复进行登录尝试，直到找到正确的密码，那么它就非常容易遭受攻击，因为即使是业余攻击者也可以在浏览器中手动输入一些常见的用户名和密码

PS：管理员密码实际上比密码策略允许的更为脆弱。它们可能在实施密码策略之前就已设置，或者通过其他应用程序或界面设置。

目前网站往往会使用一些手段来进行限制暴力破解，如下面的一些手段

1）验证码：通过使用验证码来判断是否是人在操作

2）失败错误锁定（如果使用客户端控件来实现，可能进行绕过，失败锁定以后要看正确密码与错误密码是否存在不同）

详细的失败信息

一个典型的登录表单要求用户输入两组信息（用户名和密码），而另外一些应用程序则需要更多信息（如出生日期、纪念地或PIN号码）。如果登录尝试失败，当然可以得出结论：至少有一组信息出错。但是，如果应用程序通知是哪一组信息无效，就可以利用它显著降低登录机制的防御效能。

详细的错误信息或者差异点

返回详细的失败信息，攻击者可以枚举出一批用户名，可以用于以后的密码猜测，攻击用户数据或会话，或者社会工程。

差异点

状态码，任何重定向，屏幕上的信息以及任何隐藏在HTML页面中的差异（前后端分离的项目这点可以忽略）

有效和无效用户名登录尝试的响应完全相同，如何枚举用户名？

可以通过登录请求的时间来枚举用户名。应用程序通常依据登录请求是否包含有效用户名，对其进行截然不同的后端处理。

证书（身份凭证）传输易受攻击

如果应用程序使用非加密的HTTP连接传输登录证书，处于网络适当位置的窃听者当然就能够拦截这些证书。根据用户的位置，窃听者可能位于：

❑ 用户的本地网络中；

❑ 用户的IT部门内；

❑ 用户的ISP内；

❑ 因特网骨干网上；

❑ 托管应用程序的ISP内；

❑ 管理应用程序的IT部门内。

即使使用HTTPS登录，如果传输证书的方式不安全，证书仍有可能被泄露给为授权方

1）如果已查询字符串参数，而不是在POST请求主体中传送证书，许多地方都可能记录这些证书，例如用户的浏览器历史记录汇总，web服务器日志内以及主机基础架构采用的任何反向代理中。

2）302跳转。虽然大多数Web应用程序确实使用POST请求主体提交HTML登录表单，但令人奇怪的是，应用程序常常通过重定向到一个不同的URL来处理登录请求，而以查询字符串参数的形式提交证书。我们并不清楚应用程序开发者为何采用这种方法，但以连接一个URL的302重定向执行请求，比使用另一个通过JavaScript提交的HTML表单提出POST请求要容易得多。

3）Web应用程序有时将用户证书保存在cookie中，通常是为了执行设计不佳的登录、密码修改、“记住我”等机制。攻击者通过攻击用户cookie即可获取这些证书。如果cookie相对安全可靠，可通过访问客户端的本地文件系统获得它们。即使证书被加密，攻击者仍然不需要用户证书就可以通过重新传送cookie实施登录。

密码修改功能

令人奇怪的是，许多Web应用程序并不允许用户修改其密码。但是，出于两个方面的原因，精心设计的验证机制需要这种功能。

1）定期强制修改密码可降低某一密码成为密码猜测攻击目标的可能性，同时降低攻击者不需要检测即可使用被攻破密码的可能性，由此降低密码被攻击的概率。

2）怀疑自己的密码已被攻破的用户需要立即修改密码，以降低未授权使用概率。

虽然密码修改功能是一个高效验证机制的必要组成部分，但从设计来看，它往往易于遭受攻击。在主要登录功能中特意避免的漏洞通常在密码修改功能中重复出现。许多Web应用程序的密码修改功能不需要验证即可访问，并为攻击者提供某些信息或允许攻击者执行某些操作。

❑ 提供详细的错误消息，说明被请求的用户名是否有效。

❑ 允许攻击者无限制猜测“现有密码”字段。

❑ 在验证现有密码后，仅检查“新密码”与“确认新密码”字段的值是否相同，允许攻击者不需入侵即可成功查明现有密码。

忘记密码功能

忘记密码也是经常遇到的一个功能，该机制常常会引入已在主要登录功能中避免的问题，如用户名枚举。

除这种缺陷外，忘记密码功能设计方面的缺点往往使它成为应用程序总体验证逻辑中最薄弱的环节。

忘记密码使用的方式

1）质询响应

2）短信验证码

3）邮箱密码重置链接

缺陷

质询响应的内容过于简单

无限制质询响应

密码提示

邮箱发送的链接可以被猜测

发送重置链接时可以指定邮箱

记住我功能

为方便用户，避免他们每次在一台特定的计算机上使用应用程序时需要重复输入用户名和密码，应用程序通常执行“记住我”功能。这些功能在设计上并不安全，致使用户易于遭受本地和其他计算机用户的攻击。

记住我功能原理，一般是在cookie中设置一个会话标识符，表明该用户已经登录过。或者在cookie中记录登录用户的账户信息。

用户伪装功能

一些应用程序允许特权用户伪装成其他用户，以在该用户的权限下访问数据和执行操作。例如，一些银行应用程序允许服务台操作员口头验证一名电话用户，然后将银行的应用程序会话转换到该用户的权限下，以为其提供帮助。

可能存在的缺陷

1）猜测出用户伪造的功能路径的人都可以伪装成其它用户

2）在cookie中通过userid来判断用户所拥有的权限

证书确认不完善

精心设计的验证机制强制要求密码满足各种要求，如最小密码长度和同时使用大小写字符。相应地，一些设计不佳的验证机制不仅没有强制执行这些最佳实践，而且对用户遵守这些要求的愿望置之不理。

可能得问题

1）截断密码，只确认前n个字符

2）一些应用程序并不对密码进行大小写检查

3）一些应用程序在检查密码之前删除不常用的字符

非唯一性用户名

一些支持自我注册的应用程序允许用户指定他们自己的用户名，而且并不强制要求用户使用唯一的用户名。虽然这种应用程序极其少见，但我们还是见到过若干这类应用程序。

缺陷

1）在注册阶段或随后修改密码的过程中，共享同一个用户名的两个用户可能碰巧选择相同的密码。如果出现这种情况，应用程序要么拒绝第二名用户选择的密码，要么允许两个账户使用相同的证书。如果属于前者，应用程序将会向一名用户泄露另一名用户的证书；如果属于后者，其中一名用户登录后会访问另一名用户的账户。

2）即使由于登录失败尝试次数方面的限制，在其他地方不可能实施这种攻击，攻击者仍然可以利用这种行为成功实施蛮力攻击。攻击者可以使用不同的密码，多次用一个特殊的用户名注册，同时监控说明使用该用户名和密码的账户已经存在的不同响应。攻击者不需以目标用户进行任何一次登录尝试，即可获取该用户的密码。

可预测用户名

一些应用程序根据某种可以预测的顺序（如cust5331、cust5332）自动生成账户用户名。如果应用程序以这种方式运转，弄清了用户名顺序的攻击者就可以很快获得全部有效用户名，以此作为后续攻击的基础。与依赖不断提交由词汇驱动请求的枚举方法不同，这种确定用户名的方法不需实施入侵，也很少给应用程序造成干扰。

可预测的初始密码

一些应用程序一次性或大批量创建用户，并自动指定初始密码，然后以某种方式将密码分配给所有用户。这种生成密码的方式可让攻击者能够预测其他应用程序用户的密码。基于内联网的企业应用程序常常存在这种漏洞。例如，应用程序为每位雇员创建一个账户，并向其发送一份打印好的密码通知。

证书分配不安全

许多应用程序并不在用户与应用程序正常交互的过程中分配新建账户的证书（如通过邮寄或电子邮件）。有时，采用这种分配方式主要出于安全考虑，例如，确保用户提供的邮寄或电子邮件地址属于其本人。

问题举例：

发送的账号激活URL可以猜测

发送账号的邮件没有设置时间限制并且没有要求用户修改初始密码，有可能导致其它人获取到账号信息

来源：https://www.freebuf.com/

原文始发于微信公众号（船山信安）：验证机制常见的问题