Abuse Case Cheat Sheet (Historical) / 滥用案例备忘单（历史）¶

Archive Statement / 存档声明¶

Reviewers have identified that abuse cases are rarely used in practice. Additionally, the material is presented as a "getting started tutorial" which isn't appropriate for the cheat sheet series.

审查人员发现，滥用案例在实践中很少使用。此外，该材料以“入门教程”的形式呈现，不适合备忘单系列。

Introduction / 介绍¶

Often when the security level of an application is mentioned in requirements, the following expressions are met:

通常，当需求中提到应用程序的安全级别时，会满足以下_表达式_：

The application must be secure.
中文：应用程序必须安全。
The application must defend against all attacks targeting this category of application.
中文：应用程序必须防御针对此类应用程序的所有攻击。
The application must defend against attacks from the OWASP TOP 10
中文：应用程序必须防御来自 OWASP TOP 10 的攻击
...

These security requirements are too generic, and thus useless for a development team...

这些安全要求太笼统，因此对于开发团队来说毫无用处......

In order to build a secure application, from a pragmatic point of view, it is important to identify the attacks which the application must defend against, according to its business and technical context. Abuse cases were a frequently recommended threat modeling technique, and reviewing the threat modeling cheat sheet may be helpful. In practice, the abuse case framework seems heavyweight and there are few published examples or success stories.

为了构建安全的应用程序，从实用的角度来看，根据应用程序的业务和技术环境来识别应用程序必须防御的攻击非常重要。滥用案例是经常推荐的_威胁建模_技术，查看威胁建模备忘单可能会有所帮助。在实践中，滥用案例框架似乎很重量级，并且很少有公开的例子或成功案例。

Objective / 客观的¶

The objective of this cheat sheet is to provide an explanation of what an Abuse Case is, how abuse cases can be important when considering the security of an application, and finally to provide a proposal for a pragmatic approach to building a list of abuse cases and tracking them for every feature planned for implementation as part of an application. The cheat sheet may be used for this purpose regardless of the project methodology used (waterfall or agile).

本备忘单的目的是解释什么是滥用案例，在考虑应用程序的安全性时滥用案例的重要性，并最终提供建议，以实用的方法构建滥用案例列表并跟踪计划作为应用程序一部分实现的每个功能。无论使用何种项目方法（瀑布式或敏捷式），备忘单都可以用于此目的。

Important note about this Cheat Sheet:

关于本备忘单的重要说明：

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.

Context & approach / 背景和方法¶

Why clearly identify the attacks / 为什么要清楚地识别攻击¶

Clearly identifying the attacks against which the application must defend is essential in order to enable the following steps in a project or sprint:

为了在项目或冲刺中实现以下步骤，清楚地识别应用程序必须防御的攻击至关重要：

Evaluate the business risk for each of the identified attacks in order to perform a selection according to the business risk and the project/sprint budget.
中文：评估已识别攻击的业务风险，以便根据业务风险和项目/冲刺预算进行选择。
Derive security requirements and add them into the project specification or sprint's user stories and acceptance criteria.
中文：导出安全需求并将其添加到项目规范或冲刺的用户故事和验收标准中。
Estimate the overhead of provision in the initial project/sprint charge that will be necessary to implement the countermeasures.
中文：估算在初始项目/冲刺费用中提供反制措施所需的额外开销。
About countermeasures: Allow the project team to define them, and to determine in which location (network, infrastructure, code...) they should be located.
中文：关于对策：允许项目团队定义它们，并确定它们应该位于哪个位置（网络、基础设施、代码......）。

Notion of Abuse Cases / 滥用案件的概念¶

You can think of Abuse cases in two ways. The first is to discover attacks (answer the question "what can go wrong"), and the second is to help record those attacks (informally, this includes threats, issues, risks) in a form that may be less intimidating to developers.

您可以通过两种方式来思考滥用案例。第一个是发现攻击（回答“可能会出现什么问题”的问题），第二个是帮助以一种对开发人员来说不那么吓人的形式记录这些攻击（非正式地，这包括威胁、问题、风险）。

