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
  • 谨慎处理用户凭证
  • 不要依赖用户的安全
  • 防止用户名枚举
  • 实现强大的暴力破解保护
  • 三重检查你的验证逻辑
  • 不要忽视附加功能
  • 实现适当的多因素认证
  1. 服务器端主题
  2. 认证

如何保护你的认证机制

在本节中,我们将讨论如何防范在你的认证机制中出现我们讨论过的一些漏洞。

认证是一个复杂的主题,正如我们已经证明的那样,很遗憾,弱点和缺陷很容易产生。明确列出所有可能的措施来保护你自己的网站显然是不可能的。然而,有几个通用原则你应该始终遵循。

谨慎处理用户凭证

如果你无意中向攻击者泄漏了一组有效的登录凭证,那么即使是最强大的认证机制也是无效的。不言而喻,你绝不能在未加密的连接上发送任何登录数据。尽管你可能已经为登录请求实现了HTTPS,但确保通过将任何尝试的HTTP请求重定向到HTTPS来强制执行这一点。

你还应该对你的网站进行审计,确保没有用户名或电子邮件地址通过公开可访问的个人资料或在HTTP响应中反映出来。

不要依赖用户的安全

严格的认证措施通常需要用户付出一些额外的努力。人性使得一些用户几乎不可避免地找到方法来节省这些努力。因此,你需要在可能的情况下强制执行安全行为。

最明显的例子是实现有效的密码策略。一些传统的策略失败是因为人们把自己可预测的密码硬塞进策略中。相反,实现某种简单的密码检查器可能更加有效,它允许用户尝试密码并实时提供有关密码强度的反馈。一个流行的例子是由Dropbox开发的JavaScript库zxcvbn。通过仅允许密码检查器评级较高的密码,你可以比使用传统策略更有效地强制使用安全密码。

防止用户名枚举

如果你透露了用户在系统中的存在,攻击者就更容易破坏你的认证机制。甚至在某些情况下,由于网站的性质,知道某个特定用户拥有一个帐户本身就是敏感信息。

无论尝试的用户名是否有效,重要的是使用相同的通用错误信息,并确保它们确实相同。你应始终使为每个登录请求返回相同的HTTP状态码,最后,使不同情况的响应时间尽可能难以区分。

实现强大的暴力破解保护

鉴于构造暴力破解攻击的简单性,确保采取措施来防止或至少干扰任何暴力破解登录尝试是至关重要的。

其中一种更有效的方法是实现基于IP的用户速率限制。这应该包括防止攻击者操纵其表面IP地址的措施。理想情况下,你应该要求用户在达到一定限制后的每次登录尝试都要完成一个验证码测试。

请记住,这并不能完全消除暴力破解的威胁。然而,使该过程尽可能繁琐和手动化,会增加任何潜在攻击者放弃并转而寻找更脆弱目标的可能性。

三重检查你的验证逻辑

不要忽视附加功能

确保不要只关注核心登录页面,而忽视与认证相关的附加功能。这在攻击者可以自由注册自己的帐户并探索这些功能的情况下尤其重要。记住,密码重置或更改与主要登录机制一样是有效的攻击面,因此必须同样健壮。

实现适当的多因素认证

虽然多因素认证可能不适用于每个网站,但如果操作得当,它会比仅基于密码的登录更安全。请记住,验证同一因素的多个实例并不是真正的多因素认证。通过电子邮件发送验证码本质上只是一种更冗长的单因素认证形式。

基于短信的双因素认证在技术上验证了两个因素(你所知道的和你所拥有的)。然而,通过SIM卡交换等方式进行滥用的可能性,意味着这一系统可能不可靠。

理想情况下,双因素认证应使用直接生成验证码的专用设备或应用程序来实现。由于它们专为提供安全性而构建,因此通常更安全。

最后,与主要的认证逻辑一样,确保你的双因素认证检查中的逻辑是可靠的,以便不会被轻易绕过。

Previous其他认证机制中的漏洞Next目录遍历

Last updated 1 year ago

正如我们的所证明的那样,在代码中很容易出现简单的逻辑缺陷,这些缺陷在认证的情况下可能会完全破坏你的网站和用户。彻底审计任何验证或验证逻辑以消除缺陷,对于健壮的认证至关重要。可以绕过的检查,最终并没有比没有检查更好。

实验