Calendar's Blog

认证漏洞

13 min read

认证（Authentication）是验证用户或客户端身份的过程。网站可能暴露给任何接入互联网的人，因此，完善的认证机制是实现有效网络安全不可或缺的一部分。

认证是验证用户是否符合其声称身份的过程，而授权则是验证用户是否被允许执行某项操作的过程。

Burp靶场-认证漏洞

介绍

认证的三种主要类型

  1. 你所知道的信息：例如密码或安全问题的答案，这类也被称为 “知识因子（knowledge factors）”。
  2. 你所拥有的物品：指物理实体，如手机或安全令牌，这类也被称为 “持有因子（possession factors）”。
  3. 你的固有特征或行为：例如生物特征（如指纹、人脸）或行为模式（如打字节奏），这类也被称为 “固有因子（inherence factors）”。

认证机制会依托各类技术，对上述一种或多种因子进行验证。

认证漏洞的产生原因

认证机制中的绝大多数漏洞，主要通过以下两种方式产生：

  1. 认证机制本身存在缺陷：这类机制因未能充分抵御暴力破解攻击（brute-force attacks），而具备先天的脆弱性。
  2. 实现环节的逻辑缺陷或糟糕的编码：攻击者可借此完全绕过认证机制，这种情况有时也被称为 “认证失效（broken authentication）”。

由于认证对安全至关重要，存在缺陷的认证逻辑极有可能使网站面临安全风险。

漏洞

基于密码的登录机制漏洞

暴力破解

这类攻击通常会借助用户名和密码字典库（wordlists）实现自动化操作；一旦实现自动化（尤其是使用专用工具时），攻击者有可能以极高的速度发起海量登录尝试。

暴力破解并非总是对用户名和密码进行完全随机的猜测。攻击者还会结合基础逻辑或公开可获取的信息，对暴力破解攻击进行优化，从而做出更具针对性的猜测 —— 这会大幅提升此类攻击的效率。

分为爆破用户名、密码

  • 用户名：枚举通常发生在两个场景：一是登录页面（例如输入有效用户名但密码错误时），二是注册表单（例如输入已被占用的用户名时）。
  • 注意：状态码，错误提示信息，响应时间
  • 响应差异检索：用 Burp - Setting - GrepExtract 进行筛选（注意要选全，可能有细微差别）

http 式密码：直接用 Base64 编码以后当作了认证信息，没用

拦截疏漏

IP 拦截：

  • 在部分实现方案中，若该 IP 的持有者成功登录一次，失败尝试次数的计数器就会重置。这意味着攻击者只需每隔几次尝试，就登录一次自己的账号，便能避免触发封禁限制。
  • 在这种场景下，攻击者只需在密码字典库中定期插入自己的登录凭证，就能让这类防护机制几乎失效。

账户锁定：

  • 网站防范暴力破解的一种常见手段是：当满足特定可疑条件（通常是达到设定的登录失败次数阈值）时，锁定对应账号。与普通登录错误提示类似，服务器返回的 “账号已锁定” 响应，同样会帮助攻击者实现用户名枚举。账号锁定机制虽能对 “针对特定账号的定向暴力破解” 起到一定防护作用，但无法有效阻止攻击者 “尝试攻陷任意可用账号” 的暴力破解行为。
  • 构建用户名表，用少数几个高可能性的密码爆破，不触发账号封禁
  • 或者根据返回的信息判断，然后等封禁期过了再登陆

多因素认证

多因素认证的完整安全优势，仅在核验多种不同类型的认证因素时才能体现。若只是通过两种不同方式核验同一类因素，并非真正的双因素认证。

手机验证：尽管从技术层面来说，这仍属于对 “你所拥有的物品（手机）” 这一认证因素的核验，但这种方式存在被滥用的风险：

  1. 传输拦截风险：验证码并非由设备本地生成，而是通过短信传输 —— 这就存在验证码被拦截的可能性；
  2. SIM 卡劫持风险：攻击者可通过欺诈手段获取绑定受害者手机号的 SIM 卡（即 SIM 卡替换 / SIM swapping），进而接收发送给受害者的所有短信，其中就包括包含验证码的短信。

验证疏漏

网站在第一次登陆后，已经设置了 Cookie 等，并未进行第二次的认证

用户管理接口

在攻击者能够自行注册账号、进而轻易访问并研究这些附加页面的场景下，可能可以利用账号管理接口对其他账号进行操作，如修改密码、忘记密码、重置密码等等。