An Abuse Case can be defined as:

滥用案例可以定义为：

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 defines an Abuse Case like this:

概要定义了一个滥用案例，如下所示：

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 source) （剧情简介来源）

How to define the list of Abuse Cases / 如何定义滥用案例列表¶

There are many different ways to define the list of abuse cases for a feature (that can be mapped to a user story in agile projects).

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

Threat Modeling) （威胁建模） is a set of techniques for anticipating what can go wrong, and ensuring we do something about each identified possible scenario. Taking each item on the list of "what are we going to do about it" and writing an abuse case may help your engineering teams process the output.

The project OWASP Open SAMM proposes the following approach in the Stream B of the Security Practice Requirements Driven Testing for the Maturity level 2:

项目 OWASP Open SAMM 在成熟度级别 2 的安全实践_需求驱动测试_的_Stream 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 source: Verification Requirement Driven Testing Stream B

开放 SAMM 源码：验证需求驱动测试流 B

Another way to achieve the building of the list can be the following (more bottom-up and collaboratively oriented):

另一种实现列表构建的方法如下（更加自下而上且面向协作）：

Make a workshop that includes people with the following profiles:

举办一个研讨会，其中包括具有以下特征的人员：

Business analyst: Will be the business key people that will describe each feature from a business point of view.
中文：业务分析师：将是业务关键人员，将从业务角度描述每个功能。
Risk analyst: Will be the company's risk personnel that will evaluate the business risk from a proposed attack (sometimes it is the Business analyst depending on the company).
中文：风险分析师：将是公司的风险人员，负责评估拟议攻击的业务风险（有时是业务分析师，具体取决于公司）。
Penetration tester: Will be the attacker that will propose attacks that they can perform on the business feature(s) in question. If the company does not have a person with this profile then it is possible to request the service of an external specialist. If possible, include 2 penetration testers with different backgrounds in order to increase the number of possible attacks that will be identified and considered.
中文：渗透测试人员：将是_攻击者_，他们将提出可以对相关业务功能执行的攻击。如果公司没有具备此资质的人员，则可以请求外部专家提供服务。如果可能，请包括 2 名具有不同背景的渗透测试人员，以增加将识别和考虑的可能攻击的数量。
Technical leaders of the projects: Will be the project technical people and will allow technical exchange about attacks and countermeasures identified during the workshop.
中文：项目的技术领导者：将担任项目技术人员，并就研讨会期间确定的攻击和对策进行技术交流。
Quality assurance analyst or functional tester: Personnel that may have a good sense of how the application/functionality is intended to work (positive testing), not work (negative testing), and what things cause it to fail (failure cases).
中文：质量保证分析师或功能测试员：可能对应用程序/功能应该如何工作（正向测试）、不应该工作（负向测试）以及导致其失败的因素（故障案例）有良好理解的人员。

During this workshop (duration will depend on the size of the feature list, but 4 hours is a good start) all business features that will be part of the project or the sprint will be processed. The output of the workshop will be a list of attacks (abuse cases) for all business features. All abuse cases will have a risk rating that allows for filtering and prioritization.

在本次研讨会期间（持续时间取决于功能列表的大小，但 4 小时是一个好的开始），将处理将成为项目或冲刺一部分的所有业务功能。研讨会的输出将是所有业务功能的攻击（滥用案例）列表。所有滥用案例都会有一个风险评级，以便进行过滤和优先排序。

It is important to take into account Technical and Business kind of abuse cases and mark them accordingly.

重要的是要考虑技术和业务类型的滥用案例并相应地标记它们。

Example:

例子：

Technical flagged abuse case: Add Cross Site Scripting injection into a comment input field.
中文：技术标记的滥用案例：将跨站点脚本注入添加到评论输入字段中。
Business flagged abuse case: Ability to arbitrarily modify the price of an article in an online shop prior to passing an order causing the user to pay a lower amount for the wanted article.
中文：商业标记的滥用案例：能够在传递订单之前任意修改在线商店中商品的价格，导致用户为想要的商品支付较低的金额。

