滥用案例备忘录¶

简介¶

通常，当在需求中提及应用程序的安全级别时，会遇到以下表述：

应用程序必须安全.
应用程序必须防御针对此类应用程序的所有攻击.
应用程序必须防御 OWASP TOP 10 中的攻击
...

这些安全要求过于笼统，对开发团队来说毫无用处……

为了从务实的角度构建一个安全的应用程序，根据其业务和技术背景，识别应用程序必须防御的攻击至关重要。滥用案例是常用的威胁建模工具，查阅威胁建模备忘录可能会有所帮助。

目标¶

本备忘录的目标是解释什么是滥用案例，滥用案例在考虑应用程序安全性时为何重要，并最终提出一种务实的方法，用于构建滥用案例清单并跟踪应用程序中计划实现的每个功能。本备忘录可用于此目的，无论项目方法（瀑布或敏捷）如何。

关于本备忘录的重要说明

The main objective is to provide a pragmatic approach in order to allow a company or a project team
to start building and handling the list of abuse cases and then customize the elements
proposed to its context/culture in order to, finally, build its own method.

This cheat sheet can be seen as a getting-started tutorial.

背景与方法¶

为何要明确识别攻击¶

明确识别应用程序必须防御的攻击对于项目或冲刺中的后续步骤至关重要：

评估每个已识别攻击的业务风险，以便根据业务风险和项目/冲刺预算进行选择。
推导安全需求并将其添加到项目规范或冲刺的用户故事和验收标准中。
估计实施对策所需的初始项目/冲刺成本中的额外开销。
关于对策：允许项目团队定义对策，并确定其应位于何处（网络、基础设施、代码……）。

滥用案例的概念¶

你可以从两种方式思考滥用案例。第一种是发现攻击（回答“可能出错的是什么”），第二种是帮助记录这些攻击（非正式地，这包括威胁、问题、风险），以一种开发者可能不那么望而生畏的形式。

一个滥用案例可以定义为：

A way to use a feature that was not expected by the implementer,
allowing an attacker to influence the feature or outcome of use of
the feature based on the attacker action (or input).

Synopsis 这样定义一个滥用案例：

Misuse and abuse cases describe how users misuse or exploit the weaknesses
of controls in software features to attack an application.

This can lead to tangible business impact when a direct attack against
business functionalities, which may bring in revenue or provide
positive user experience, are attacked.

Abuse cases can also be an effective way to drive security requirements
that lead to proper protection of these critical business use cases.

Synopsis 来源

如何定义滥用案例清单¶

定义一个功能的滥用案例清单（在敏捷项目中可以映射到用户故事）有许多不同的方法。

威胁建模是一套预测可能出错的情况并确保我们对每个已识别的可能场景采取措施的技术。将“我们将对此做什么”清单上的每个项目都写成一个滥用案例，可能有助于您的工程团队处理输出。

OWASP Open SAMM 项目OWASP Open SAMM在成熟度级别 2 的安全实践需求驱动测试的B 流中提出了以下方法：

Misuse and abuse cases describe unintended and malicious use scenarios of the application, describing how an attacker could do this. Create misuse and abuse cases to misuse or exploit the weaknesses of controls in software features to attack an application. Use abuse-case models for an application to serve as fuel for identification of concrete security tests that directly or indirectly exploit the abuse scenarios.

Abuse of functionality, sometimes referred to as a “business logic attack”, depends on the design and implementation of application functions and features. An example is using a password reset flow to enumerate accounts. As part of business logic testing, identify the business rules that are important for the application and turn them into experiments to verify whether the application properly enforces the business rule. For example, on a stock trading application, is the attacker allowed to start a trade at the beginning of the day and lock in a price, hold the transaction open until the end of the day, then complete the sale if the stock price has risen or cancel if the price dropped?

Open SAMM 来源：验证需求驱动测试 B 流

另一种构建列表的方法可以是以下（更偏向自下而上和协作导向）：

举办一个工作坊，包括以下背景的人员：

