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
  • 保持用户登录
  • 重置用户密码
  • 通过电子邮件发送密码
  • 使用URL重置密码
  • 更改用户密码
  1. 服务器端主题
  2. 认证

其他认证机制中的漏洞

Previous多因素认证中的漏洞Next如何保护你的认证机制

Last updated 1 year ago

本节将介绍与认证相关的一些附加功能,并演示这些功能是如何容易受到攻击的。我们还创建了几个交互式实验,供你将学到的知识付诸实践。

除了基本的登录功能外,大多数网站还提供补附加功能,以允许用户管理他们的账户。例如,用户通常可以更改密码或在忘记密码时重置密码。这些机制也可能引入被攻击者利用的漏洞。

网站通常会注意避免其登录页面中出现已知的漏洞。但很容易忽视一个事实,即你需要采取类似的步骤来确保相关功能同样健壮。这在攻击者能够创建自己的账户并因此可以轻松访问研究这些附加页面的情况下尤为重要。

保持用户登录

一个常见的功能是即使在关闭浏览器会话后也可以保持登录状态的选项。通常会有一个简单的复选框,标有类似于“记住我”或“保持登录状态”的标签。

通常,这个功能是通过生成某种“remember me”令牌,并将其存储在一个持久性的Cookie中来实现的。由于拥有此Cookie可以让你绕过整个登录过程,因此最佳实践是确保该Cookie很难猜测。但是,某些网站会基于可预测的静态值(例如用户名和时间戳)拼接生成此Cookie。甚至有些网站将密码作为Cookie的一部分。如果攻击者能够创建自己的账户,则此方法尤其危险,因为他们可以研究自己的Cookie并推测出它是如何生成的。一旦他们计算出了公式,他们就可以尝试暴力破解其他用户的Cookie来获取对其账户的访问权限。

一些网站假设,即使Cookie使用静态值,只要对其进行某种方式的加密,它就不会被猜测到。如果正确实施,这可能是正确的,但天真地使用简单的双向编码(如Base64)对Cookie进行“加密”不会起到任何保护作用。即使使用正确的单向哈希函数进行加密也不是绝对安全的。如果攻击者能够轻松识别哈希算法,并且没有使用盐,他们可能通过简单地对其字典列表进行哈希来暴力破解Cookie。如果对Cookie的猜测没有类似的限制,这种方法可以用于绕过登录尝试次数的限制。

LAB

即使攻击者无法创建自己的账户,他们仍然可以利用这个漏洞。使用常见的技术(如XSS),攻击者可以窃取另一个用户的“remember me” Cookie,并从中推测出Cookie的构造方式。如果网站是使用开源框架构建的,Cookie构造的关键细节甚至可能是公开文档化的。

在一些罕见的情况下,即使Cookie经过哈希处理,也有可能从Cookie中以明文形式获取用户的实际密码。在网上有已经哈希化的知名密码列表,因此如果用户的密码出现在其中之一,解密哈希有时就像简单地将哈希值粘贴到搜索引擎中那样容易。这说明盐对有效加密的重要性。

LAB

重置用户密码

实际中,有些用户会忘记他们的密码,因此通常会提供一种重置密码的方式。由于在这种情况下无法使用通常的基于密码的认证,网站必须依靠替代方法来确保真正的用户在重置自己的密码。因此,密码重置功能本质上是危险的,需要安全地实现。

这个功能通常有几种常见的实现方式,存在不同程度的漏洞。

通过电子邮件发送密码

应该毋需多言,如果一个网站在首次处理密码时已经安全地处理了密码,那么绝对不应该允许发送用户的当前密码。相反,一些网站会生成一个新密码,并通过电子邮件将其发送给用户。

一般来说,应该避免通过不安全的渠道发送持久性密码。在这种情况下,安全性依赖于生成的密码在很短的时间后过期,或者用户立即再次更改密码。否则,这种方法极易受到中间人攻击。

考虑到收件箱既是持久性的,也不是真正为机密信息的安全存储而设计的,电子邮件通常也不被视为安全的。许多用户还会通过不安全的渠道在多个设备之间自动同步他们的收件箱。

使用URL重置密码

一种更可靠的重置密码方法是向用户发送一个唯一的URL,该URL将他们带到密码重置页面。较不安全的实现方法使用一个易于猜测的参数来识别正在重置的账户的URL,例如:

http://vulnerable-website.com/reset-password?user=victim-user

在这个例子中,攻击者可以将user参数更改为他们已经确定的任何用户名。然后他们将直接进入一个页面,在该页面可以为这个任意用户设置一个新密码。

这个过程的更好实现方法是生成一个高熵的、难以猜测的令牌,并基于此创建重置URL。在最理想的情况下,该URL不应提供任何关于正在重置密码的用户的提示。

http://vulnerable-website.com/reset-password?token=a0ba0d1cb3b63d13822572fcff1a241895d893f659164d4cc550b421ebdd48a8

当用户访问此URL时,系统应该在后端检查这个令牌是否存在,并确定它应该重置哪个用户的密码。该令牌应该在短时间内过期,并在重置密码后立即销毁。

然而,有些网站在提交重置表单时未再次验证令牌。在这种情况下,攻击者只需从他们自己的账户访问重置表单,删除令牌,并利用该页面重置任意用户的密码。

LAB

如果重置电子邮件中的URL是动态生成的,那么它也可能易受到密码重置投毒的攻击。在这种情况下,攻击者可能窃取另一个用户的令牌,并使用它来更改他们的密码。

LAB

阅读更多

更改用户密码

通常,更改密码的过程涉及输入当前密码,然后两次输入新密码。这些页面基本上依赖于与普通登录页面相同的过程,来检查用户名和当前密码是否匹配。因此,这些页面可能易受到相同技术的攻击。

如果密码更改功能允许攻击者在不作为受害用户登录的情况下直接访问它,那么它可能特别危险。例如,如果用户名在一个隐藏字段中提供,攻击者可能能够在请求中编辑该值,以针对任意用户进行攻击。这可能被利用来枚举用户名并暴力破解密码。

LAB

暴力破解保持登录状态的Cookie
离线密码破解
密码重置逻辑存在缺陷
通过中间件进行密码重置投毒
密码重置投毒
通过密码更改进行密码暴力破解