重置密码：

  • 邮箱发给用户临时密码：很不安全，可能泄露，且邮箱是持久化存储，不能保证用户马上修改密码
  • 唯一 URL：更安全的实现方式是向用户发送唯一 URL，引导其进入密码重置页面。但该方式的安全性高度依赖 URL 的设计，不同实现方案的风险差异极大。用高熵的随机 URL 较为安全

修改密码：

  • 若没有要求输入当前密码，可以尝试枚举用户名（需要找到指向）
  • 若要求，可以爆破密码

验证疏漏

部分网站仅在 “访问重置页面时” 校验令牌，却在 “提交重置表单时” 跳过令牌验证 —— 攻击者可利用这一缺陷越权重置任意用户密码。只需要在自己的账号上进行重置密码，然后更改 user 指向被攻击者即可。

令牌窃取

若重置邮件中的 URL 为动态生成，该机制还可能存在密码重置投毒（password reset poisoning） 漏洞 —— 攻击者可借此窃取其他用户的重置令牌，进而修改目标用户的密码。

例如攻击者向服务器发起 “触发目标用户密码重置” 的请求（如利用用户名枚举获取的有效账号），并篡改请求头中的Host为自己的服务器域名，服务器基于恶意Host生成重置 URL（如http://attacker.com/reset?token=xxx），并发送到目标用户的邮箱，该用户的 token 就会被窃取。

漏洞触发的关键条件：

  • 服务器未校验请求头的合法性（如允许X-Forwarded-Host等自定义头覆盖真实域名）；
  • 重置 URL 的生成逻辑依赖客户端可控的请求头参数，而非服务器端固定配置的域名；
  • 重置令牌未与目标用户的 IP / 会话绑定，攻击者窃取后可直接复用。

保持登录状态

通常采用的策略是通过产生长效 Cookie 来进行。但是 Cookie 有可能被误用，如：

  • 基于可预测的静态值拼接生成（如用户名 + 时间戳）；
  • 甚至将密码直接作为 Cookie 的组成部分，或只是进行简单编码
  • 单向哈希函数可能可以被字典比对

即便攻击者无法登录进而查看 Cookie，也可能通过 Xss攻击、源码审计等手段来判断 Cookie 构成

防御手段

不能通过未加密的连接传输任何登录数据 —— 即便你已为登录请求部署了 HTTPS，也需确保通过 “将所有 HTTP 请求重定向至 HTTPS” 的方式强制启用加密，避免出现传输漏洞。

此外，还需对网站进行全面审计，确保用户名、邮箱地址等敏感信息不会通过以下途径泄露：

  • 可公开访问的用户资料页（如个人主页、公开的用户列表）；
  • HTTP 响应内容的回显（如接口返回值、错误提示中直接包含用户名）。

不要相信用户自己设置的密码强度

为了防止爆破，无论尝试登录的用户名是否有效，都必须做到以下三点，彻底杜绝用户名枚举漏洞：

  1. 使用完全相同的通用错误提示（例如统一返回 “账号或密码错误”，而非区分 “用户名不存在” 和 “密码错误”），且需确保提示文本、格式完全一致；
  2. 所有登录请求返回相同的 HTTP 状态码（例如无论用户名是否存在，均返回 200 OK，避免用 404/401 等状态码区分）；
  3. 让不同场景（用户名存在 / 不存在、密码正确 / 错误）的响应时间尽可能一致，避免攻击者通过响应速度差异推断用户名有效性。
  4. 较为有效的防护方案是实施严格的、基于 IP 的用户访问频率限制，同时需配套措施防止攻击者篡改显示 IP（如伪造 IP 地址绕过限制）。理想情况下，当登录尝试次数达到阈值后，应要求用户每次登录都完成 CAPTCHA（验证码）验证（如图形验证码、滑动验证等）。
    • 需注意的是，这类措施无法完全消除暴力破解威胁，但能让攻击过程变得极其繁琐且需手动操作 —— 这会大幅提高攻击者的时间成本，增加他们放弃攻击、转向其他防护更薄弱目标的概率。

理想情况下，双因素认证应采用专用设备或认证 APP 直接生成验证码的方式实现 —— 这类工具专为安全场景设计，通常具备更高的安全性（如 Google Authenticator、硬件令牌等）。

Graph View

Backlinks