企业应用的渗透测试与安全审计：何时需要、测试什么，以及如何跟进发现

许多企业主只有在出事之后才会考虑应用安全：客户数据泄露、管理员账号被盗，或者支付页面被篡改。然而，攻击者利用的大多数漏洞从上线那一天起就存在，只是没有人有意去查找。渗透测试（penetration test，常简称 pentest）就是抢在攻击者之前查找这些漏洞的方法：采用模拟攻击者的手法，但以正式授权、可控的方式进行。

本文用企业主和管理者能够直接使用的语言，说明渗透测试与安全审计：它与自动化扫描有何不同、何时应该进行、测试哪些内容、如何阅读报告，以及如何确保发现的问题真正得到修复。目标是让您的安全预算花在最重要的地方，而不是换来一张证书或一份最终被锁进抽屉的报告。

摘要

• 渗透测试是由像攻击者一样思考的测试人员进行的、经授权且可控的安全漏洞查找，不同于只匹配已知模式的自动化扫描
• 最佳测试时机是重大上线之前、架构变更或支付等敏感功能上线之后，以及至少每年定期一次
• 清晰的范围、书面的交战规则和安全的测试环境，与测试人员的能力同样重要
• 好的报告应包含按风险分级的发现、可复现的证据和具体的修复建议，而不只是一堆技术术语
• 渗透测试的价值在于修复和复测，而不在于报告本身

什么是渗透测试，它与扫描有何不同

有三类活动经常被混为一谈，但目的并不相同。

• 漏洞扫描（vulnerability scan）：自动化工具对照已知漏洞清单检查系统，例如过时的软件版本或薄弱的配置。成本低、速度快，适合定期运行，但不理解您的业务逻辑
• 渗透测试：测试人员借助工具，尝试真正突破系统，把几个小弱点串联成一条攻击路径。它回答的问题是“一个意志坚定的攻击者能达成什么？”
• 安全审计或代码审查：依照某项标准，对代码、配置、政策和流程进行系统性检查。它回答的问题是“我们是否遵循了正确的做法？”

三者相辅相成。扫描每周发现容易发现的问题，审计确认基础是否扎实，渗透测试则检验这一切在面对有创造力的对手时是否站得住。扫描器永远发现不了的例子：客户 A 只要修改页面地址中的一个数字，就能看到客户 B 的发票。扫描器看到的是一个运行正常的页面，而人工测试人员会立刻尝试修改这个数字。

何时进行渗透测试

并非每个应用都需要每月测试，但有些时刻几乎必须测试。

• 在上线会存储客户数据、员工数据或金融交易的新应用之前
• 重大变更之后：迁移到云、更换登录系统、新增支付集成，或向合作伙伴开放 API
• 在旺季或大型营销活动之前，此时攻击与欺诈往往增多
• 当企业客户或监管机构要求提供安全测试证明作为合作条件时
• 定期进行，至少每年一次，因为代码、库和攻击技术都在不断变化

如果预算紧张，请优先测试面向互联网并持有最敏感数据的组件：登录页面、客户门户、API 和支付流程。只能从办公网络访问的内部面板通常可以放在后面。但请记住，攻击者常常通过泄露的员工账号进入，因此内部面板也应在后续轮次中测试。

通常测试哪些内容

针对 Web 和移动应用的常见范围，遵循业界公认的风险类别，包括开放安全社区发布的 Web 应用头号风险清单。

身份认证与会话管理

测试人员会检查是否接受弱密码、登录尝试是否受到限制、账号找回流程是否可被滥用，以及用户退出后会话是否正确结束。如果您使用两步验证或无密码登录，备用流程也会被测试，因为它们常常成为后门。

访问控制

这是企业应用中最常产生严重发现的类别。问题在于：普通用户能否访问本应只属于管理员或其他用户的数据或功能？在多分支或多客户系统中，此项测试确保一方的数据不会泄露给另一方。

输入验证与注入

测试人员向表单、地址参数和文件上传输入意料之外的数据，看应用是否会被迫执行数据库命令、运行恶意脚本，或保存不应保存的文件。

业务逻辑

这是人类胜过工具的地方。例如：优惠券能否被多次使用，购物车中的价格能否在付款前被修改，订单能否在发货后取消而退款仍然成功，或者多级审批能否通过特定的步骤顺序被绕过。

配置与基础设施

不必要开放的端口、可被公众访问的管理面板、泄露系统结构的错误信息、对外公开的文件存储，以及遗留在代码中的密钥，都是常见发现。密钥的管理在关于密钥与 API 密钥管理的文章中有进一步介绍。

移动应用与 API

对于移动应用，测试人员检查设备上的数据存储、与服务器的通信，以及应用能否被拆解以提取密钥或敏感逻辑。对于 API，重点是每个请求的授权、速率限制以及响应中的多余数据。其设计原则与优秀的企业 API 设计一致。

测试模式：黑盒、灰盒与白盒

测试人员可以获得三个层级的信息，这一选择会影响成本和结果的深度。

• 黑盒：测试人员只得到目标地址，类似外部攻击者。真实，但大量时间花在侦察上，深度有限
• 灰盒：测试人员获得普通用户账号、基础文档，也许还有测试管理员账号。这是企业应用中最常见、最高效的选择，因为可以直接聚焦于逻辑和访问控制
• 白盒：测试人员可访问源代码和架构。最深入，适合支付模块等关键组件

对于大多数中型企业，对面向客户的应用做灰盒测试，性价比最高。

正确准备测试

结果的质量在很大程度上取决于您这边的准备。