When to define the list of Abuse Cases / 何时定义滥用案例列表¶

In agile projects, the definition workshop must be made after the meeting in which User Stories are included in a Sprint.

在敏捷项目中，定义研讨会必须在用户故事包含在冲刺中的会议之后进行。

In waterfall projects, the definition workshop must be made when the business features to implement are identified and known by the business.

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

Whatever the mode of the project used (agile or waterfall), the abuse cases selected to be addressed must become security requirements in each feature specification section (waterfall) or User Story acceptance criteria (agile) in order to allow additional cost/effort evaluation, identification and implementation of the countermeasures.

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

Each abuse case must have a unique identifier in order to allow tracking throughout the whole project/sprint (details about this point will be given in the proposal section).

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

An example of unique ID format can be ABUSE_CASE_001.

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

The following figure provides an overview of the chaining of the different steps involved (from left to right):

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

Overview Schema

概述架构

Proposal / 提议¶

The proposal will focus on the output of the workshop explained in the previous section.

该提案将重点关注上一节中解释的研讨会的成果。

Step 1: Preparation of the workshop / 第一步：研讨会准备¶

First, even if it seems obvious, the key business people must be sure to know, understand and be able to explain the business features that will be processed during the workshop.

首先，即使看起来很明显，关键业务人员也必须确保知道、理解并能够解释研讨会期间将处理的业务特征。

Secondly, create a new Microsoft Excel file (you can also use Google Sheets or any other similar software) with the following sheets (or tabs):

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

FEATURES
中文：特征**
- Will contain a table with the list of business features planned for the workshop.
  中文：将包含一个表格，其中列出了研讨会计划的业务功能列表。
ABUSE CASES
中文：滥用案例**
- Will contain a table with all abuse cases identified during the workshop.
  中文：将包含一个表格，其中包含研讨会期间确定的所有滥用案例。
COUNTERMEASURES
中文：对策**
- Will contain a table with the list of possible countermeasures (light description) imagined for the abuse cases identified.
  中文：将包含一个表格，其中列出了针对已识别的滥用案例设想的可能对策（简单描述）。
- This sheet is not mandatory, but it can be useful (for an abuse case to know), if a fix is easy to implement and then can impact the risk rating.
  中文：此表不是强制性的，但如果修复很容易实施并且可以影响风险评级，则它可能很有用（对于滥用案例而言）。
