攻击面分析备忘录¶

什么是攻击面分析以及为何它很重要¶

本文介绍了一种进行攻击面分析和管理应用程序攻击面的简单实用方法。它旨在帮助开发人员在设计和更改应用程序时理解和管理应用程序安全风险，也适用于进行安全风险评估的应用程序安全专家。本文的重点是保护应用程序免受外部攻击——它不考虑针对系统用户或操作员的攻击（例如恶意软件注入、社会工程攻击），并且较少关注内部威胁，尽管其原则保持不变。内部攻击面可能与外部攻击面不同，并且某些用户可能拥有大量访问权限。

攻击面分析旨在映射出系统中有哪些部分需要审查和测试安全漏洞。攻击面分析的目的是了解应用程序中的风险区域，使开发人员和安全专家了解应用程序的哪些部分容易受到攻击，找到最小化这些风险的方法，并注意攻击面何时以及如何变化以及这从风险角度意味着什么。

虽然攻击面分析通常由安全架构师和渗透测试人员完成，但开发人员在设计、构建和更改系统时也应理解并监控攻击面。

攻击面分析有助于您

识别需要审查/测试安全漏洞的功能和系统部分
识别需要纵深防御保护的高风险代码区域——即您需要防御的系统部分
识别何时您已更改攻击面以及何时需要进行某种威胁评估

定义应用程序的攻击面¶

攻击面描述了攻击者可以进入系统以及从中获取数据的所有不同入口点。

应用程序的攻击面包括：

数据/命令进出应用程序的所有路径的总和，以及
保护这些路径的代码（包括资源连接和身份验证、授权、活动日志记录、数据验证和编码）
应用程序中使用的所有有价值数据，包括秘密和密钥、知识产权、关键业务数据、个人数据和 PII，以及
保护这些数据的代码（包括加密和校验和、访问审计以及数据完整性和操作安全控制）。

您将此模型与可以访问系统（无论是否已授权）的不同类型的用户——角色、权限级别——叠加起来。复杂性随着不同类型用户数量的增加而增加。重要的是要关注两个极端：未经身份验证的匿名用户和高权限管理员用户（例如数据库管理员、系统管理员）。

根据风险（面向外部或面向内部）、目的、实现、设计和技术，将每种攻击点类型分组。然后，计算每种类型的攻击点数量。接下来，为每种类型选择一些案例。最后，将您的审查/评估重点放在这些案例上。

通过这种方法，您无需了解每个端点即可理解攻击面和系统的潜在风险概况。相反，您可以计算不同通用类型的端点以及每种类型的端点数量。这使您能够预算大规模风险评估所需的投入，并且可以判断应用程序的风险概况何时发生了显著变化。

微服务和云原生应用程序¶

微服务和云原生应用程序由多个更小的组件组成，这些组件使用 API 松散耦合且可独立伸缩。在评估这种架构风格应用程序的攻击面时，您应该优先考虑可从攻击源（例如来自互联网的外部流量）访问的组件。此类组件可能位于多层代理、负载均衡器和入口控制器之后，并且可能在没有警告的情况下自动伸缩。

开源工具，例如 Scope 或 ThreatMapper 有助于可视化攻击面。

识别和映射攻击面¶

您可以开始通过图示和笔记构建攻击面的基线描述。花几个小时从攻击者的角度审查设计和架构文档。通读源代码并识别不同的入口/出口点

用户界面（UI）表单和字段
HTTP头和Cookie
API
文件
数据库
其他本地存储
电子邮件或其他类型的消息
运行时参数
...您的入口/出口点

不同攻击点的总数很容易达到数千甚至更多。为了便于管理，请根据功能、设计和技术将模型分解为不同类型

登录/身份验证入口点
管理界面
查询和搜索功能
数据录入（CRUD）表单
业务工作流
事务接口/API
操作命令和监控接口/API
与其他应用程序/系统的接口
...您的类型

您还需要通过访谈系统开发人员和用户，以及再次审查源代码，来识别应用程序中的有价值数据（例如机密、敏感、受监管的数据）。

您还可以通过扫描应用程序来构建攻击面的图景。对于Web应用程序，您可以使用诸如 ZAP、Arachni、Skipfish、w3af 等工具，或众多商业动态测试和漏洞扫描工具或服务中的一个，来爬取您的应用程序并映射通过Web可访问的应用程序部分。一些Web应用程序防火墙（WAF）也可能能够导出应用程序入口点的模型。

通过演练系统中的一些主要用例来验证和完善您对攻击面的理解：注册和创建用户配置文件、登录、搜索项目、下订单、更改订单等等。跟踪控制流和数据在系统中的流动，查看信息如何被验证以及存储在哪里，哪些资源被访问，以及涉及哪些其他系统。攻击面分析与应用程序威胁建模之间存在递归关系：攻击面的变化应触发威胁建模，而威胁建模有助于您理解应用程序的攻击面。