业务分析师：将是业务关键人员，负责从业务角度描述每个功能。
风险分析师：将是公司的风险人员，负责评估提议攻击的业务风险（有时根据公司情况，也可能是业务分析师）。
渗透测试人员：将是攻击者，负责提出他们可以对相关业务功能执行的攻击。如果公司没有这种背景的人员，可以请求外部专家的服务。如果可能，请包括 2 名具有不同背景的渗透测试人员，以增加将被识别和考虑的可能攻击数量。
项目技术负责人：将是项目技术人员，负责在工作坊期间就识别出的攻击和对策进行技术交流。
质量保证分析师或功能测试人员：可能对应用程序/功能的预期工作方式（正向测试）、不工作方式（负向测试）以及导致其失败的原因（失败案例）有良好理解的人员。

在本次工作坊期间（时长取决于功能列表的大小，但 4 小时是一个好的开始），将处理项目或冲刺中的所有业务功能。工作坊的输出将是所有业务功能的攻击（滥用案例）清单。所有滥用案例都将具有风险评级，以便进行筛选和优先级排序。

重要的是要考虑技术和业务两种滥用案例，并相应地进行标记。

示例

技术标记的滥用案例：向评论输入字段添加跨站脚本注入。
业务标记的滥用案例：能够在下订单前任意修改在线商店中商品的价格，导致用户为所需商品支付较低的金额。

何时定义滥用案例清单¶

在敏捷项目中，定义工作坊必须在用户故事被纳入冲刺的会议之后进行。

在瀑布项目中，定义工作坊必须在业务识别并了解要实现的业务功能时进行。

无论项目采用何种模式（敏捷或瀑布），选择要解决的滥用案例都必须成为每个功能规范部分（瀑布）或用户故事验收标准（敏捷）中的安全要求，以便进行额外的成本/工作量评估、识别和实施对策。

每个滥用案例都必须有一个唯一的标识符，以便在整个项目/冲刺过程中进行跟踪（有关此点的详细信息将在提议部分给出）。

唯一 ID 格式的示例可以是ABUSE_CASE_001。

下图概述了所涉及的不同步骤的链式关系（从左到右）：

Overview Schema

提议¶

本提案将侧重于上一节中解释的工作坊的输出。

步骤 1：工作坊准备¶

首先，即使这看起来很明显，关键业务人员也必须确保了解、理解并能够解释在工作坊期间将要处理的业务功能。

其次，创建一个新的 Microsoft Excel 文件（您也可以使用 Google 表格或任何其他类似软件），包含以下工作表（或选项卡）：

功能 (FEATURES)
- 将包含一个表格，列出为工作坊计划的业务功能。
滥用案例 (ABUSE CASES)
- 将包含一个表格，列出工作坊期间识别的所有滥用案例。
对策 (COUNTERMEASURES)
- 将包含一个表格，列出为已识别滥用案例设想的可能对策（简要描述）。
- 此工作表不是强制性的，但对于（了解某个滥用案例）如果修复易于实施并因此可能影响风险评级时，它会很有用。
- 对策可以由 AppSec 专家在工作坊期间识别，因为 AppSec 人员必须能够执行攻击，也能够构建或识别防御（渗透测试人员通常不是这样，因为此人的重点通常只在攻击方面，所以，渗透测试人员 + AppSec 的组合对于获得 360 度视角非常有效）。

这是每个工作表的表示以及在工作坊期间将填写的示例内容：

功能表 (FEATURES sheet)

功能唯一 ID	功能名称	功能简要描述
功能_001 (FEATURE_001)	文档上传功能 (DocumentUploadFeature)	允许用户上传带有消息的文档 (Allow user to upload document along a message)

对策表 (COUNTERMEASURES sheet)

对策唯一 ID	对策简要描述	对策帮助/提示
防御_001 (DEFENSE_001)	通过将其加载到解析器中来验证上传的文件 (Validate the uploaded file by loading it into a parser)	使用 OWASP 关于文件上传的备忘录建议 (Use advice from the OWASP Cheat Sheet about file upload)

滥用案例表 (ABUSE CASES sheet)

滥用案例唯一 ID	受影响的功能 ID	滥用案例的攻击描述	攻击参考 ID（如果适用）	CVSS V3 风险评级（分数）	CVSS V3 字符串	滥用案例类型	适用的对策 ID	处理决定（待解决或风险接受）
滥用案例_001 (ABUSE_CASE_001)	功能_001 (FEATURE_001)	上传包含恶意宏的 Office 文件，负责投放恶意软件 (Upload Office file with malicious macro in charge of dropping a malware)	CAPEC-17	高 (7.7) (HIGH (7.7))	CVSS:3.0/AV:N/AC:H/PR:L/UI:R/S:C/C:N/I:H/A:H	技术 (Technical)	防御_001 (DEFENSE_001)	待解决 (To Address)