- Countermeasures can be identified by the AppSec profile during the workshop, because an AppSec person must be able to perform attacks but also to build or identify defenses (it is not always the case for the Pentester profile because this person's focus is generally on the attack side only, so, the combination Pentester + AppSec is very efficient to have a 360 degree view).
  中文：在研讨会期间，可以通过 AppSec 配置文件来确定对策，因为 AppSec 人员必须能够执行攻击，而且还必须能够构建或识别防御（渗透测试人员配置文件并不总是如此，因为此人的重点通常仅在攻击方，因此，渗透测试人员 + AppSec 的组合对于拥有 360 度视图非常有效）。

This is the representation of each sheet along with an example of content that will be filled during the workshop:

这是每张表格的表示以及研讨会期间将填写的内容示例：

FEATURES sheet:

_特点_表：

Feature unique ID / 功能唯一ID	Feature name / 功能名称	Feature short description / 功能简短描述
FEATURE_001	DocumentUploadFeature 文档上传功能	Allow user to upload document along a message 允许用户在消息中上传文档

COUNTERMEASURES sheet:

Countermeasure unique ID / 对策唯一标识	Countermeasure short description / 对策简短描述	Countermeasure help/hint
DEFENSE_001	Validate the uploaded file by loading it into a parser 通过将上传的文件加载到解析器中来验证该文件	Use advice from the OWASP Cheat Sheet about file upload 参考 OWASP 欺骗表关于文件上传的建议

ABUSE CASES sheet:

_滥用案例_表：

Abuse case unique ID / 滥用案例唯一标识符	Feature ID impacted / 受影响的特性标识符	Abuse case's attack description / 滥用案例的攻击描述	Attack referential ID (if applicable) / 攻击参考标识符（如适用）	Business risk rating / 业务风险评级	CVSS severity and vector (if applicable) / CVSS 严重性和向量（如适用）	Kind of abuse case / 滥用案例类型	Countermeasure ID applicable / 适用的对策ID	Handling decision (To Address or Risk Accepted) / 处理决策（解决或接受风险）
ABUSE_CASE_001	FEATURE_001	Upload Office file with malicious macro in charge of dropping a malware 上传带有恶意宏的办公文件，负责投放恶意软件	CAPEC-17	To be assessed 待评估	Not assigned 未分配	Technical 技术	DEFENSE_001	To Address 为了解决

Step 2: During the workshop / 第 2 步：研讨会期间¶

Use the spreadsheet to review all the features.

使用电子表格查看所有功能。

For each feature, follow this flow:

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

Key business people explain the current feature from a business point of view.
中文：主要业务人员从业务角度解释了当前的功能。
Penetration testers propose and explain a set of attacks that they can perform against the feature.
中文：渗透测试人员提出并解释了他们可以针对该功能执行的一组攻击。
For each attack proposed:
中文：对于提出的每个攻击：
Appsec proposes a countermeasure and a preferred set up location (infrastructure, network, code, design...).
中文：Appsec 提出对策和首选设置位置（基础设施、网络、代码、设计...）。
Technical people give feedback about the feasibility of the proposed countermeasure.
中文：技术人员对所提出的对策的可行性进行反馈。
If an abuse case involves a specific vulnerability, penetration testers may record its Common Vulnerability Scoring System (CVSS) severity score and vector. FIRST explains that CVSS measures severity and should not be used alone to assess risk.
中文：如果一个滥用案例涉及特定的漏洞，渗透测试人员可以记录其通用漏洞评分系统（CVSS）严重性评分和向量。FIRST 解释说 CVSS 衡量严重性，不应单独用于评估风险。
Risk leaders assess the abuse case's likelihood and business impact using the organization's risk assessment method. Record this business risk rating and its rationale separately from any CVSS score; do not modify a CVSS score to represent business risk.
中文：风险领导者使用组织的风险评估方法来评估滥用案例的可能性和业务影响。将此业务风险评级及其理由与任何 CVSS 分数分开记录；请勿修改 CVSS 分数来代表业务风险。
Business, Risk, and Technical leaders should find a consensus and filter the list of abuses for the current feature to keep the ones that must be addressed, and then flag them accordingly in the ABUSE CASES sheet (if risk is accepted then add a comment to explain why).
中文：业务、风险和技术领导者应达成共识，并过滤当前功能的滥用列表，以保留必须解决的滥用行为，然后在_滥用案例_表中相应地标记它们（如果接受风险，则添加评论以解释原因）。
Pass to next feature...
中文：转到下一个功能...

If the presence of penetration testers is not possible then you can use the following references to identify the applicable attacks on your features:

如果渗透测试人员不可能在场，那么您可以使用以下参考来识别针对您的功能的适用攻击：

OWASP Automated Threats to Web Applications) （OWASP 对 Web 应用程序的自动威胁）
OWASP Testing Guide) （OWASP 测试指南）
OWASP Mobile Testing Guide) （OWASP 移动测试指南）
Common Attack Pattern Enumeration and Classification (CAPEC)) （常见攻击模式枚举和分类 (CAPEC)）

Important note on attacks and countermeasure knowledge base(s):

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

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.

Step 3: After the workshop / 第三步：研讨会结束后¶

The spreadsheet contains (at this stage) the list of all abuse cases that must be handled and, potentially (depending on the capacity) corresponding countermeasures.

该电子表格包含（在此阶段）必须处理的所有滥用案例的列表，以及可能的（取决于能力）相应的对策。

