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
  • 什么是OAST安全测试?
  • OAST测试有什么其他方法无法做到的?
  • 隐形漏洞 - DAST
  • 误报 - SAST
  • OAST的工作原理
  • 从外部进攻
  • 看到地平线
  • OAST的简易方法
  • 带外测试的优势
  • OAST测试有什么缺点吗?
  1. 前篇

带外应用程序安全测试(OAST)

Previous动态应用程序安全测试(DAST)NextSQL注入

Last updated 1 year ago

什么是OAST安全测试?

带外应用程序安全测试(OAST)利用外部服务器来发现本不可见的漏洞。它的引入是为了进一步改进DAST模型。PortSwigger通过Burp Collaborator成为了OAST的先驱。它将OAST功能添加到Burp Suite中,使这种方法更易于使用。

OAST测试有什么其他方法无法做到的?

一个Web应用程序可能包含任意数量的安全漏洞。其中许多漏洞广为人知,但漏洞经常会在新旧软件中被发现。更复杂的是,Web应用程序以及它们所使用的编码语言往往处于持续开发之中。没有什么东西可以一成不变。

这种动态性质的情况使事情变得棘手。意味着,无论进行多少测试,也无论采用何种技术组合,都不可能发现应用程序中的每一个潜在漏洞。即便能做到,这种情况也不会持续太久。安全专业人员与网络犯罪分子处于不断竞争之中,失败的后果可能是毁灭性的。

隐形漏洞 - DAST

DAST的主要卖点一直是它能产生高质量的结果。如果你浏览的是用这种方法生成的报告,那么几乎可以肯定你看到的就是真实的漏洞。这些信息可以直接交给开发团队进行修复。

但是当单独使用DAST时,动态测试很难检测到某些类型的安全漏洞。比如很容易错过不可见的或异步的漏洞。正如你将在下文看到的,使用OAST来增强动态测试可以很好地解决这个问题。

误报 - SAST

SAST是另一种常见的安全测试方法。它采用与动态测试完全相反的方法。DAST从外部对应用程序进行攻击,而SAST则着眼于代码本身。这种方法具有一系列不同的优点和缺点。

这里的主要问题是,由于SAST实际上并不执行任何代码,它只能看到可能发生的事情。意味着通常情况下,SAST将产生比DAST更大、更有噪音的结果集。这种噪音以误报的形式出现。其中会有真正的漏洞,但确定它们是哪些是需要花费时间和金钱的。

想要了解更多关于的信息?

OAST的工作原理

OAST改进了DAST安全测试的结果。在很多方面,它本身就是一种动态的方法,尽管它可以看到“转角”。因为动态应用程序安全测试实际上只是表示一种无法看到应用程序内部运作的测试。这也可以作为OAST的描述。

从外部进攻

传统的动态测试因其简单而优雅。从本质上讲,它向目标应用程序发送有效载荷并分析返回的响应,就像真正的攻击者一样。

当你发送一个DAST有效载荷,并且目标返回给你一个表明存在漏洞的响应时,你可以很肯定它是真实的。动态测试之所以取得成功,是因为它在这些情况下运作良好。

但如果一个目标应用程序没有对有效载荷返回响应,即使该目标实际上是存在漏洞的,又该怎么办?当一个应用程序异步工作时,这是一个特殊的问题。仅靠传统的DAST技术是无法解决的。

看到地平线

这就是OAST的用武之地。当PortSwigger推出Burp Collaborator时,OAST是该领域的一个革命性的补充。它使Burp Suite能够检测到大量新的漏洞,包括许多盲SQL注入、盲跨站脚本和盲操作系统命令注入漏洞。

Burp Collaborator通过在动态测试过程中引入一个新的通信渠道来执行OAST。

那么,这里究竟发生了什么?正如我们上面提到的,Burp Collaborator可以搜索大量在DAST测试中曾是不可见的漏洞。

如果一个漏洞是不可见的,那么当我们发送测试攻击时,它不会向我们返回任何有用的响应,即使该攻击是成功的。我们需要一种方法来绕过这一点。带外测试方法就是这种绕过方法。它通过发送攻击有效载荷,使目标与我们控制的外部系统发生交互,这个外部系统位于目标域之外。

OAST的简易方法

有了Burp Collaborator,即使你没有控制的外部系统,也很容易做到OAST。Burp Suite企业版和Burp Suite Professional都可以与Burp Collaborator服务器通信,以达到测试的目的。如果你愿意,还可以配置一个私人服务器来做同样的事情。

Burp Collaborator可以识别出导致每次交互的确切Burp Scanner有效负载。因此,如果某个目标返回了有用的信息,你就能准确地知道是什么触发了它。这个过程主要是为了实现自动化而设计的,它位于Burp Scanner内部。对于高级用户,Burp Suite Professional还包括手动OAST工具。

带外测试的优势

正如你可能看到的,自动化OAST是一种强大的技术,可以添加到安全测试人员的武器库中。上面的维恩图显示了OAST如何大大增加了DAST可以识别的安全问题的数量。其中一些也可能被SAST工具发现,但在许多情况下,这种可能性不大。

OAST具有与传统动态测试相同的优势。它很少产生误报,意味着它的报告是值得信赖的。

与DAST一样,OAST对应用程序所编写的语言并不关心。即使你想扫描多个Web应用程序,也无需多个软件。这与Burp Suite企业版的巨大可扩展性相得益彰。现在,你的整个网络组合只需一个软件就能够扫描。

OAST测试有什么缺点吗?

如果说OAST使测试变得完美,那就是在撒谎。没有任何一种方法是完美的。总会有DAST和OAST无法发现的漏洞,正如SAST会漏掉其他漏洞一样。

自动化Web安全扫描并不是解决安全漏洞的灵丹妙药。它应始终与定期的人工手动渗透测试结合使用。这种方法将有助于保持你的Web应用既安全又合规。

PortSwigger在引入Burp Collaborator时是OAST测试的先驱。这一功能集成在Burp Suite企业版和Burp Suite Professional中。有关Burp Suite的更多信息,以及它如何适合你特定的使用场景,请参阅下面的资源:

https://portswigger.net/customers

Web应用程序安全测试