Web安全学院
Web安全学院
  • 首页
  • 译序
  • 学习路线
  • 前篇
    • Web应用程序安全测试
    • 动态应用程序安全测试(DAST)
    • 带外应用程序安全测试(OAST)
  • 服务器端主题
    • SQL注入
      • SQL注入
      • SQL注入UNION攻击
      • 在SQL注入攻击中检索数据库
      • SQL盲注
      • SQL注入速查表
    • 认证
      • 认证漏洞
      • 基于密码登录中的漏洞
      • 多因素认证中的漏洞
      • 其他认证机制中的漏洞
      • 如何保护你的认证机制
    • 目录遍历
      • 目录遍历
    • 命令注入
      • OS命令注入
    • 业务逻辑漏洞
      • 业务逻辑漏洞
      • 业务逻辑漏洞示例
    • 信息泄露
      • 信息泄露漏洞
      • 如何发现并利用信息泄露漏洞
    • 访问控制
      • 访问控制漏洞与权限提升
      • 不安全的直接对象引用(IDOR)
      • 访问控制安全模型
    • 文件上传漏洞
      • 文件上传漏洞
    • 条件竞争
      • 条件竞争
    • 服务器端请求伪造(SSRF)
      • 服务器端请求伪造(SSRF)
      • 盲SSRF漏洞
    • XXE注入
      • XML外部实体(XXE)注入
      • XML实体
      • 发现并利用盲XXE漏洞
  • 客户端主题
    • 跨站脚本(XSS)
      • 跨站脚本
      • 反射型XSS
      • 存储型XSS
      • 基于DOM的XSS
      • XSS上下文
        • 跨站脚本上下文
        • 客户端模版注入
      • 利用跨站脚本漏洞
      • 内容安全策略
      • 悬空标记注入
      • 如何防范XSS漏洞
      • 跨站脚本(XSS)速查表
    • 跨站请求伪造(CSRF)
      • 跨站请求伪造(CSRF)
      • XSS与CSRF
      • 绕过CSRF令牌验证
      • 绕过SameSite Cookie限制
      • 绕过基于Referer的CSRF防御
      • 如何防范CSRF漏洞
    • 跨域资源共享(CORS)
      • 跨域资源共享(CORS)
      • 同源策略(SOP)
      • CORS和Access-Control-Allow-Origin响应标头
    • 点击劫持
      • 点击劫持(UI伪装)
    • 基于DOM的漏洞
      • 基于DOM的漏洞
      • 控制Web消息源
      • 基于DOM的开放重定向
      • 基于DOM的Cookie操纵
      • 基于DOM的JavaScript注入
      • 基于DOM的document-domain操纵
      • 基于DOM的WebSocket URL投毒
      • 基于DOM的链接操纵
      • Web消息操纵
      • 基于DOM的Ajax请求标头操纵
      • 基于DOM的本地文件路径操纵
      • 基于DOM的客户端SQL注入
      • 基于DOM的HTML5 Storage操纵
      • 基于DOM的客户端XPath注入
      • 基于DOM的客户端JSON注入
      • DOM-data操纵
      • 基于DOM的拒绝服务
      • DOM破坏
    • WebSocket
      • 测试WebSocket安全漏洞
      • 什么是WebSocket?
      • 跨站WebSocket劫持
  • 进阶主题
    • 不安全的反序列化
      • 不安全的反序列化
      • 利用不安全的反序列化漏洞
    • 测试GraphQL API
      • 测试GraphQL API
      • 什么是GraphQL?
    • 服务器端模板注入
      • 服务器端模板注入
      • 利用服务器端模板注入漏洞
    • Web缓存投毒
      • Web缓存投毒
      • 缓存设计缺陷的利用
      • 缓存实现缺陷的利用
    • HTTP Host标头攻击
      • HTTP Host标头攻击
      • 如何识别和利用HTTP Host头的漏洞
      • 密码重置投毒
    • HTTP请求走私
      • HTTP请求走私
      • 查找HTTP请求走私漏洞
      • 利用HTTP请求走私漏洞
      • 高级请求走私
        • 高级请求走私
        • HTTP/2降级
        • 响应队列投毒
        • HTTP/2专属载体
        • HTTP请求隧道
      • 浏览器驱动的请求伪造
        • 浏览器驱动的请求伪造
        • CL.0请求走私
        • 客户端异步攻击
        • 基于暂停的异步攻击
    • OAuth认证
      • OAuth 2.0认证漏洞
      • OAuth授权类型
      • OpenID Connect
      • 如何防范OAuth认证漏洞
    • JWT攻击
      • JWT攻击
      • 在Burp Suite中使用JWT
      • 算法混淆攻击
    • 原型污染
      • 什么是原型污染?
      • JavaScript原型和继承
      • 客户端
        • 客户端原型污染漏洞
        • 通过浏览器API进行原型污染
      • 服务器端
        • 服务器端原型污染
      • 预防原型污染漏洞
    • 基本技能
      • 基本技能
      • 使用编码混淆攻击
      • 在手动测试中使用Burp Scanner
