您正在查看 Apigee Edge 文档。
前往 Apigee X 文档。 信息
概览
API 生态系统会遭受来自外部和内部客户端的各种攻击。 提供和使用 API 为服务提供商带来了巨大的机遇，但也带来了一些安全风险。开发者在创建和使用 API 时，必须了解这些挑战并加以应对。
OWASP 是一个开放社区，致力于帮助组织开发、购买和维护可信的应用和 API。通过 OWASP API 安全项目，OWASP 发布了 Web 应用和 REST API 最严重的安全风险，并提供了解决这些风险的建议。
借助 Apigee，API 代理层可以在后端系统处理来自客户端的格式错误的 API 请求之前检测、阻止和报告这些请求，从而降低风险并保护您的服务。格式错误的请求可能包含构成 HTTP 应用级协议的任何组件：
- 网址
- 标头
- 路径
- 载荷
格式错误的 API 请求可能来自外部开发者、内部开发者或恶意机器人开发的已知或未知客户端。这些类型的请求构成了 OWASP 威胁的大部分，但底层 API 代理层还有其他组件可以缓解风险，例如数据遮盖、日志记录、管理等。
借助 Apigee 的智能 API 管理平台，您可以采用以消费为中心的方法来设计 API 并将其与后端系统连接，从而无缝解决 OWASP API 安全漏洞中的头号问题。以下是 Apigee 针对 OWASP 前 10 大 REST 威胁推荐的政策/配置。
Apigee 解决方案 - 2017 年 OWASP 排名前 10
在构建和保护 Web 应用时，存在许多安全问题。 OWASP 发布了 Web 应用的十大 OWASP 安全威胁 - 2017 年列表。虽然 Web 应用包含许多部分，但大多数现代 Web 应用都严重依赖 REST API。Apigee 并非旨在满足 Web 应用的所有安全需求，但它可以在保护 REST API 方面发挥关键作用。 以下是 OWASP 提出的主要安全威胁，并说明了如何使用 Apigee 来帮助应对这些威胁。
A1:2017 - 注入
为防范不可信的数据注入（例如 SQL、NoSQL、LDAP 和 JavaScript），这些注入可能会导致执行意外的命令或未经授权的数据访问权限，Apigee 提供多种输入验证政策，以便先验证客户端提供的值是否符合预期值，然后才允许进一步处理。Apigee Edge 充当传入 API 请求的服务器，用于进行检查以确保载荷结构在可接受的范围内，这称为限制检查。您可以配置 API 代理，以便输入验证例程转换输入，从而移除有风险的字符序列，然后将它们替换为安全值。
借助 Apigee 平台，您可以通过下列几种方法来验证输入：
- JSONThreatProtection 可检查 JSON 载荷是否存在威胁。
- XMLThreatProtection 可检查 XML 载荷是否存在威胁。
- 可以使用 JavaScript 执行参数验证。
- 可以使用 JavaScript 执行标头验证。
- 可以使用 RegularExpressionProtection 政策处理 SQLCodeInjection。
验证内容类型：
- 请求 - 在代理流程中使用条件逻辑来检查 Content-Type。使用 AssignMessage 政策或 RaiseFault 政策返回自定义错误消息。
- 响应 - 在代理流程中使用条件逻辑来验证 Content-Type。使用 AssignMessage 政策设置 Content-Type 标头，或使用 AssignMessage 或 RaiseFault 政策返回自定义错误消息。
A2:2017 - 身份验证和会话管理中断
攻击者可以利用应用中的实现缺陷来访问密码、会话令牌和密钥，从而冒充其他用户。这更像是一个实现问题，而不是产品问题。Apigee 提供 VerifyApiKey、OAuth 和 JSON Web 令牌 (JWT) 政策，帮助防范此漏洞。
API 密钥验证
API 密钥验证是一种最简单的基于应用的安全形式，您可以为 API 配置密钥验证。客户端应用只需随其请求提供 API 密钥，然后 Apigee Edge 会通过附加到 API 代理的政策来检查该 API 密钥对于所请求的资源而言是否处于已批准状态。
Apigee 支持生成和验证 API 密钥。当开发者应用创建并获得批准后，Apigee 会生成一个 API 密钥和 Secret，它们与一个或多个 API 产品相关联。
“API 密钥”一词有时可能具有不同的含义。在 Apigee 中，当应用与产品建立关联时，Apigee 会生成客户端 ID 和客户端密钥。有些人将 ID 和 Secret 都称为 API 密钥。有些人将客户端 ID 称为 API 密钥。在 Edge 界面中，您会看到“使用方密钥”和“使用方密文”。
在 VerifyAPIKey 政策中，系统只会验证客户端 ID 或“使用方密钥”。开发者在 Apigee 中注册应用并将应用与 API 产品相关联时，会收到一个使用方密钥。开发者在应用对 API 产品中捆绑的 API 代理进行的调用中包含使用方密钥。
Apigee 还支持从外部来源导入现有 API 密钥。
对于 OAuth 授权类型，客户端 ID 和密钥都会使用。
OAuth 2.0
OAuth 2.0 授权框架使第三方应用能够以资源所有者的名义通过协调资源所有者与 HTTP 服务之间的审批互动来获得对 HTTP 服务的有限访问权限，或者允许第三方应用自行获得访问权限。
借助 Apigee 的 OAuth 2.0 政策，您可以实现和自定义四种 OAuth 2.0 授权类型。 可以使用 OAuthv2 政策强制执行 OAuth 访问令牌。使用方必须已注册，并且已获批的应用已授予其对 API 的访问权限。作为回报，他们将收到 API 客户端 ID 和客户端密钥。使用方必须通过其中一种 OAuth 授权来完成身份验证，从而获得不透明的访问令牌。此令牌可用于控制对 API 的访问权限。
JWT
JSON Web 令牌 (JWT) 通常用于在连接的应用之间共享声明或断言。Apigee 使用三个政策来提供 JWT 支持。
- 生成 JWT 令牌（支持 HS256 和 RS256 签名）
- 验证 JWT 令牌
- 解码 JWT 令牌，而不进行验证
A3:2017 - 敏感数据泄露
攻击者会窃取信用卡详细信息、社会保障号、登录凭据、个人身份信息 (PII) 和纳税人识别号等敏感数据，以实施身份盗窃、盗窃钱财、欺诈和其他犯罪行为。Web 应用需要实施静态加密和传输中加密，并采取其他策略来确保敏感数据受到保护。
TLS（传输层安全协议，其前身是 SSL）是一种标准的安全技术，用于在 Web 服务器与 Web 客户端（例如浏览器或应用）之间建立加密链接。Apigee 支持单向和双向 TLS。
通过使用虚拟主机配置，可以支持北向 TLS（客户端连接到充当服务器的 API）。虚拟主机可以配置为单向或双向 TLS。
通过使用目标服务器配置，可以支持南向 TLS（Apigee 作为客户端连接到后端服务）。您可以为目标服务器配置单向或双向 TLS。
Apigee 支持许多 TLS 配置选项。
双向 TLS 强制执行可确保客户端使用的是已加入 Apigee 的证书。OWASP 还提供 TLS 最佳实践。
在 Apigee Hybrid 中，TLS 可通过主机别名在入站流量中提供，主机别名与虚拟主机类似。
以下是保护敏感数据的指南：
- 使用支持单向和双向 TLS 的平台，以便在协议级进行保护。
- 使用 AssignMessage 政策和 JavaScript 政策等政策来移除敏感数据以免返回给客户端。
- 使用标准的 OAuth 技术，并考虑添加 HMAC、哈希、状态、Nonce、PKCE 或其他技术，以提高每个请求的身份验证级别。
- 使用数据遮盖设置在 Edge Trace 工具中遮盖敏感数据。
- 请注意，不要在缓存中存储任何敏感数据（或对存储在缓存中的敏感数据进行加密）。在 Edge 中，您可以对键值对映射中的静态敏感数据进行加密。
A4:2017 - XML 外部实体
处理 XML 的系统或应用需要处理 XML 中的“外部实体引用”，即对文件或数据的引用，这些文件或数据会在 XML 处理期间被实际数据替换。如果应用或 XML 处理器过旧或实现不佳，攻击者可以入侵数据并利用这些数据窃取信息或对系统发起各种攻击，例如拒绝服务攻击。
通过 Apigee 的 ExtractVariables 政策，您可以从请求或响应中提取内容，然后将该内容分配给变量。您可以提取消息的任何部分，包括标头、URI 路径、JSON/XML 载荷、表单参数和查询参数。该政策的工作原理是对消息内容应用文本模式，在找到匹配项时，使用指定的消息内容设置变量。
Apigee 平台内置了一个 XML 解析器，它使用 XPath 来提取数据。它还具有一项 XMLThreatProtection 政策，可防范恶意 XML 载荷。
A5:2017 - 访问权限控制中断
用户登录并获得系统访问权限后，需要实施适当的授权控制措施，以便用户只能查看和执行他们有权查看和执行的操作。如果没有严格的访问权限控制，攻击者可能会查看未经授权的敏感数据，或恶意操纵数据和系统行为。
Apigee 支持采用分层方法来实施访问权限控制，以防止作恶方进行未经授权的更改或访问系统。
Edge 界面访问权限控制
- 通过您公司的身份提供方配置单点登录。
- 配置基于角色的访问控制 (RBAC)，仅允许用户访问所需的功能和配置。
- 借助“团队”功能，您可以进一步限制对代理、产品和应用的访问权限。
- 配置数据遮盖以向用户隐藏敏感数据。
- 创建加密的键值对映射，以存储在 Edge 界面和 Management API 调用中遮盖的敏感键值对。
Apigee 开发者门户的访问权限控制
- 通过您公司的身份提供方配置单点登录。
- 配置基于角色的访问控制 (RBAC)，仅允许用户访问基于 Drupal 的开发者门户上所需的功能和配置。
- 配置开发者门户，根据用户角色显示特定的 API 产品。
- 配置门户，根据用户角色显示或隐藏内容。
Apigee 运行时 API 访问权限控制
- 可以通过 API 密钥、OAuth 令牌、OAuth 范围、证书和其他技术来强制执行 API 访问权限。
- API 提供商通过定义 API 产品来配置哪些资源可用。访问权限可通过界面、Management API 或开发者门户手动授予。当开发者的应用获得对 API 产品的访问权限时，他们会收到在身份验证过程中使用的客户端 ID 和密钥。
- Apigee 可以与任何身份提供方集成以执行 OAuth。
- Apigee 可以生成 JWT 令牌或使用其他技术将用户身份信息发送到目标服务。 目标服务可以使用该身份来限制对服务和数据的访问权限（如果需要）。
A6:2017-安全配置错误
安全配置错误很容易被忽略，这通常是因为管理员和开发者错误地认为他们使用的系统本身就是安全的。安全配置错误可能以多种不同的方式发生，例如信任默认配置或进行可能不安全的部分配置、让错误消息包含敏感细节、在没有适当安全控制的情况下将数据存储在云中、错误配置 HTTP 标头等。Apigee 平台提供多种机制，让您能够控制、管理和监控安全配置，包括 可重复使用的共享流。
借助共享流，API 开发者可以将政策和资源组合成一个可重复使用的组。 通过将可重复使用的功能集中到一个地方，共享流有助于确保一致性、缩短开发时间以及更轻松地管理代码。您可以在各个 API 代理中添加共享流，也可以更进一步，将共享流放入流钩子，以便为部署在与共享流相同的环境中的每个 API 代理自动执行共享流逻辑。
Apigee 产品版本可确保防范存在漏洞的库。 如果发现新的漏洞，Apigee 可能会发布其他补丁或更新。 边缘公有云会自动进行修补。Edge Private Cloud（本地）客户必须自行应用产品补丁。
A7:2017-跨站脚本攻击 (XSS)
跨站脚本攻击 (XSS) 允许攻击者在用户 Web 浏览器中执行脚本来控制用户会话、操纵网站或以其他方式恶意影响用户。XSS 问题不一定与 API 相关，但 Apigee 提供了一些威胁防护政策，可用于防范 API 中发生 XSS。将正则表达式与 RegularExpressionProtection 政策或 JavaScript 政策搭配使用，可检查 JavaScript 和其他注入类型攻击的载荷和参数值。
CORS 是所有浏览器强制执行的同源政策的一种常用解决方案，可以使用 AssignMessage 政策来实现。
A8:2017 - 不安全的反序列化
攻击者可以使用反序列化中的缺陷进行不同类型的攻击，例如重放、提权和注入攻击。不安全的反序列化可能还会导致远程代码执行攻击。
Apigee 不建议进行反序列化。不过，JSONThreatProtection 政策和 RegularExpressionProtection 政策有助于防范恶意 JSON 载荷。 JavaScript 政策还可用于扫描载荷中的恶意内容。 缓存和其他政策可用于防范重放攻击。在基础设施层面，Apigee 平台还内置了安全护栏来保护正在运行的进程。
A9:2017 - 使用具有已知漏洞的组件
由于框架、库和模块以完全执行和 CRUD 访问权限运行，攻击者可以利用组件漏洞来攻击系统。
Apigee 的常规产品发布可确保防范组件漏洞，尤其是在发现特定漏洞时。Apigee 公有云会自动进行修补，当本地补丁可供安装时，Apigee 会通知 Edge for Private Cloud 客户。
A10:2017 - 日志记录和监控权限不足
如果您在系统中未妥善执行日志记录、监控和突发事件管理，则攻击者可能会对数据和软件执行更深入和更长时间的攻击。
Apigee 提供了多种方法可供您执行日志记录、监控、错误处理和审核日志记录。
日志记录
- 您可以使用 MessageLogging 政策将日志消息发送到 Splunk 或其他 syslog 端点。
- API 分析数据可通过 Analytics API 拉取，并导入或导出到其他系统中。
- 在 Edge for Private Cloud 中，您可以使用 MessageLogging 政策写入本地日志文件。 还提供每个正在运行的组件的日志文件。
- JavaScript 政策可用于以同步或异步方式将日志消息发送到 REST 日志记录端点。
监控
- 使用 API Monitoring 界面或 API 定期监控 API 和后端并触发提醒。
- 使用健康状况监控功能定期监控目标服务器后端。
- Apigee 提供了用于监控 Edge for Private Cloud 的建议。
- Apigee 还提供了 最佳实践，供团队用来监控您的 API 项目。
错误处理
Apigee 为 API 代理提供了功能强大的通用故障处理机制。与 Java 程序捕获异常的方式类似，API 代理可以捕获故障并确定如何向客户端返回适当的响应。 借助 Apigee 的自定义故障处理，您可以在发生错误时添加消息日志记录等功能。
审核日志
Apigee 平台会保留审核日志，用于跟踪 API 代理、产品和组织历史记录的变化。您可以通过界面或 Audits API 获取此日志。
针对 2013 年 OWASP 漏洞的 Apigee 解决方案
OWASP 在 2017 年更新了其列表，2013 年列表中的一些漏洞被排除在外。不过，这些漏洞仍然是有效的威胁。以下部分介绍了如何使用 Apigee 处理这些威胁。
A8:2013 - 跨站请求伪造 (CSRF)
借助跨站伪造请求，攻击者可以通过 HTTP 将用户的身份验证详细信息、会话 Cookie 和其他数据转发给易受攻击的 Web 应用，从而欺骗该 Web 应用，使其误以为这些请求是用户发出的合法请求。
准则：
- 这更像是一个浏览器问题，而不是 API 产品问题。您可以使用 OpenID Connect、OAuth 和其他技术来解决此漏洞。
- 考虑使用 HMAC、状态、哈希、Nonce 或 PKCE 技术来防止伪造和重放攻击。
A10:2013 - 未经验证的重定向和转发
如果 Web 应用执行重定向，但未验证重定向是否将用户发送到可信的预期网站，攻击者可能会将用户发送到恶意目的地，以执行钓鱼式攻击、恶意软件执行和其他攻击。
准则：
- 使用 OAuth 并在每次请求时强制执行验证。
- 通过在 API 代理逻辑中检查响应代码并适当处理重定向，防止出现意外的 302 重定向。