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
  • 什么是Web应用安全测试?
  • Web应用无处不在
  • 每个人都面临着数据泄露的风险
  • 进入:Web应用安全测试
  • Web应用安全测试的类型
  • 动态应用程序安全测试(DAST)
  • 静态应用程序安全测试(SAST)
  • 交互式应用程序安全测试(IAST)
  • 带外应用程序安全测试(OAST)
  • Web应用程序安全测试的不同用途
  • 测试各类Web技术
  • 保持合规
  • 大规模自动化
  • 渗透测试
  • 安全开发
  1. 前篇

Web应用程序安全测试

Previous学习路线Next动态应用程序安全测试(DAST)

Last updated 1 year ago

什么是Web应用安全测试?

Web应用安全测试的目的是确定一个Web应用程序是否容易受到攻击。它涵盖了多种不同方法的自动化和手动技术。

Web应用无处不在

多年前,当桌面应用程序仍然是时代的主流时,Web应用程序比现在要少得多。从技术上讲,任何通过Web浏览器访问的客户端-服务器程序都是一个Web应用程序,如今它包括了互联网的绝大多数。Web应用程序在许多方面更加灵活。

从简单的联系表格和电子商务结账,一直到社交媒体平台和网上银行系统。如果你通过浏览器访问它,那么它就是一个Web应用程序。一个Web应用程序可以构成一个网站的一小部分,或者它本身就是一个网站。

每个人都面临着数据泄露的风险

所有Web应用程序都有一个共同点,那就是它们处理数据(一种有价值的商品)。和任何商品一样,数据也有存储风险。存在着想要窃取数据的组织,无论是出于监视的目的,还是为了实施欺诈,或仅仅是为了出售。

这意味着Web应用程序安全至关重要。但在现实世界中,确保一个Web应用程序的安全并不是一件容易的事。首先,构建Web应用程序的开发人员往往不是安全专家。并且新的安全漏洞不断被发现,因此很难跟上。

进入:Web应用安全测试

解决方案是测试你的Web应用程序,以了解其弱点所在。用银行保险库来比喻,你首先要确保它的设计是正确的。然后你可能会聘请一个专家团队来尝试闯入它。随着时间的推移和新的弱点被发现,你会相应地改进保险库。

你将在下文中看到,这与Web应用程序安全测试并没有太大的不同。现在“保险库”的墙是代码,涉及的许多(但不是全部)参与者都是自动化的,但理论是相同的。构建强大的系统并保持其强大,尽可能测试每一种攻击方法。

Web应用安全测试的类型

Web应用安全测试中有各种概念。其中最著名的包括:

动态应用程序安全测试(DAST)

DAST在一个正在运行的应用程序上由外向内地工作。就好比让一个专家团队试图为你闯入你的银行保险库。这就是所谓的黑盒安全测试技术,因为Web应用程序背后运行的代码对测试来说是不可见的。DAST模拟了真实的攻击,Burp Suite在很大程度上是由DAST方法演变而来的。

由于DAST是一种切实有效的技术,模拟对正在运行的Web应用程序进行真实攻击,因此其结果通常可以被认为是正确的。在所有条件相同的情况下,DAST往往会比SAST产生更少的误报。

静态应用程序安全测试(SAST)

SAST或多或少与DAST相反。它从内向外地处理静态代码。一个很好的比喻就是让一个专家查看银行保险库的设计图纸,以寻找缺陷。这被称为白盒安全测试技术,因为测试可以看到Web应用程序的全部代码(与大多数真实攻击者不同)。

不幸的是,由于SAST运作在理论层面,而不是在实际层面,因此它很容易出现误报。然后就需要人工调查,需要花费时间和金钱。而且,就像那个“狼来了”的故事一样,SAST的性质可能会导致它的警告在现实场景中被用户忽视。

交互式应用程序安全测试(IAST)

IAST修改一个正在运行的应用程序,以便发现漏洞。这很像在你的银行保险库内放置传感器,以查看你的DAST攻击产生的影响。这被称为灰盒安全测试技术,实际上是黑盒和白盒方法的混合。它可以看到仅使用DAST会不可见的漏洞。

由于其侵入性,IAST不应被用于生产系统。这就限制了它在测试环境中的应用。这也是OAST可以被认为是世界上最好的安全测试技术的一个原因。

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

因此OAST具有上述三种技术的许多优点,同时最大限度地减少了它们的缺点。与SAST和IAST一样,它可以看到DAST无法看到的漏洞,但它不像SAST那样容易产生误报。而且,尽管IAST是一种侵入性的使用方法,但OAST不会做这样的改变,因此它更安全。

Web应用程序安全测试的不同用途

正如我们已经看到的,如今几乎每一个网站都是一个Web应用。但不同的情况会伴随着不同的安全测试挑战。

测试各类Web技术

Web应用程序本身有多种不同的类型。其中包括移动应用程序、单页应用程序(SPA)和渐进式Web应用程序(PWA)。每种类型都有一套明确的安全测试要求。例如,SPA大量使用JavaScript,这对自动化扫描工具来说是出了名的难以处理。

保持合规

某些行业也有他们自己非常特殊的需求。例如,金融和电子商务行业由于掌握的客户数据量很大,会受到网络安全合规标准的严格监管。这使得安全测试至关重要。

大规模自动化

使用安全测试的组织规模也会影响其所选择的解决方案。当然,在企业层面,单个产品组合中可能包含成千上万的Web应用程序,自动化是至关重要的。但是自动化漏洞扫描器无法像人一样发挥创造力,因此应始终进行手动渗透测试。

渗透测试

渗透测试人员是能够模拟对你的“保险库”进行攻击以改进它的专家。渗透测试本身属于道德黑客的更大范畴。道德黑客还包括漏洞赏金猎人,如果有人提供赏金,他们将会竞相寻找Web应用程序中的安全漏洞。发起这种活动的一种方式是通过像HackerOne这样的计划。

安全开发

正如我们前面所谈到的,确保银行保险库安全的一个首要因素是确保它在一开始就建造得很好。传统上,Web应用程序的安全被推迟到开发结束后,这不仅造成了延误,还可能耗费大量资金。简而言之,很难在开发软件的同时考虑安全问题。

但自动化安全测试的力量允许采用DevSecOps方法。DevSecOps使开发人员能够编写安全的代码。由于安全是内建的,而不是在最后才添加的,因此应用程序在发布之日就会更安全。最好的DevSecOps解决方案甚至可以教育使用它们的开发者,这意味着首要修复的Bug更少。

OAST是的一项技术。正如我们所知,由于DAST只能在外部产生可见差异的情况下才能看到漏洞,因此它有可能错过不可见的漏洞。OAST解决了这个问题,同时几乎没有误报,并且也不需要修改应用程序。

PortSwigger首创