数百次渗透测试得出的五条经验

Web应用是攻击者成功入侵的首选路径。Verizon《2022年数据泄露调查报告》揭示，大约70%的数据泄露走的是Web应用路线。

经由300多次Web应用渗透测试之后，Web应用为何是数据泄露最大通途的原因显露了出来。开发人员一直在犯同样的安全错误，导致漏洞层出不穷。他们往往不使用安全框架，试图自行编写安全代码和身份验证过程。

有必要指出的是，开发人员承受着将产品快速推向市场的巨大压力。他们的绩效取决于能尽快引入多少功能，而不是能尽可能安全地引入多少功能。这就导致了在安全方面走捷径，最终在Web应用中留下漏洞的情况。

夯实应用安全的五条经验

渗透测试人员充当了唱反调的角色，逆向工程应用开发人员创建的东西，显示攻击者可以从什么地方以何种方式侵入。渗透测试的结果往往能凸显出常见的基本错误。软件开发公司可以汲取以下五条经验，学习如何让自己的应用更加安全。

1、攻击者仍然在利用跨站脚本（XSS）。跨站脚本一直都是攻击者钟爱的Web应用漏洞。2021年，由于应用开发框架的改进，跨站脚本掉出了开放式Web应用程序安全项目（OWASP）十大漏洞榜单，但仍现身于几乎每次渗透测试中。

跨站脚本常被认为是低风险的，但也可能引发严重风险，比如账户接管、数据盗窃和对应用基础设施的全面破坏。很多开发人员觉得使用成熟的输入验证库并设置恰当的HttpOnly cookie属性就够了，但只要用到自定义代码，就难免出现跨站脚本漏洞。以WordPress站点为例，针对管理员的跨站脚本攻击就很严重，因为拿到此类凭证的用户可以加载插件，从而在服务器上执行类似代码的恶意攻击载荷。

2、自动扫描器不够深入。如果只用自动化工具扫描Web应用，漏洞很有可能躲过扫描。这类工具采用模糊测试方法，通过向系统注入格式错误的数据检测漏洞，但这种技术可能会产生误报。

扫描器通常跟不上现代Web开发的速度，针对JavaScript单页应用、WebAssembly和Graph的扫描结果并不理想。复杂漏洞需要人工精心编制的载荷加以验证，降低了自动化工具的效率。

必须有人参与才能最为准确细致地分析漏洞和漏洞利用程序，但这些扫描器可以作为快速发现简单漏洞的补充资源加以利用。

3、自研身份验证通常太弱了。身份验证是保护Web应用安全的基础。试图创建自己的密码重置工作流时，开发人员往往没有用最安全的方式实现。

渗透测试人员常能获取到其他用户的信息，或者入手超出自身角色的过多权限。这造成了横向和纵向访问控制问题，让攻击者得以锁定用户账户或者破坏应用。

身份验证最终归结于这些协议都是怎么实现的。例如，安全声明标记语言（SAML）身份验证就是个日渐流行的单点登录协议，可以提高安全性，但如果未能正确实现，那引入的漏洞可能比堵上的更多。

4、攻击者瞄准业务逻辑中的缺陷。开发人员检查各种功能，确定自己是否满足了客户的用例。但他们通常不会换个角度看问题，不去确认攻击者可能通过哪种方式恶意使用这些功能。

电子商务网站的购物车就是个很好的例子。该功能业务关键，但往往不够安全，会产生严重的漏洞，例如在结账时将总数清零、结账后添加商品，或用其他SKU替换产品。

开发人员专注主要用例而未考虑到其他恶意用途无可指摘。他们的业绩看的就是能不能提供所需功能。高管则要看到其他方面，知晓业务逻辑应关联安全逻辑。具有极高业务价值的功能，如购物车或身份验证工作流，可能就不适合交给初级开发人员。

5、良好渗透测试不存在“超出范围”一说。取决于投入多少资源和资产，Web应用很快就会变得十分复杂。我们需要考虑到支持主应用功能的后端API服务器。

有必要让执行渗透测试的安全审计人员知道所有这些外部资产，了解这些资产如何连接哪些应用。开发人员可能会认为这些资产在“范围之外”，因而自己无需对此负责，但攻击者才不会管什么范围不范围的。正如渗透测试所显示的，没有什么东西是“超出范围”的。

平衡问题

如果能够事先了解一些此类常见风险，软件开发公司就能更好地与安全审计人员沟通，让渗透测试不那么痛苦。没有哪家公司会想阻碍开发人员，但在创造力和安全框架之间取得平衡，开发人员就能知道哪些地方可以自由发挥，而哪些地方需要遵从应用程序安全指南。

Verizon《2022年数据泄露调查报告》获取地址
https://www.verizon.com/business/resources/T9b9/reports/dbir/2022-data-breach-investigations-report-dbir.pdf

---

参考阅读
五大类渗透测试
每年一次渗透测试够用吗？
无密码身份验证：幻象多过现实
歪招盛行，多因素身份验证岌岌可危

原文始发于微信公众号（数世咨询）：数百次渗透测试得出的五条经验