步骤 2：工作坊期间¶

使用电子表格审阅所有功能。

对于每个功能，遵循以下流程：

关键业务人员从业务角度解释当前功能。
渗透测试人员提出并解释他们可以对该功能执行的一系列攻击。
对于每个提出的攻击：
AppSec 提出对策和首选设置位置（基础设施、网络、代码、设计……）。
技术人员就所提议对策的可行性提供反馈。
渗透测试人员使用 CVSS v3（或其他标准）计算器确定风险评级。（例如：CVSS V3 计算器）
风险负责人应接受或修改风险评级，以确定准确反映公司实际业务影响的最终风险分数。
业务、风险和技术负责人应达成共识，并筛选当前功能的滥用列表，保留必须解决的滥用，然后在滥用案例工作表中相应地标记（如果接受风险，则添加评论解释原因）。
转到下一个功能……

如果无法安排渗透测试人员参与，则可以使用以下参考资料来识别适用于您功能的攻击：

关于攻击和对策知识库的重要说明

With time and experience across projects, you will obtain your own dictionary of attacks and countermeasures
that are applicable to the kind of application in your business domain.

This dictionary will speed up the future workshops in a significant way.

To promote the creation of this dictionary, you can, at the end of the project/sprint, gather the list
of attacks and countermeasures identified in a central location (wiki, database, file...) that will be
used during the next workshop in combination with input from penetration testers.

步骤 3：工作坊之后¶

此时，电子表格包含必须处理的所有滥用案例列表，以及（根据能力）可能对应的对策。

现在，还有两项任务：

关键业务人员必须更新每个功能的规范（瀑布）或每个功能的用户故事（敏捷），以将相关的滥用案例作为安全要求（瀑布）或验收标准（敏捷）包含在内。
关键技术人员必须评估实施对策的成本/工作量。

步骤 4：实施期间 - 滥用案例处理跟踪¶

为了跟踪所有滥用案例的处理情况，可以使用以下方法：

如果一个或多个滥用案例在以下级别处理：

设计、基础设施或网络层面
- 在文档或架构图中添加注释，表明“此设计/网络/基础设施考虑了滥用案例 ABUSE_CASE_001、ABUSE_CASE_002、ABUSE_CASE_xxx”。
代码层面
- 在类/脚本/模块中添加特殊注释，表明“此类/模块/脚本考虑了滥用案例 ABUSE_CASE_001、ABUSE_CASE_002、ABUSE_CASE_xxx”。
- 可以使用专用注解，如@AbuseCase(ids={"ABUSE_CASE_001","ABUSE_CASE_002"})，以方便跟踪并在集成开发环境中进行识别。

通过这种方式，可以（通过一些简单的脚本）识别滥用案例在哪里得到解决。

步骤 5：实施期间 - 滥用案例处理验证¶

由于滥用案例已定义，因此可以进行自动化或手动验证，以确保：

所有选定的滥用案例都已处理。
滥用案例已正确/完整处理。

验证可以有以下几种类型：

自动化（在项目持续集成作业中，定期在提交时、每日或每周运行）
- 静态应用安全测试 (SAST) 或动态应用安全测试 (DAST) 工具中的自定义审计规则。
- 专用的单元、集成或面向安全的功能测试。
- ...
手动
- 在设计或实施期间，项目成员之间的安全代码审查。
- 向渗透测试人员提供所有已解决的滥用案例列表，以便他们在对应用程序进行入侵测试时验证每个滥用案例的保护效率（渗透测试人员将验证已识别的攻击是否不再有效，并尝试发现其他可能的攻击）。
- ...

添加自动化测试还允许团队跟踪对策对滥用案例的有效性，并确定在项目维护或错误修复阶段对策是否仍然存在（以防止意外删除/禁用）。当采用持续交付方法时，这也很有用，以确保在开放应用程序访问之前，所有滥用案例的保护都已到位。

滥用案例作为用户故事的派生示例¶

以下部分展示了滥用案例作为用户故事的派生示例，此处以 OWASP TOP 10 作为输入来源。