• 设定书面范围：可测试的地址、应用和 API，以及禁止的内容，例如导致服务中断的攻击或对员工的社会工程
• 准备一个类似生产环境、使用虚构数据的测试环境。在某些情况下可能需要直接在生产环境测试，但必须约定时间、紧急联系人和恢复计划
• 通知需要知情的各方：托管服务商、支持团队和安全服务商，避免测试流量的激增被误认为真实事件
• 提供不同角色的账号，以便测试角色之间的访问控制
• 在您这边指定一位能在数小时而非数天内回答测试人员问题的负责人
• 测试前按照[企业数据备份策略](/blog/strategi-backup-data-bisnis)备份数据

合作协议还应涵盖保密、发现的存储方式，以及测试人员删除测试期间所获数据的义务。

选择渗透测试服务商

以下几点可以区分真正优秀的服务商与只会卖报告的服务商。

• 具有与您类似应用的经验，而不仅仅是通用网络
• 方法论清晰并引用公认标准，而不是只运行一个扫描器再换上自己的标志
• 测试人员的资质，以及愿意介绍实际执行人员
• 展示证据、复现步骤和修复建议的样例报告
• 愿意在修复后复测，最好包含在价格之内
• 书面的披露与保密政策

要警惕价格极低的报价和“零发现”的承诺。真实的应用几乎总有需要修复的地方，没有任何发现的报告往往意味着测试肤浅，而不是应用完美无缺。

阅读报告并确定优先级

一份好的渗透测试报告通常包括管理摘要、发现清单和技术附录。管理摘要面向管理层，详细发现面向技术团队。

每项发现应说明标题、风险等级、位置、证据或复现步骤、业务影响和修复建议。风险等级通常分为严重、高、中、低和提示性。优先级应同时权衡两件事：被利用的难易程度和损失的大小。

• 严重和高：数日内修复，必要时采取临时缓解措施，例如停用该功能
• 中：安排在下一个开发周期，并设定明确期限
• 低和提示性：归类后与其他修复一起处理

一个常见的错误是把原始评级当作绝对真理。存储健康数据的系统中一个中等漏洞，可能比公开信息网站上的高危漏洞更紧迫。在确定顺序时，请让了解业务的人参与。

闭环：修复、复测与学习

渗透测试的最大价值出现在收到报告之后。

• 为每项发现创建工单，指定负责人和期限，像其他工作一样跟踪
• 修复根本原因，而不只是症状。如果某个页面因为未检查授权而泄露，请查看其他页面是否有相同的代码模式
• 对重要发现要求复测，确认修复正确且没有打开新的漏洞
• 为已发现的弱点添加自动化测试，避免在下一次发布中重现，作为[自动化测试与 CI/CD](/blog/pengujian-otomatis-dan-ci-cd-untuk-aplikasi-bisnis)的一部分
• 记录反复出现的模式，并用于团队培训或编码规范
• 如果测试揭示了尚未涵盖的攻击路径，请更新[事件响应计划](/blog/rencana-respons-insiden-keamanan-siber-untuk-bisnis)

有了这一闭环，每次测试都会让应用更有韧性，而不只是产出一份文件。

在两次测试之间保持安全

渗透测试是某一时间点的快照。应用每周都在变化，因此需要在两次测试之间维持安全的习惯。

• 每次发布时自动进行漏洞扫描，并检查[第三方依赖](/blog/keamanan-dependensi-dan-rantai-pasok-perangkat-lunak)
• 对涉及登录、支付和权限的变更，使用安全检查清单进行代码审查
• 对可疑模式进行监控和告警，并以[良好的可观测性与日志](/blog/observabilitas-log-dan-penanganan-error-aplikasi-bisnis)作为支撑
• 简单的漏洞报告渠道：为发现问题的研究人员或客户提供专用邮箱
• 落实[企业应用基础安全](/blog/keamanan-dasar-aplikasi-bisnis)中介绍的基本原则

常见错误

• 测试太晚，临近上线才做，导致严重发现迫使延期或为赶期限而被忽视
• 范围过窄，最危险的部分从未被触及
• 把证书或干净的报告当作永久保证
• 因团队人手耗尽而不跟进发现
• 只测试一种用户角色，导致跨角色的弱点未被发现
• 把报告存放在许多人都能打开的地方，而它其实是通往您弱点的地图

常见问题

渗透测试费用是多少？

费用取决于范围、深度和测试人员的工作日数。小型 Web 应用需要几天，而拥有多种角色、API 和移动应用的大型系统可能需要数周。请依据书面范围索取报价，并比较包含的内容，尤其是复测和结果讲解会议。

自动化扫描足够吗？

对于应用简单的小企业，定期扫描加上良好的基本做法是合理的起点。但一旦应用存储客户数据、处理支付或有多种用户角色，就需要人工测试，因为逻辑与访问控制缺陷几乎不会被工具发现。

渗透测试会损坏系统吗？

管理得当的话风险很小，这也是为什么应事先约定规则、测试时间和数据备份。可能造成干扰的测试，例如高负载，通常被排除或单独进行。

应该多久重复一次？

至少每年一次，并且在架构、登录或支付发生重大变化时再做。对于变化很快的应用，可考虑对新发布的功能进行更轻量、更频繁的测试。

内部团队可以自己做吗？

内部团队可以运行扫描和代码审查。但外部测试人员带来全新的视角，不受开发人员所用假设的影响，因此更可能发现被遗漏的问题。

结论

渗透测试并不意味着您的应用很糟糕，而是表明您希望在别人之前发现问题。当范围清晰、测试人员经验丰富、发现结合业务判断确定优先级、修复经复测验证时，成果价值最大。与例行扫描和安全开发习惯相结合，定期测试可使安全成为持续的过程，而不是一次性的项目。

Agsora 帮助企业从一开始就以安全实践构建应用、为测试做好准备，并跟进发现直至解决。如果您想评估企业应用的安全就绪程度，欢迎与我们交流。