攻击面模型可能一开始是粗略和不完整的，特别是如果您之前没有对应用程序进行任何安全工作。随着您在安全分析中深入挖掘，或者随着您更多地使用应用程序并意识到您对攻击面的理解有所提高时，再填补这些空白。

度量和评估攻击面¶

一旦您有了攻击面的映射，请识别高风险区域。重点关注远程入口点——与外部系统和互联网的接口——尤其是系统允许匿名、公共访问的地方。

面向网络的，尤其是面向互联网的代码
Web表单
来自网络外部的文件
与其他系统的向后兼容接口——旧协议，有时是旧代码和库，难以维护和测试多个版本
自定义API——协议等——在设计和实现中很可能出现错误
安全代码：与加密、身份验证、授权（访问控制）和会话管理相关的任何内容

这些通常是您最容易受到攻击的地方。然后了解您已有哪些补偿性控制措施，例如网络防火墙和应用程序防火墙等操作控制，以及入侵检测或防御系统，以帮助保护您的应用程序。

微软的Michael Howard和其他研究人员开发了一种测量应用程序攻击面的方法，并用于跟踪攻击面随时间的变化，称之为相对攻击面商（RSQ）。使用这种方法，您可以计算系统的整体攻击面分数，并随着系统发生变化和部署方式的改变来衡量这个分数。卡内基梅隆大学的研究人员在此工作的基础上，开发了一种计算像SAP这样大型系统的攻击面度量的正式方法。他们将攻击面计算为所有入口和出口点、通道（客户端或外部系统连接到系统的不同方式，包括TCP/UDP端口、RPC端点、命名管道等）以及不受信任数据元素的总和。然后，他们将损害潜力/工作量比率应用于这些攻击面元素，以识别高风险区域。

请注意，部署应用程序的多个版本、保留不再使用但以防将来可能需要的特性，或者保留旧的备份副本和未使用的代码都会增加攻击面。应使用源代码控制和健全的变更管理/配置实践，以确保实际部署的攻击面尽可能与理论攻击面匹配。

代码和数据的备份——在线和离线介质上的——是系统攻击面中重要但经常被忽视的一部分。如果您不保护您的备份，而将所有东西都交给了恶意行为者，那么通过编写安全软件和强化基础设施来保护您的数据和知识产权都将是徒劳的。

管理攻击面¶

一旦您对攻击面有了基线了解，您就可以在对应用程序进行更改时，以此为基础逐步识别和管理风险。问问自己：

什么改变了？
您正在做什么不同的事情？（技术、新方法……）
您可能打开了哪些漏洞？

您创建的第一个网页会显著扩大系统的攻击面，并引入各种新风险。如果您在该页面上添加另一个字段，或者添加另一个类似的网页，虽然技术上您已经使攻击面更大，但您并没有以有意义的方式增加应用程序的风险概况。除非您遵循新的设计或使用新的框架，否则这些增量更改大多是重复性的。

如果您添加另一个与现有网页采用相同设计和技术的网页，则很容易理解它需要多少安全测试和审查。如果您添加新的Web服务API或可以从互联网上传的文件，这些更改中的每一个又具有不同的风险概况——查看该更改是否符合现有类别，查看现有控制和保护是否适用。如果您添加的内容不属于现有类别，这意味着您必须进行更彻底的风险评估，以了解您可能打开哪种安全漏洞以及需要采取哪些保护措施。

会话管理、身份验证和密码管理的变化直接影响攻击面，需要进行审查。授权和访问控制逻辑的更改也需要审查，特别是添加或更改角色定义、添加具有高权限的管理员用户或管理员功能。同样，处理加密和秘密的代码更改也需要审查。数据验证方式的根本性变化，以及分层和信任关系的重大架构变化，或技术架构的根本性变化——例如更换您的Web服务器或数据库平台，或更改运行时操作系统——也都需要审查。

当您添加新的用户类型、角色或权限级别时，您也进行相同的分析和风险评估。将访问类型叠加到数据和功能上，寻找问题和不一致之处。了解应用程序的访问模型很重要，无论是正向（默认拒绝访问）还是负向（默认允许访问）。在正向访问模型中，定义新用户类型或角色允许访问哪些数据或功能时出现的任何错误都易于发现。在负向访问模型中，您必须更加谨慎，以确保用户不会访问其不应被允许访问的数据/功能。

这种威胁或风险评估可以定期进行，或者作为串行/阶段式/螺旋式/瀑布式开发项目设计工作的一部分，或者在敏捷/迭代开发中持续和增量地进行。

通常，随着您添加更多接口、用户类型以及与其他系统集成，应用程序的攻击面会随时间增加。您还希望在可能的情况下寻找减小攻击面的方法，例如通过简化模型（例如减少用户级别数量或不存储绝非必须的机密数据）、关闭不使用的功能和接口，以及引入Web应用程序防火墙（WAF）和实时应用程序特定攻击检测等操作控制。