您正在查看 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 发布了 2017 年 Web 应用 10 大 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 和客户端密钥。其中有些将 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 支持。
- GenerateJWT 令牌（支持 HS256 和 RS256 签名）
- 验证 JWT 令牌
- 解码 JWT 令牌而不验证
A3:2017 - 敏感数据暴露
攻击者的目标是窃取信用卡信息、社会保障号、登录凭据、个人身份信息 (PII) 和税号等敏感数据，以实施身份盗用、金钱盗用、欺诈和其他犯罪行为。Web 应用需要实施静态加密和传输加密以及其他策略来确保敏感数据的安全。
TLS（传输层安全协议，其前身为 SSL）是在网络服务器和 Web 客户端（例如浏览器或应用）之间建立加密链接的标准安全技术。Apigee 支持单向 TLS 和双向 TLS。
通过使用虚拟主机配置可支持北向 TLS（连接到该 API 并充当服务器的客户端）。虚拟主机可以配置为单向或双向 TLS。
通过使用目标服务器配置，支持南向 TLS（作为连接到后端服务的客户端）。目标服务器可以配置为单向或双向 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 界面和管理 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（本地）的 Edge 客户必须自行应用产品补丁。
A7:2017 跨站脚本攻击 (XSS)
利用跨站脚本攻击 (XSS)，攻击者可以在用户的网络浏览器中执行脚本，以控制用户会话、操纵网站，或以其他方式对用户造成恶意影响。XSS 问题不一定与 API 相关，但 Apigee 提供了威胁防护政策，可用于防范 API 中的 XSS。将正则表达式与 RegularExpressionProtection 政策或 JavaScript 政策搭配使用，检查 JavaScript 和其他注入类攻击的载荷和参数值。
CORS 是所有浏览器强制执行的同源政策的常用解决方案之一，可以使用 AssignMessage 政策实现。
A8:2017 - 不安全的反序列化
攻击者可以将反序列化中的缺陷用于不同类型的攻击，例如重放、提权和注入。不安全的反序列化还会导致远程执行代码。
Apigee 不建议反序列化。但是，JSONThreatProtection 政策和 RegularExpressionProtection 政策有助于防范恶意 JSON 载荷。 JavaScript 政策还可用于扫描载荷中是否包含恶意内容。 缓存和其他政策可用于防范重放攻击。在基础架构级别，Apigee 平台还内置了安全措施，可以保护正在运行的进程。
A9:2017 - 使用存在已知漏洞的组件
由于框架、库和模块在运行时具有完整执行权限和 CRUD 访问权限，因此攻击者可以利用组件漏洞攻击系统。
Apigee 的常规产品版本可确保防范组件漏洞，尤其是在发现特定漏洞时。Apigee 公有云会自动修补，当本地补丁可供安装时，Apigee 会向 Private Cloud 客户发送通知。
A10:2017 - 日志记录和监控不足
如果您在系统中不能充分执行日志记录、监控和事件管理，攻击者可能会对数据和软件执行更深入、更长期的攻击。
Apigee 有多种方法来执行日志记录、监控、错误处理和审核日志记录。
日志记录
- 您可以使用 MessageLogging 政策将日志消息发送到 Splunk 或其他 Syslog 端点。
- API 分析数据可通过 Analytics API 提取，然后导入或导出到其他系统中。
- 在适用于私有云的 Edge 中，您可以使用 MessageLogging 政策写入本地日志文件。此外，还提供每个正在运行的组件的日志文件。
- JavaScript 政策可用于同步或异步向 REST 日志记录端点发送日志消息。
监控
- 使用 API Monitoring 界面或 API 定期监控 API 和后端并触发 alet。
- 使用运行状况监控定期监控目标服务器后端。
- Apigee 针对监控 Private Cloud 的 Edge 提供了建议。
- 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 重定向。