Powered by GitBook
On this page
  • 双因素认证令牌
  • 绕过双因素认证
  • 有缺陷的双因素验证逻辑
  • 暴力破解2FA验证码
  1. 服务器端主题
  2. 认证

多因素认证中的漏洞

Previous基于密码登录中的漏洞Next其他认证机制中的漏洞

Last updated 1 year ago

在本节中,我们将讨论多因素认证机制可能出现的一些漏洞。我们还提供了几个交互式实验,以展示你如何利用这些漏洞来攻击多因素认证。

许多网站仅依赖单因素认证,即使用密码对用户进行身份验证。然而,一些网站要求用户使用多个认证因素来证明其身份。

验证生物特征因素对于大多数网站来说是不切实际的。然而,基于你知道的东西和你拥有的东西的两因素认证(2FA)越来越常见。这通常要求用户同时输入一个传统密码和一个他们持有的带外物理设备上的临时验证码。

虽然攻击者有时可能获取到某一个基于知识的因素,比如密码,但能够同时从带外来源获取另一个因素的可能性要小得多。因此,双因素认证在实际上比单因素认证更安全。然而,与任何安全措施一样,它的安全性仅取决于实现方式。实现不良的双因素认证可以被攻破,甚至完全绕过,就像单因素认证一样。

还值得注意的是,多因素认证的全部优势仅通过验证多个不同的因素来实现。以两种不同方式验证相同因素并不是真正的双因素认证。基于电子邮件的2FA就是一个例子。尽管用户必须提供密码和验证码,但访问验证码只依赖于他们知道电子邮件账户的登录凭证。因此,这只是对知识认证因素进行了两次验证。

双因素认证令牌

验证码通常由用户从某种物理设备上读取。许多高安全性的网站现在为用户提供专用设备,例如RSA令牌或键盘设备,你可以用它们访问在线银行或工作笔记本电脑。除了专为安全而设计外,这些专用设备还具有直接生成验证码的优势。出于同样的原因,网站也常常使用专用的移动应用程序,如Google Authenticator。

另一方面,一些网站将验证码以短信的形式发送到用户的手机上。虽然这在技术上仍然验证了“你拥有的东西”因素,但它存在滥用的风险。首先,验证码是通过SMS传输而不是由设备自动生成的。这会导致验证码被截获的可能性。还存在SIM卡交换的风险,攻击者借此以欺诈的方式获得受害者的手机号码对应的SIM卡。然后,攻击者将接收到发送给受害者的所有短信,包括包含验证码的短信。

绕过双因素认证

有时,双因素认证的实现存在缺陷,以至于可以完全绕过它。

如果用户首先被要求输入密码,然后在另一页上被要求输入验证码,那么用户在输入验证码之前实际上已经处于“已登录”的状态。在这种情况下,值得测试一下在完成第一步认证后,是否可以直接跳转到“仅限已登录”的页面。偶尔,你会发现网站在加载页面之前实际上并没有检查你是否完成了第二步认证。

LAB

有缺陷的双因素验证逻辑

有时,双因素认证中的逻辑错误意味着用户完成了初始登录步骤后,网站并未充分验证同一用户是否正在完成第二步骤。

例如,用户在第一步中使用正常凭证登录,如下所示:

POST /login-steps/first HTTP/1.1
Host: vulnerable-website.com
...
username=carlos&password=qwerty

然后,在进入登录过程的第二步之前,他们会被分配一个与其账户相关的Cookie:

HTTP/1.1 200 OK
Set-Cookie: account=carlos

GET /login-steps/second HTTP/1.1
Cookie: account=carlos

提交验证码时,请求使用此Cookie来确定用户要访问的账户:

POST /login-steps/second HTTP/1.1
Host: vulnerable-website.com
Cookie: account=carlos
...
verification-code=123456

在这种情况下,攻击者可以使用自己的凭证登录,然后在提交验证码时更改account Cookie的值为任意用户名。

POST /login-steps/second HTTP/1.1
Host: vulnerable-website.com
Cookie: account=victim-user
...
verification-code=123456

如果攻击者能够暴力破解验证码,那么这将非常危险,因为这样可以完全基于用户名登录到任意用户的账户,而无需知道用户的密码。

LAB

暴力破解2FA验证码

与密码一样,网站需要采取措施来防止对2FA验证码的暴力破解。这尤其重要,因为验证码通常是一个简单的4或6位数字。如果没有足够的暴力破解保护措施,破解此类验证码将变得非常容易。

LAB

一些网站尝试通过在用户输入一定数量的错误验证码后自动登出用户来阻止暴力破解。但这在实践中是无效的,因为高级攻击者甚至可以通过为Burp Intruder来自动化这个多步骤过程。Turbo Intruder扩展程序也可用于此目的。

2FA简单绕过
2FA逻辑存在缺陷
创建宏
使用暴力破解绕过2FA