以威胁为导向的角色

恶意用户
滥用用户
不知情用户

A1:2017-注入¶

史诗故事

几乎所有数据源都可以成为注入向量，包括环境变量、参数、外部和内部 Web 服务，以及所有类型的用户。注入缺陷发生在攻击者可以将恶意数据发送给解释器时。

滥用案例

作为攻击者，我将对用户或 API 接口的输入字段执行注入攻击（SQL、LDAP、XPath 或 NoSQL 查询、OS 命令、XML 解析器、SMTP 头、表达式语言和 ORM 查询）。

A2:2017-身份验证失效¶

史诗故事

攻击者可以访问数亿个有效的用户名和密码组合，用于凭据填充、默认管理帐户列表、自动化暴力破解和字典攻击工具。会话管理攻击已得到充分理解，特别是与未过期的会话令牌相关的攻击。

滥用案例

作为攻击者，我可以访问数亿个有效的用户名和密码组合，用于凭据填充。

滥用案例

作为攻击者，我拥有默认管理帐户列表、自动化暴力破解和字典攻击工具，我将其用于攻击应用程序和支持系统的登录区域。

滥用案例

作为攻击者，我使用过期和伪造的会话令牌来操纵会话令牌以获取访问权限。

A3:2017-敏感数据泄露¶

史诗故事

攻击者不直接攻击密码学，而是窃取密钥，执行中间人攻击，或从服务器、传输中或用户客户端（例如浏览器）窃取明文数据。通常需要手动攻击。先前获取的密码数据库可能被图形处理器（GPU）暴力破解。

滥用案例

作为攻击者，我窃取应用程序中暴露的密钥，以获取对应用程序或系统的未授权访问。

滥用案例

作为攻击者，我执行中间人攻击以获取流量并利用其获取敏感数据，并可能获得对应用程序的未授权访问。

滥用案例

作为攻击者，我从服务器、传输中或用户客户端（例如浏览器）窃取明文数据，以获取对应用程序或系统的未授权访问。

滥用案例

作为攻击者，我通过捕获流量并破解加密来发现并针对旧的或弱的加密算法。

A4:2017-XML 外部实体 (XXE)¶

史诗故事

如果攻击者能够上传 XML 或在 XML 文档中包含恶意内容，利用易受攻击的代码、依赖项或集成，他们就可以利用易受攻击的 XML 处理器。

滥用案例

作为攻击者，我利用应用程序中用户或系统可以上传 XML 的易受攻击区域来提取数据、从服务器执行远程请求、扫描内部系统、执行拒绝服务攻击以及执行其他攻击。

滥用案例

作为攻击者，我在上传到应用程序或系统的 XML 文档中包含恶意内容，以提取数据、从服务器执行远程请求、扫描内部系统、执行拒绝服务攻击以及执行其他攻击。

滥用案例

作为攻击者，我包含恶意 XML 代码，以利用易受攻击的代码、依赖项或集成来提取数据、从服务器执行远程请求、扫描内部系统、执行拒绝服务攻击（例如 Billion Laughs 攻击）以及执行其他攻击。

A5:2017-访问控制失效¶

史诗故事

利用访问控制是攻击者的核心技能。访问控制可以通过手动方式检测，或者在某些框架中可能通过自动化检测访问控制缺失的情况。

滥用案例

作为攻击者，我通过修改 URL、内部应用程序状态或 HTML 页面，或者简单地使用自定义 API 攻击工具来绕过访问控制检查。

滥用案例

作为攻击者，我操纵主键并将其更改为访问其他用户的记录，从而允许查看或编辑他人的帐户。

滥用案例

作为攻击者，我操纵应用程序中的会话、访问令牌或其他访问控制，以在未登录时作为用户操作，或在作为用户登录时作为管理员/特权用户操作。

滥用案例

作为攻击者，我利用元数据操纵，例如重放或篡改 JSON Web Token (JWT) 访问控制令牌或被操纵的 cookie 或隐藏字段，以提升权限或滥用 JWT 失效。

滥用案例

作为攻击者，我利用跨域资源共享 CORS 配置错误，允许未经授权的 API 访问。

滥用案例

作为攻击者，我强制未认证用户浏览认证页面，或强制标准用户浏览特权页面。

滥用案例