Now, there are two remaining task:

现在，还剩下两个任务：

Key business people must update the specification of each feature (waterfall) or the User Story of each feature (agile) to include the associated abuse cases as Security Requirements (waterfall) or Acceptance Criteria (agile).
中文：关键业务人员必须更新每个功能（瀑布）的规范或每个功能（敏捷）的用户故事，以将相关的滥用案例包含为安全要求（瀑布）或验收标准（敏捷）。
Key technical people must evaluate the overhead in terms of expense/effort to take into account the countermeasure.
中文：关键技术人员必须评估采取对策的代价/努力，以考虑开销。

Step 4: During implementation - Abuse cases handling tracking / 第 4 步：实施期间 - 滥用案例处理跟踪¶

In order to track the handling of all the abuse cases, the following approach can be used:

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

If one or several abuse cases are handled at:

如果一件或多件虐待案件在以下地点处理：

Design, Infrastructure or Network level
中文：设计、基础设施或网络级别**
- Make a note in the documentation or schema to indicate that This design/network/infrastructure takes into account the abuse cases ABUSE_CASE_001, ABUSE_CASE_002, ABUSE_CASE_xxx.
  中文：在文档或模式中注明，指明“此设计/网络/基础设施考虑了滥用案例 ABUSE_CASE_001、ABUSE_CASE_002、ABUSE_CASE_xxx_”。
Code level
中文：代码级别**
- Put a special comment in the classes/scripts/modules to indicate that This class/module/script takes into account the abuse cases ABUSE_CASE_001, ABUSE_CASE_002, ABUSE_CASE_xxx.
  中文：在类/脚本/模块中添加特殊注释，指明“此类/模块/脚本考虑了滥用案例 ABUSE_CASE_001、ABUSE_CASE_002、ABUSE_CASE_xxx_”。
- Dedicated annotation like @AbuseCase(ids={"ABUSE_CASE_001","ABUSE_CASE_002"}) can be used to facilitate tracking and allow identification into integrated development environment.
  中文：像@AbuseCase(ids={"ABUSE_CASE_001","ABUSE_CASE_002"})这样的专用注释可用于促进跟踪并允许识别到集成开发环境中。

Using this way, it becomes possible (via some minor scripting) to identify where abuse cases are addressed.

使用这种方式，可以（通过一些小的脚本）确定滥用案例的处理位置。

Step 5: During implementation - Abuse cases handling validation / 第 5 步：实施期间 - 滥用案例处理验证¶

As abuse cases are defined, it is possible to put in place automated or manual validations to ensure that:

定义滥用案例后，可以进行自动或手动验证，以确保：

All the selected abuse cases are handled.
中文：所有选定的虐待案件均已得到处理。
An abuse case is correctly/completely handled.
中文：滥用案例得到正确/完整处理。

Validations can be of the following varieties:

验证可以有以下几种：

Automated (run regularly at commit, daily or weekly in the Continuous Integration Jobs of the project):
中文：自动化（在项目的持续集成作业中每天或每周在提交时定期运行）：
- Custom audit rules in Static Application Security Testing (SAST) or Dynamic Application Security Testing (DAST) tools.
  中文：静态应用程序安全测试 (SAST) 或动态应用程序安全测试 (DAST) 工具中的自定义审核规则。
- Dedicated unit, integration or functional security oriented tests.
  中文：面向专用单元、集成或功能安全的测试。
- ...
Manual:
中文：手动的：
- Security code review between project's peers during the design or implementation.
  中文：在设计或实施过程中，项目同行之间进行安全代码审查。
- Provide the list of all abuse cases addressed to pentesters so that they may validate the protection efficiency for each abuse case during an intrusion test against the application (the pentester will validate that the attacks identified are no longer effective and will also try to find other possible attacks).
  中文：向渗透测试人员提供所有滥用案例的列表，以便他们可以在针对应用程序的入侵测试期间验证每个滥用案例的保护效率（渗透测试人员将验证所识别的攻击不再有效，并且还将尝试查找其他可能的攻击）。
