目录
1.1、证书传输易受攻击
简述：
如果应用程序使用非加密的HTTP连接传输登录证书， 处于网络适当位置的窃听者当然就能够拦截这些证书
根据用户的位置， 窃听者可能位于
用户的本地网络中
用户的IT部门内
用户的ISP内
因特网骨干网上
托管应用程序的ISP内
管理应用程序的IT部门内
————
即使是通过HTTPS登录， 如果应用程序处理证书的方式并不安全， 证书仍有可能被泄露给未授权方
1、如果以查询字符串参数、而不是在POST请求主体中传送证书， 许多地方都可能记示这些证书， 例如用户的浏览器历史记录中、Web服务器日志内以及主机基础架构采用的任何反向代理中。如果攻击者成功攻破这些资源， 就能够获取保存在这些地方的用户证书， 从而提升其访问权限。
2、虽然大多数Web应用程序确实使用POST请求主体提交HTML登录表单，应用程序信信通过重定向到一个不同的URL来处理登录请求， 而以查询字符串参数的形式提交证书。 但以连接一个URL
的302重定向执行请求，比使用另一个通过JavaScript提交的HTML表单提出POST请求要容易得多。3、Web应用程序有时将用户证书保存在cookie中， 通常是为了执行设计不佳的登录、密码修改、＂记住我” 等机制。攻击者通过攻击用户cookie即可获取这些证书。如果cookie相对安全可靠， 可通过访问客户端的本地文件系统获得它们。即使证书被加密， 攻击者仍然不需要用户证书就可以通过重新传送cookie实施登录。
————
许多应用程序对应用程序中未经验证的区域使用HTTP，而在登录时转而使用HTTPS
应在向浏览器加载登录页面时转换到HTTPS,使得用户能够在输入证书前核实页面是否具实可信。但是，一些应用程序通常使用HTTP加载登录页面， 而在提交证书时才转换到HTTPS。这样是不安全的，用户不能核实登录页面的且实性， 因此无法保证安全提交证书。那么，处在适当位置的攻击者就可以拦截并修改登录页面， 更改登录表单的目标URL以使用HTTP。等到精明的用户意识到证书已使用HTTP提交时，攻击者已成功获取这些证书
过程：
1、进行一次成功登录， 监控客户端与服务器之间的所有来回流量。
2、确定在来回方向传输证书的每一种情况。可以在拦截代理服务器中设置拦截规则， 标记包含特殊字符串的消息
3、如果发现通过URL查询字符串或者以cookie的方式提交证书， 或者由服务器向客户端传输证书的任何情况， 了解传输的一切细节并设法弄清应用程序开发者这样做的目的。设法查明攻击者干扰应用程序逻辑以获取其他用户证书的各种手段。
4、如果通过非加密渠道传输任何敏感信息， 这样做当然容易遭受攻击。
5、如果没有发现证书传输不安全的情况， 留意任何明显被编码或模糊处理的数据。如果这些数据中包括敏感数据， 其模糊算法可能遭受逆向工程。
6、如果使用HTTPS提交证书， 但使用HTTP加载登录表单， 那么应用程序就容易遭受中间人攻击， 攻击者也可能使用这种攻击手段获取证书
1.2、密码修改功能
简述：
许多Web应用程序并不允许用户修改其密码，出于两个方面的原因，验证机制需要这种功能
1、定期强制修改密码可降低某一密码成为密码猜测攻击目标的可能性， 同时降低攻击者不需要检测即可使用被攻破密码的可能性， 由此降低密码被攻击的概率
2、怀疑自己的密码已被攻破的用户需要立即修改密码， 以降低未授权使用概率。
————
虽然密码修改功能是一个高效验证机制的必要组成部分， 但它往往易于遭受攻击。在主要登录功能中特意避免的漏洞通常在密码修改功能中重复出现。许多Web应用程序的密码修改功能不需要验证即可访问， 并为攻击者提供某些信息或允许攻击者执行某些操作。
1、提供详细的错误消息， 说明被请求的用户名是否有效
2、允许攻击者无限制猜测“现有密码” 字段
3、在验证现有密码后， 仅检查“新密码” 与“确认新密码” 字段的值是否相同， 允许攻击者不需入侵即可成功查明现有密码
————
典型的密码修改功能通常包含一个相对较大的逻辑判定树。应用程序需要确认用户、验证提供的现有密码、集成任何账户锁定防御、对提交的新密码进行相互比较并根据密码强度规则进行比较， 以及以适当的方式向用户返回任何错误条件。为此， 密码修改功能通常包含难以察觉的可用于破坏整个机制的逻辑缺陷
过程：
1、确定应用程序中的所有密码修改功能。即使公布的内容中没有明确的密码修改功能链接， 应用程序仍然可能实施这种功能。
2、使用无效的用户名、无效的现有密码及不匹配的“新密码” 和“确认新密码＂ 值向密码修改功能提交各种请求。
3、设法确定任何可用于用户名枚举或蛮力攻击的行为
注：
如果密码修改表单只可由验证用户访问， 且其中并无用户名字段， 表单中仍有可能包含一个任意用户名。表单可能将用户名保存在一个可被轻易修改的隐藏字段中。如果在字段中没有发现用户名， 设法使用和主登录表单中相同的参数提交另一个包含用户名的参数。这种技巧有时可成功覆盖当前用户的用户名，使攻击者能够向其他用户的证书发动蛮力攻击， 即使在主登录页面不可佳实施这种攻击。
1.3、忘记密码功能
简述：
与密码修改功能一样，重新获得忘记密码的机制常常会引入已在主要登录功能中避免的问题， 如用户名枚举
忘记密码功能设计方面的缺陷往往使它成为应用程序总体验证逻辑中最薄弱的环节
————
常见的设计缺点
1、忘记密码功能常常向用户提出一个次要质询以代替主要登录功能。与试图猜测用户密码相比， 响应这种质询对攻击者来说更容易一些。母亲的姓、生日、最喜欢的颜色等问题的答案要比可能的密码的数量少得多。这些问题的答案常常隐藏在公开的信息中，对于攻击者来说无须花费多大精力即可找到答案。
应用程序允许用户在注册阶段设定他们自己的密码恢复质询与响应， 而用户很有可能会设置极其不安全的质询， 这也许是因为用户错误地认为应用程序仅向他们自已提出这些质询，在这种情况下，希望获得访问权的攻击者可使用自动攻击手段遍历一组已枚举的或常见的用户名， 记录所有密码恢复质询， 并选择那些看似最容易猜测出的质询发动攻击。
2、与密码修改功能一样，即使应用程序开发者在主登录页面阻止攻击者向密码恢复质询的响应发动蛮力攻击， 他们也往往会在忘记密码功能中忽略这种攻击的可能性。如果应用程序允许无限制地回答密码恢复质询， 那么攻击者就很可能会攻破这个密码。
3、一些应用程序使用一个简单的密码＂提示＂ （可由用户在注册阶段配置）代替恢复质询。由于用户错误地认为只有自己才会看到这些提示， 他们往往设置非常明显的暗示， 甚至是和密码完全相同的暗示。拥有一组常见或已枚举出的用户名的攻击者可轻易获取大量密码暗示， 然后开始实施猜测。
4、在用户正确响应一个质询后， 应用程序即允许用户项新控制他们的账户， 这种机制非常容易遭受攻击。执行这种机制的一个相对安全的方法是向用户在注册阶段提供的电子邮件地址发送一个唯一的、无法猜测的、存在时间限制的恢复URL。用户在几分钟内访问这个URL即可设置一个新密码。但常常会遇到其他一些在设计上存在缺陷的账户恢复机制
一些应用程序在用户成功响应一个质询后即向其透漏现有与遗忘的密码， 使攻击者能够无限制地使用该账户， 而不会被账户所有者检测出来。即使账户所有者随后修改被攻破的密码， 攻击者只需项新回答相同的质询即可获得新密码
一些应用程序在用户成功完成一个质询后， 立即让其进人一个不需验证的会话。这同样使攻击者可无限制地使用该账户， 而不会被账户所有者检测出来， 甚至不需要知道用户的密码。
一些应用程序采用发送一个唯一恢复URL的机制， 但却将这个URL发送至用户在完成质询时指定的电子邮件地址中。除能够记录攻击者所使用的电子邮件地址外， 这种方法根本无法提高恢复过程的安全性
注：
即使应用权序并未提供一个在屏幕上显示的字段， 要求用户输入接收恢复URL的电子邮件地址， 它仍有可能通过一个隐藏表单字段或cookie传送这个地址。攻击者因此获得双重机会一方面， 可以发现所攻破的用户的电子邮件地址， 另一方面， 可对这个地址进行修改， 用自选的地址接收恢复URL
一些应用程序允许用户在成功完成一个质询后直接重新设置密码， 并且不向用户发送任何电子邮件通知。这意味着扛到所有者碰巧再次登录时才会注意到账户被攻击者攻破；而且， 如果所有者认为自己一定是忘记了密码， 于是用上述方法重新设置密码，他可能仍然无法发觉账户已被攻破。那么， 只是希望偶尔访问应用程序的攻击者就可以在一段时间攻破一个用户账户， 在另一段时间攻破另一个不同用户的账户， 从而继续无限制地使用该应用程序
过程：
1、确定应用程序中的所有忘记密码功能。即使公布的内容中没有明确的忘记密码功能链接， 应用程序仍然可能实施这种功能
2、使用受控制的账户执行一次完整的密码恢复过程， 了解忘记密码功能的工作机制。
3、如果恢复机制使用质询， 确定用户是否能够设定或选择他们自己的质询与响应。如果用户可设定或选择自己的质询与响应， 使用一组已枚举的或常见的用户名获取一些质询， 并对其进行分析， 找出任何非常容易猜测出响应的质询
4、如果恢复机制使用密码“提示”，采取和上个步骤相同的操作获得一组密码提示， 并对任何可轻易猜测出答案的提示发动攻击
5、设法确定忘记密码机制中任何可用于用户名枚举或蛮力攻击的行为
6、如果应用程序在忘记密码请求的响应中生成一封包含恢复URL的电子邮件， 获取大量这类URL ，并试图确定任何可帮助预测向其他用户发布URL的模式。使用和分析会话令牌以实现预测相同的技巧