版权声明：本文为博主原创文章，转载请注明出处！ https://blog.csdn.net/qq_37964989/article/details/88890380
第六章 攻击验证机制
一、验证技术：
1. 基于HTML表单的验证
2. 多元机制
3. 客户SSL证书或智能卡
4. HTTP基本和摘要验证
5. 使用NTML或Kerberors、整合Windows的验证
6. 验证服务
二、 验证机制设计缺陷：
1. 密码保密性不强：
- a) 非常短或空白的密码
- b) 以常用的字典词汇或名称为密码
- c) 密码和用户名完全相同
- d) 仍然使用默认密码
2. 蛮力攻击登录
3. 详细的失败消息
4. 证书传输易受攻击
5. 密码修改功能
6. 忘记密码功能
7. 记忆功能（“记住我”）
8. 用户伪装功能
9. 证书确认不完善
10. 非唯一性用户名
缺陷：
- a) 在注册阶段或随后修改密码的过程中，共享同一个用户名的两个用户可能碰巧选择相同的密码
- b) 及时由于失败登录尝试次数方面的限制，在其他地方不可能实施这种攻击，攻击者仍然可以利用这种行为成功实施蛮力攻击）
11. 可预测的用户名
12. 可预测的初试密码
13. 证书分配不安全
三、 验证机制执行缺陷：
1. 故障开放登录机制
2. 多阶段登录机制中的缺陷：
- a) 使得仅拥有部分正常登录所需各种证书的攻击者能够成功登录
- b) 攻击者若能在不同登录阶段的转换过程中干扰这些标记，就可以更改应用程序的行为，让他们只需部分证书即可通过验证，或者提升其权限
- c) 应用程序可能认为每个阶段的用户身份不会发生变化
3. 不安全的证书储存
四、 保障验证机制的安全：
1. 使用可靠的证书：
- a) 强制执行适当的最小密码强度要求
- b) 使用唯一的用户名
- c) 系统生成的任何用户名和密码应具有足够的随机性
- d) 允许用户设置足够强大的密码
2. 安全处理证书：
- a) 以不会造成非授权泄露的方式创建、保存和传送所有证书
- b) 使用公认的加密技术保护客户与服务器之间的所有通信
- c) 只使用POST请求向服务器传输证书
- d) 客户端“记住我”功能应仅记忆非保密类数据
- e) 使用一种密码修改工具，定期修改密码
- f) 考虑在适当的地方使用下拉菜单而非文本字段截取用户的一些登录信息
3. 正确确认证书：
- a) 确认完整的密码
- b) 在登录处理过程中主动防御无法预料的事件
- c) 对验证逻辑的伪代码和实际的应用程序源代码进行仔细的代码审查
- d) 严格控制用户伪装功能，防止攻击者滥用它获得未授权访问
- e) 对多阶段登录进行严格控制
4. 防止信息泄露：
- a) 应用程序使用的各种验证机制不应通过公开的消息，或者通过从应用程序的其他行为进行推断，来揭示关于验证参数的任何信息
- b) 由单独一个代码组件使用一条常规消息负责响应所有的失败登录尝试
5. 防止蛮力攻击：
- a) 必须对验证功能执行的各种质询采用保护措施，防止攻击者试图使用自动工具响应这些质询
- b) 使用无法预测的用户名，同时阻止用户名枚举
6. 防止滥用密码修改功能:
- a) 应用程序应始终执行密码修改功能，允许定期使用的密码到期终止并允许用户修改密码
- b) 只能从已通过验证的会话中访问该功能
- c) 不应以任何方式直接提供用户名，或通过隐藏表单字段或cookie提供用户名
- d) 应用程序应对密码修改功能加以保护，防止攻击者通过其他安全缺陷获得未授权访问
- e) 为防止错误，新密码应输入两次
- f) 使用一条常规错误消息告知用户现有证书中出现的任何错误
- g) 使用“带外”方式通知用户其密码已被修改
7. 防止滥用账户恢复功能:
- a) 精心设计的密码恢复机制需要防止账户被未授权方攻破，避免给合法用户造成任何使用中断
- b) 绝对不要使用密码“暗示”之类的特性
- c) 通过电子邮件给用户发送一个唯一的、具有时间限制的、无法猜测的一次性恢复URL是帮助用户重新控制账户的最佳自动化解决方案
- d) 为进一步防止未授权访问，可能会向用户提出一个次要质询，用户必须在使用密码重设功能前完成质询
8. 日志、监控与通知:
- a) 应用程序应在日志中记录所有与验证有关的事件
- b) 应用程序的实时报警与入侵防御功能应对验证过程中的一场事件进行处理
- c) 应以“带外”方式向用户通报任何重大的安全事件
- d) 应以“带内”方式向用户通报经常发生的安全事件
第七章 攻击会话管理
执行会话的最简单、也是最常见的方法就是向每名用户发布一个唯一的会话令牌或标识符。
1. 会话管理机制中存在的两类漏洞：
- a) 会话令牌生成过程中的薄弱环节
- b) 在整个生命周期过程中处理会话令牌的薄弱环节
2. 会话替代方案
- a) HTTP验证
- b) 无会话状态机制
3. 结构化令牌的组成成分：
- a) 账户用户名
- b) 应用程序用来区分账户的数字标识符
- c) 用户的电子邮件地址
- d) 用户在应用程序中所属的组或扮演的角色
- e) 日期/时间戳
- f) 一个递增或可预测的数字
- g) 客户的IP地址
4. 会话令牌处理中的薄弱环节：
1) 在网络上泄露令牌：
- a) 一些应用程序在登录阶段选择使用HTTPS保护用户证书的安全，但在用户会话的其他阶段转而使用HYYP
- b) 一些应用程序在站点中预先通过验证的区域使用HTTP，但从登录页面开始转换到HTTPS
- c) 即使应用程序在用户成功登录后发布一个新令牌，并从登录页面开始使用HTTPS，但如果用户通过单击验证区域中的一个连接、使用“后退”按钮或者直接输入URL，重新访问一个预先验证的页面
- d) 一些应用程序对应用程序内的全部静态内容使用HTTP
- e) 即使应用程序在每一个页面都使用HTTPS，有些情况下，用户的令牌仍然通过HTTP传送
2)在日志中泄露令牌：
- a) 用户浏览器的日志
- b) Web服务器的日志
- c) 企业或ISP代理服务器的日志
- d) 任何在应用程序主机环境中采用的反向代理的日志
- e) 应用程序用户通过单击站外链接访问的任何服务器Referer日志
3) 令牌－会话映射易受攻击
4) 会话终止易受攻击
5)客户暴露在令牌劫持风险之中：
- a) 攻击者可通过跨站点脚本攻击查询用户的cookie，获得他们的会话令牌，然后将其传送给自己控制的任意服务器
- b) 攻击者可以使用其他针对用户的攻击，以不同的方式劫持用户的会话
6) 宽泛的cookie范围
5. 保障会话管理的安全：
（1） 生成强大的令牌
（2） 在整个生命周期保障令牌的安全：
- a) 令牌只能通过HTTPS传送
- b) 绝不能在URL中传送会话令牌
- c) 总是执行推出功能
- d) 会话处于非活动状态一段时间后，执行会话终止
- e) 防止并行登录
- f) 尽可能限定应用程序会话cookie的域和路径范围
- g) 严格审查应用程序的代码库，以确定并删除任何跨站点脚本漏洞
- h) 不接受用户提交、但服务器并不认可的任何令牌
- i) 在执行转帐之类的重要操作前，要求进行两步确认或重新验证
- j) 不完全依赖HTTP cookie传送会话令牌
- k) 成功验证后总是建立一个新的会话，以避免会话固定攻击的影响
（3） 日志、监控与警报