- ...

Adding automated tests also allow teams to track the effectiveness of countermeasures against abuse cases and determine if the countermeasures are still in place during a maintenance or bug fixing phase of a project (to prevent accidental removal/disabling). It is also useful when a Continuous Delivery approach is used, to ensure that all abuse cases protections are in place before opening access to the application.

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

Example of derivation of Abuse Cases as User Stories / 将滥用案例派生为用户故事的示例¶

The following section shows an example of derivation of Abuse Cases as User Stories, here using the OWASP TOP 10 as input source.

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

Threat Oriented Personas:

面向威胁的角色：

Malicious User
中文：恶意用户
Abusive User
中文：滥用用户
Unknowing User
中文：不知情的用户

A1:2017-Injection / A1:2017-注射¶

Epic:

史诗：

Almost any source of data can be an injection vector, environment variables, parameters, external and internal web services, and all types of users. Injection flaws occur when an attacker can send hostile data to an interpreter.

几乎任何数据源都可以是注入向量、环境变量、参数、外部和内部 Web 服务以及所有类型的用户。当攻击者向解释器发送恶意数据时，就会出现注入缺陷。

Abuse Case:

滥用案例：

As an attacker, I will perform an injection attack (SQL, LDAP, XPath, or NoSQL queries, OS commands, XML parsers, SMTP headers, expression languages, and ORM queries) against input fields of the User or API interfaces

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

A2:2017-Broken Authentication / A2:2017-身份验证失效¶

Epic:

史诗：

Attackers have access to hundreds of millions of valid username and password combinations for credential stuffing, default administrative account lists, automated brute force, and dictionary attack tools. Session management attacks are well understood, particularly in relation to unexpired session tokens.

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

Abuse Case:

滥用案例：

As an attacker, I have access to hundreds of millions of valid username and password combinations for credential stuffing.

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

Abuse Case:

滥用案例：

As an attacker, I have default administrative account lists, automated brute force, and dictionary attack tools I use against login areas of the application and support systems.

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

Abuse Case:

滥用案例：

As an attacker, I manipulate session tokens using expired and fake tokens to gain access.

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

A3:2017-Sensitive Data Exposure / A3:2017-敏感数据泄露¶

Epic:

史诗：

Rather than directly attacking crypto, attackers steal keys, execute man-in-the-middle attacks, or steal clear text data off the server, while in transit, or from the user's client, e.g. browser. A manual attack is generally required. Previously retrieved password databases could be brute forced by Graphics Processing Units (GPUs).

攻击者不是直接攻击加密货币，而是窃取密钥、执行中间人攻击，或者从服务器、传输过程中或用户的客户端（例如客户端）窃取明文数据。浏览器。一般需要手动攻击。以前检索到的密码数据库可能会被图形处理单元 (GPU) 暴力破解。

Abuse Case:

滥用案例：

As an attacker, I steal keys that were exposed in the application to get unauthorized access to the application or system.

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

Abuse Case:

滥用案例：

As an attacker, I execute man-in-the-middle attacks to get access to traffic and leverage it to obtain sensitive data and possibly get unauthorized access to the application.

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

Abuse Case:

滥用案例：

As an attacker, I steal clear text data off the server, while in transit, or from the user's client, e.g. browser to get unauthorized access to the application or system.

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

Abuse Case:

滥用案例：

As an attacker, I find and target old or weak cryptographic algorithms by capturing traffic and breaking the encryption.

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

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

Epic:

史诗：

Attackers can exploit vulnerable XML processors if they can upload XML or include hostile content in an XML document, exploiting vulnerable code, dependencies or integrations.

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

Abuse Case:

滥用案例：

As an attacker, I exploit vulnerable areas of the application where the user or system can upload XML to extract data, execute a remote request from the server, scan internal systems, perform a denial-of-service attack, as well as execute other attacks.

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

Abuse Case:

滥用案例：

