您正在查看 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 针对主要 REST OWASP 威胁推荐的政策/配置列表。
针对 2017 年 OWASP 十大漏洞的 Apigee 解决方案
在构建和保护 Web 应用时，存在许多安全问题。 OWASP 发布了 Web 应用的 2017 年 OWASP 十大安全威胁列表。虽然 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 密钥。在创建并批准与一个或多个 API 产品关联的开发者应用后，Apigee 会生成 API 密钥和 Secret。
“API 密钥”一词有时有不同的含义。在 Apigee 中，建立应用与产品之间的关系后，Apigee 会生成客户端 ID 和客户端 Secret。有些人会将 ID 和 Secret 都称为 API 密钥。有些人仅将客户端 ID 称为 API 密钥。在 Edge 界面中，您会看到“使用方密钥”和“使用方密文”。
在 VerifyAPIKey 政策中，仅会验证客户端 ID（即“使用方密钥”）。开发者在向 Apigee 注册应用并将应用与 API 产品相关联后，会收到使用方密钥。开发者在应用对 API 产品中捆绑的 API 代理进行的调用中添加使用方密钥。
Apigee 还支持从外部来源导入现有 API 密钥。
对于 OAuth 授权类型，需要同时使用客户端 ID 和 Secret。
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 支持。
- GenerateJWT 令牌（支持 HS256 和 RS256 签名）
- ValidateJWT 令牌
- 解码 JWT 令牌，但不进行验证
A3:2017 - 敏感数据泄露
攻击者会以信用卡详细信息、社会保障号、登录凭据、个人身份信息 (PII) 和纳税人识别号等敏感数据为目标，从而实施身份盗用、盗窃、欺诈和其他犯罪行为。Web 应用需要实现静态数据和传输中数据的加密以及其他策略，以确保敏感数据受到保护。
TLS（传输层安全协议，其前身是 SSL）是一种标准安全技术，用于在网络服务器与网络客户端（例如浏览器或应用）之间建立加密链接。Apigee 同时支持单向和双向 TLS。
通过使用虚拟主机配置，支持北向 TLS（客户端连接到充当服务器的 API）。虚拟主机可以配置为使用单向或双向 TLS。
通过使用目标服务器配置，支持南向 TLS（Apigee 作为连接到后端服务的客户端）。目标服务器可以配置为单向或双向 TLS。
Apigee 支持许多 TLS 配置选项。
强制执行双向 TLS 可确保客户端使用已加入 Apigee 的证书。OWASP 还提供了 TLS 最佳实践。
在 Apigee Hybrid 中，TLS 可通过主机别名（与虚拟主机类似的概念）在入站点使用。
以下是关于保护敏感数据的指南：
- 使用支持单向和双向 TLS 的平台，以便在协议级进行保护。
- 使用分配消息政策和 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 和 Secret。
- Apigee 可以与任何身份提供方集成以执行 OAuth。
- Apigee 可以生成 JWT 令牌或使用其他方法将用户身份发送到目标服务。 目标服务可以使用该身份根据需要限制对服务和数据的访问。
A6:2017-安全配置错误
安全配置错误很容易被忽略，这通常是因为管理员和开发者错误地认为他们使用的系统本身就是安全的。安全配置错误可能以多种不同的方式发生，例如信任默认配置或进行可能不安全的部分配置、让错误消息包含敏感细节、在没有适当安全控制的情况下将数据存储在云中、错误配置 HTTP 标头等。Apigee 平台提供了多种机制，可让您控制、管理和监控安全配置，包括 可重复使用的共享流程。
借助共享流，API 开发者可以将政策和资源组合成一个可重复使用的组。 通过将可重复使用的功能集中到一个地方，共享流有助于确保一致性、缩短开发时间以及更轻松地管理代码。您可以在各个 API 代理中添加共享流，也可以更进一步，将共享流放入流钩子，以便为部署在与共享流相同环境中的每个 API 代理自动执行共享流逻辑。
Apigee 产品版本可确保防范存在漏洞的库。 如果发现新漏洞，Apigee 可能会发布其他补丁或更新。 Edge Public Cloud 会自动打补丁。Edge for Private Cloud（本地）客户必须自行应用产品补丁。
A7:2017-Cross-Site Scripting (XSS)
跨站脚本攻击 (XSS) 允许攻击者在用户 Web 浏览器中执行脚本来控制用户会话、操纵网站或以其他方式恶意影响用户。XSS 问题不一定与 API 相关，但 Apigee 提供可用于防范 API 中发生 XSS 的威胁保护措施政策。将正则表达式与 RegularExpressionProtection 政策或 JavaScript 政策搭配使用，可检查 JavaScript 和其他注入类型攻击的载荷和参数值。
CORS 是通常针对所有浏览器强制执行的同源政策实现的解决方案之一，AssignMessage 政策可用于实现 CORS。
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 获取此日志。
Apigee 针对 2013 年 OWASP 漏洞的解决方案
在 OWASP 更新 2017 年列表时，2013 年列表中的某些漏洞被遗漏。这些漏洞仍然是有效的威胁。以下部分介绍了如何使用 Apigee 处理这些威胁。
A8:2013 - 跨站请求伪造 (CSRF)
通过跨网站伪造请求，攻击者可以通过 HTTP 将用户的身份验证详细信息、会话 Cookie 和其他数据转发到易受攻击的 Web 应用，诱骗 Web 应用认为这些请求是来自用户的合法请求。
准则：
- 这更像是浏览器问题，而不是 API 产品问题。您可以使用 OpenID Connect、OAuth 和其他技术来解决此漏洞。
- 考虑使用 HMAC、状态、哈希、Nonce 或 PKCE 技术来防范伪造和重放攻击。
A10:2013 - 未经验证的重定向和转发
如果 Web 应用执行重定向，但未验证重定向是否会将用户发送到预期的可信网站，攻击者便可以将用户发送到恶意目的地，以执行钓鱼式攻击、恶意软件执行攻击和其他攻击。
准则：
- 使用 OAuth 并在每次请求时强制执行验证。
- 通过在 API 代理逻辑中检查响应代码并妥善处理重定向，防止意外的 302 重定向。