作为攻击者，我访问 POST、PUT 和 DELETE 操作缺少访问控制的 API。

滥用案例

作为攻击者，我针对正在使用的默认加密密钥、生成或重用弱加密密钥，或缺少密钥轮换的密钥。

滥用案例

作为攻击者，我发现用户代理（例如应用程序、邮件客户端）不验证收到的服务器证书是否有效，并执行导致未授权数据访问的攻击。

A6:2017-安全配置错误¶

史诗故事

攻击者通常会尝试利用未修补的漏洞或访问默认帐户、未使用的页面、未受保护的文件和目录等，以获取未经授权的访问或系统知识。

滥用案例

作为攻击者，我发现并利用应用程序堆栈任何部分中缺少适当安全强化配置或云服务上权限配置不当的问题。

滥用案例

作为攻击者，我发现已启用或安装的不必要功能（例如，不必要的端口、服务、页面、帐户或权限），并攻击或利用该弱点。

滥用案例

作为攻击者，我使用默认帐户及其密码来访问系统、接口，或对我本不应能够执行操作的组件执行操作。

滥用案例

作为攻击者，我发现应用程序中错误处理会揭示堆栈跟踪或其他过度信息丰富的错误消息，我可以用它们进行进一步的利用。

滥用案例

作为攻击者，我发现已升级的系统、最新的安全功能被禁用或未安全配置的区域。

滥用案例

作为攻击者，我发现应用程序服务器、应用程序框架（例如 Struts、Spring、ASP.NET）、库、数据库等中的安全设置未设置为安全值。

滥用案例

作为攻击者，我发现服务器未发送安全头或指令，或者设置了不安全的值。

A7:2017-跨站脚本 (XSS)¶

史诗故事

XSS 是 OWASP Top 10 中第二大常见问题，在大约三分之二的所有应用程序中都能找到。

滥用案例

作为攻击者，我执行反射型 XSS，其中应用程序或 API 将未经验证和未转义的用户输入作为 HTML 输出的一部分包含在内。我的成功攻击可以允许攻击者在受害者的浏览器中执行任意 HTML 和 JavaScript。通常，受害者需要与指向攻击者控制页面的一些恶意链接进行交互，例如恶意水坑网站、广告或类似内容。

滥用案例

作为攻击者，我执行存储型 XSS，其中应用程序或 API 存储未经净化的用户输入，这些输入稍后会被其他用户或管理员查看。

滥用案例

作为攻击者，我执行 DOM XSS，其中 JavaScript 框架、单页应用程序和 API 动态地将攻击者可控制的数据包含到页面中，从而容易受到 DOM XSS 的攻击。

A8:2017-不安全的反序列化¶

史诗故事

反序列化漏洞的利用有些困难，因为现成的漏洞利用很少在不修改或调整底层漏洞利用代码的情况下生效。

滥用案例

作为攻击者，我发现应用程序和 API 中可以提供恶意或篡改对象的反序列化区域。因此，我可以专注于与对象和数据结构相关的攻击，如果应用程序中存在可以在反序列化期间或之后更改行为的类，攻击者就可以修改应用程序逻辑或实现任意远程代码执行。或者我专注于数据篡改攻击，例如与访问控制相关的攻击，其中使用现有数据结构但内容被更改。

A9:2017-使用含有已知漏洞的组件¶

史诗故事

虽然很容易找到许多已知漏洞的现成漏洞利用，但其他漏洞需要集中精力开发自定义漏洞利用。

滥用案例

作为攻击者，我发现具有已知弱点的常见开源或闭源软件包，并针对已披露的漏洞和攻击进行攻击。

A10:2017-日志记录与监控不足¶

史诗故事

日志记录和监控不足的利用几乎是每一次重大事件的基础。攻击者依赖于缺乏监控和及时响应来实现其目标而不被发现。2016 年，识别一次泄露平均需要191 天，这给造成巨大损失留下了充足的机会。

滥用案例

作为攻击者，我攻击一个组织，而日志、监控系统和团队未能发现或响应我的攻击。

图表来源¶

所有图表均使用 https://www.draw.io/ 网站创建并导出（为 PNG 图像）以便集成到本文中。

每个图表的所有 XML 描述符文件均可在下方获取（使用 XML 描述，可以使用 DRAW.IO 网站修改图表）：

图表描述符档案