As an attacker, I include hostile content in an XML document which is uploaded to the application or system to extract data, execute a remote request from the server, scan internal systems, perform a denial-of-service attack, as well as execute other attacks.

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

Abuse Case:

滥用案例：

As an attacker, I include malicious XML code to exploit vulnerable code, dependencies or integrations to extract data, execute a remote request from the server, scan internal systems, perform a denial-of-service attack (e.g. Billion Laughs attack), as well as execute other attacks.

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

A5:2017-Broken Access Control / A5:2017-访问控制损坏¶

Epic:

史诗：

Exploitation of access control is a core skill of attackers. Access control is detectable using manual means, or possibly through automation for the absence of access controls in certain frameworks.

利用访问控制是攻击者的核心技能。访问控制可以使用手动方式进行检测，也可以通过自动化来检测，因为某些框架中缺乏访问控制。

Abuse Case:

滥用案例：

As an attacker, I bypass access control checks by modifying the URL, internal application state, or the HTML page, or simply using a custom API attack tool.

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

Abuse Case:

滥用案例：

As an attacker, I manipulate the primary key and change it to access another's users record, allowing viewing or editing someone else's account.

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

Abuse Case:

滥用案例：

As an attacker, I manipulate sessions, access tokens, or other access controls in the application to act as a user without being logged in, or acting as an admin/privileged user when logged in as a user.

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

Abuse Case:

滥用案例：

As an attacker, I leverage metadata manipulation, such as replaying or tampering with a JSON Web Token (JWT) access control token or a cookie or hidden field manipulated to elevate privileges or abusing JWT invalidation.

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

Abuse Case:

滥用案例：

As an attacker, I exploit Cross-Origin Resource Sharing CORS misconfiguration allowing unauthorized API access.

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

Abuse Case:

滥用案例：

As an attacker, I force browsing to authenticated pages as an unauthenticated user or to privileged pages as a standard user.

作为攻击者，我强制以未经身份验证的用户身份浏览经过身份验证的页面，或以标准用户身份强制浏览特权页面。

Abuse Case:

滥用案例：

As an attacker, I access APIs with missing access controls for POST, PUT and DELETE.

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

Abuse Case:

滥用案例：

As an attacker, I target default crypto keys in use, weak crypto keys generated or re-used, or keys where rotation is missing.

作为攻击者，我的目标是使用中的默认加密密钥、生成或重复使用的弱加密密钥或缺少轮换的密钥。

Abuse Case:

滥用案例：

As an attacker, I find areas where the user agent (e.g. app, mail client) does not verify if the received server certificate is valid and perform attacks where I get unauthorized access to data.

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

A6:2017-Security Misconfiguration / A6:2017-安全配置错误¶

Epic:

史诗：

Attackers will often attempt to exploit unpatched flaws or access default accounts, unused pages, unprotected files and directories, etc to gain unauthorized access or knowledge of the system.

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

Abuse Case:

滥用案例：

As an attacker, I find and exploit missing appropriate security hardening configurations on any part of the application stack, or improperly configured permissions on cloud services.

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

Abuse Case:

滥用案例：

As an attacker, I find unnecessary features which are enabled or installed (e.g. unnecessary ports, services, pages, accounts, or privileges) and attack or exploit the weakness.

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

Abuse Case:

滥用案例：

As an attacker, I use default accounts and their passwords to access systems, interfaces, or perform actions on components which I should not be able to.

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

Abuse Case:

滥用案例：

As an attacker, I find areas of the application where error handling reveals stack traces or other overly informative error messages I can use for further exploitation.

作为攻击者，我发现应用程序的错误处理区域会显示堆栈跟踪或其他信息过多的错误消息，我可以将其用于进一步利用。

Abuse Case:

滥用案例：

As an attacker, I find areas where upgraded systems, latest security features are disabled or not configured securely.

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

Abuse Case:

滥用案例：

As an attacker, I find security settings in the application servers, application frameworks (e.g. Struts, Spring, ASP.NET), libraries, databases, etc. not set to secure values.

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

Abuse Case:

滥用案例：

As an attacker, I find the server does not send security headers or directives or are set to insecure values.

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

A7:2017-Cross-Site Scripting (XSS) / A7:2017-跨站脚本 (XSS)¶

Epic:

史诗：

XSS is the second most prevalent issue in the OWASP Top 10, and is found in around two-thirds of all applications.

XSS 是 OWASP Top 10 中第二个最普遍的问题，大约三分之二的应用程序中都存在 XSS。

Abuse Case:

滥用案例：

As an attacker, I perform reflected XSS where the application or API includes unvalidated and unescaped user input as part of HTML output. My successful attack can allow the attacker to execute arbitrary HTML and JavaScript in my victim's browser. Typically the victim will need to interact with some malicious link that points to an attacker-controlled page, such as malicious watering hole websites, advertisements, or similar.

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

Abuse Case:

滥用案例：

As an attacker, I perform stored XSS where the application or API stores unsanitized user input that is viewed at a later time by another user or an administrator.

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

Abuse Case:

滥用案例：

As an attacker, I perform DOM XSS where JavaScript frameworks, single-page applications, and APIs that dynamically include attacker-controllable data to a page is vulnerable to DOM XSS.

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

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

Epic:

史诗：

Exploitation of deserialization is somewhat difficult, as off-the-shelf exploits rarely work without changes or tweaks to the underlying exploit code.

反序列化的利用有些困难，因为如果不更改或调整底层利用代码，现成的利用很少会起作用。

Abuse Case:

滥用案例：

As an attacker, I find areas of the application and APIs where deserialization of hostile or tampered objects can be supplied. As a result, I can focus on an object and data structure related attacks where the attacker modifies application logic or achieves arbitrary remote code execution if there are classes available to the application that can change behavior during or after deserialization. Or I focus on data tampering attacks such as access-control-related attacks where existing data structures are used but the content is changed.

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

A9:2017-Using Components with Known Vulnerabilities / A9:2017-使用具有已知漏洞的组件¶

Epic:

史诗：

While it is easy to find already-written exploits for many known vulnerabilities, other vulnerabilities require concentrated effort to develop a custom exploit.

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

Abuse Case:

滥用案例：

As an attacker, I find common open source or closed source packages with weaknesses and perform attacks against vulnerabilities and exploits which are disclosed

作为攻击者，我发现常见的开源或闭源软件包存在弱点，并对公开的漏洞和漏洞进行攻击

A10:2017-Insufficient Logging & Monitoring / A10:2017-日志记录和监控不足¶

Epic:

史诗：

Exploitation of insufficient logging and monitoring is the bedrock of nearly every major incident. Attackers rely on the lack of monitoring and timely response to achieve their goals without being detected. In 2016, identifying a breach took an average of 191 days allowing substantial chance for damage to be inflicted.

伐木和监测不足是几乎所有重大事件的基础。攻击者依靠缺乏监控和及时响应来实现其目标而不被发现。 2016 年，识别漏洞平均需要 191 天](https://www-01.ibm.com/common/ssi/cgi-bin/ssialias?htmlfid=SEL03130WWEN)，造成损害的可能性很大。

Abuse Case:

滥用案例：

As an attacker, I attack an organization and the logs, monitoring systems, and teams do not see or respond to my attacks.

作为攻击者，我攻击一个组织，但日志、监控系统和团队看不到或响应我的攻击。

Sources of the schemas / 模式的来源¶

All figures were created using https://www.draw.io/ site and exported (as PNG image) for integration into this article.

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

All XML descriptor files for each schema are available below (using XML description, modification of the schema is possible using DRAW.IO site):

下面提供了每个模式的所有 XML 描述符文件（使用 XML 描述，可以使用 DRAW.IO 站点修改模式）：

Schemas descriptors archive) （模式描述符存档）

References / 参考¶

OWASP SAMM: Misuse/Abuse Testing
OWASP SAMM: Security Requirements) （OWASP SAMM：安全要求）