API接口安全思考和最佳实践_api安全最佳实践

一、API安全概述 

        应用程序编程接口 (API) 允许软件应用程序相互交互。它是现代软件模式的基本组成部分，例如微服务架构。

        API 安全是保护 API 免受攻击的过程。由于 API 非常常用，而且它们可以访问敏感的软件功能和数据，因此它们正成为攻击者的主要目标。 

        API 安全性是现代 Web 应用程序安全性的关键组成部分。API 可能存在身份验证和授权损坏、缺乏速率限制和代码注入等漏洞。组织必须定期测试 API 以识别漏洞，并使用安全最佳实践解决这些漏洞。本文介绍了 API 安全测试的几种方法和工具，以及可以帮助您保护 API 的一系列最佳实践。

二、面临的威胁 

        OWASP一般指开放式Web应用程序安全项目。 开放式Web应用程序安全项目（OWASP，Open Web Application Security Project）是一个组织，它提供有关计算机和互联网应用程序的公正、实际、有成本效益的信息。其目的是协助个人、企业和机构来发现和使用可信赖软件。

        近年来与 API 相关的安全威胁的增加促使开放 Web 应用程序安全项目 (OWASP) 发布了API Security Top 10，这有助于提高人们对影响组织的最严重的 API 安全问题的认识。

        这些问题是：

        损坏的对象级授权

        API 通常会公开处理对象标识符的端点。任何接受用户输入并使用它来访问数据源的函数都可能产生级别访问控制问题，从而扩大攻击面。您应该对所有此类功能执行对象级授权检查。

        用户身份验证失败

        攻击者经常利用错误应用的身份验证机制。他们可能会破坏身份验证令牌或利用实现中的缺陷以一次性或永久地冒充另一个用户。如果系统识别客户端/用户的能力受到损害，那么整个 API 的安全性也会受到损害。

        过度数据暴露

        开发人员通常依赖客户端在将数据显示给用户之前对其进行过滤。这可能会产生严重的安全问题——数据必须始终在服务器端进行过滤，并且只有相关信息才应该传送到客户端。

        缺乏资源和速率限制

        API 通常不限制客户端/用户可以请求的资源的数量或大小。这会影响 API 服务器的性能，导致拒绝服务 (DoS)，并暴露身份验证漏洞，从而启用暴力攻击。

        损坏的功能级授权

        授权缺陷通常是由于访问控制策略过于复杂，或者常规功能和管理功能之间没有明确的分离。攻击者可以利用这些漏洞来访问用户的资源或执行管理功能。

        批量分配

        批量分配通常是由于客户端提供的数据（即 JSON）绑定到基于许可列表的数据模型，而没有适当过滤属性。攻击者可以通过多种方式修改对象属性——他们可以探索 API 端点、阅读文档、猜测对象属性或通过请求有效负载提供其他属性。

        安全配置错误

        安全错误配置通常是由于默认配置不足、临时或不完整配置、错误配置的 HTTP 标头或不适当的 HTTP 方法、限制性不足的跨域资源共享 (CORS)、开放式云存储或包含敏感信息的错误消息。

        注入

        注入缺陷（包括 SQL 注入、NoSQL 注入和命令注入）涉及通过命令或查询从不受信任的来源发送到解释器的数据。攻击者可以发送恶意数据来欺骗解释器执行危险命令，或者允许攻击者在没有必要授权的情况下访问数据。

        资产管理不当

        与传统的 Web 应用程序相比，API 通常会暴露更多端点，因此需要结构化的最新文档。暴露的调试端点和弃用的 API 版本等问题可能会增加攻击面。这可以通过创建已部署 API 版本和正确配置主机的清单来缓解。

        记录和监控不足

        攻击者可以利用不充分的日志记录和监控，以及无效或缺乏事件响应集成，在系统中持续存在，加深他们的控制并提取或破坏更多数据。检测持续性威胁通常需要 200 多天，而漏洞通常是由外部方发现的，这凸显了有效 API 监控的重要性。

三、开源API测试工具

1、Postman

        Postman 是一个 API 开发平台。

        其主要特点包括：

        自动化手动 API 测试 
        将测试集成到 CI/CD 管道中
        模拟 API 端点和响应的预期行为
        检查 API 性能和响应时间
        通过内置版本控制实现开发人员之间的协作

2、Swagger

        Swagger 是一个开源工具包，可以帮助您创建 RESTful API。

        它支持两种 API 开发风格：

        自上而下的 API 设计，让您在 Swagger 中构建 API，然后根据规范生成代码

        自下而上的 API 设计，其中 Swagger 采用现有代码并生成有关 API 操作、参数和输出的文档

3、JMeter

        JMeter 是一个负载测试工具，也可以用于安全测试。

        主要特点包括：

        输入 CSV 文件并使用它们进行负载测试——这使您可以使用不同的值执行测试，以模拟危险场景和网络攻击。
        使用 Jenkins 将 API 测试嵌入到构建过程中
        高级性能测试，具有回放测试结果的能力

4、SoapUI

        Soap UI 是一种流行的 API 功能测试工具。

        其主要特点包括：

        一个大型功能测试元素库，可让您自动化 API 测试
        完全可定制，提供源代码，以便您构建自己的功能
        轻松拖放界面以创建测试
        允许您重用现有的负载测试或安全扫描进行功能测试
        在 pro 包中，允许您执行数据驱动测试，模拟用户如何使用电子表格或数据库使用 API

5、Karate

        Karate DSL 是一种使用行为驱动开发 (BDD) 方法的 Java API 测试工具。

        其主要特点包括：

        使用现成的步骤定义为 API 编写 BDD
        生成标准 Java 报告 
        不需要 Java 知识即可为基于 Java 的 API 编写测试
        启用多线程执行
        支持在暂存和生产之间切换配置

6、Fiddler

        Fiddler 是一个监视和重放 HTTP 请求的工具，具有适用于 .NET、Java、Ruby 和其他流行框架的 API 测试扩展。

        其主要特点包括：

        调试来自任何类型客户端的请求，包括 Windows、MacO、Linux 和移动设备
        测试客户端-服务器通信中的 cookie、缓存和标头
        提供方便的 UI 用于对 API 请求进行分组和组织
        无需更改代码即可创建模拟请求和响应

四、最佳实践

1、始终使用网关

        我们的第一个建议是始终将您的 API 放在网关后面。API 网关集中了流量特性，并将它们应用到到达 API 的每个请求中。这些功能可能与安全相关，例如速率限制、阻止恶意客户端和适当的日志记录。或者，它们可能更实用且与业务相关，例如路径和标题重写、收集业务指标等。

        没有这些控制很容易导致严重的安全威胁。如果没有网关，API 提供者将不得不用这些功能一个接一个地加强每个端点。API 网关简化了添加或修复这些功能的过程。市场上有大量的API Gateway产品可以实现对应功能。

2、始终使用中央 OAuth 服务器

        接下来，不要让您的 API 或网关发出访问或刷新令牌。集中式 OAuth 服务器应始终发布此类令牌。颁发令牌需要许多复杂的过程：验证客户端、验证用户、授权客户端、签署令牌等操作。所有这些功能都需要访问不同的数据，例如客户端信息或首选身份验证机制。此外，如果许多实体发行和签署令牌，管理用于签署已发行密钥的所有凭证变得越来越具有挑战性。只有一个实体可以安全地处理这些过程——OAuth 服务器。

3、仅在内部使用 JSON Web 令牌

        当涉及 API 时，使用 JWT 作为访问和刷新令牌是一种很好的做法。接收 JWT 的服务可以利用声明信息做出明智的业务决策：是否允许调用者访问此资源？调用者可以检索哪些数据？

        但是，当令牌在您的基础设施之外暴露给第三方客户端时，您应该使用不透明令牌而不是 JWT。JWT 中的信息可供所有人使用并且易于解码。如果 JWT 数据是公开的，隐私就会成为一个问题。因此，您必须确保没有敏感数据最终出现在 JWT 的声明中。但是，如果您与第三方客户端共享 JWT，它们很可能会根据 JWT 中的数据启动。更改 JWT 中的声明可能会导致重大更改，需要在所有第三方客户端中进行昂贵的实施升级。        

        如果您想在外部使用不透明令牌，但又想在内部通信中从使用JWT，您可以使用以下两种方法之一：幻象令牌方法或者拆分令牌方法. 两者都涉及将不透明令牌转换为 JWT 的过程中的 API 网关。

（1）幻象令牌方法

        Phantom Token Approach 是一种用于保护 API 和微服务的规范性模式，它结合了不透明令牌的安全性和 JWT 的便利性。这个想法是有一对按引用和按值标记。可以在按引用等效项（不透明令牌）的帮助下获得按值令牌 (JWT)。客户端不知道 JWT，因此我们将令牌称为 Phantom 令牌。

        当客户端请求令牌时，令牌服务会返回一个引用令牌。该模式不是让 API 和微服务调用令牌服务来解析每个请求的引用令牌，而是利用 API 网关、反向代理或通常放置在客户端和 API 之间的任何其他中间件。通过这种方式，API 和微服务可以从 JWT 中受益，而无需向客户端公开任何数据，因为客户端只会检索不透明的令牌。

 （2）拆分令牌方法

        Split Token 方法与 Phantom Token 方法基于相同的主体——客户端仍然获得一个不透明的令牌，而 API 获得一个 JWT。但是在这种方法中，API 网关不需要将不透明的令牌交换为 JWT。更重要的是，JWT 并非简单地整体缓存在 API 网关中，这有助于提高安全性。

        当 Token Service 为客户端颁发令牌时，它将 JWT 拆分为两部分：

        JWT 的签名

        JWT 的头部和主体

        然后，它将 JWT 的签名部分发送回客户端，用作不透明令牌。同时，令牌服务对签名部分进行哈希处理，并将哈希与 JWT 的第二部分（头部和主体）一起发送到 API 网关。然后网关使用散列签名作为缓存的密钥来缓存令牌。只要令牌的到期时间，该值就会被缓存。

        当客户端发送请求时，API Gateway 获取客户端发送的签名部分，对其进行哈希处理并在其缓存中查找。然后它可以粘回令牌——头部、正文和签名，并将其转发给任何处理请求的 API 服务。因此，API 获得了一个完整的 JWT，可以根据需要进行反序列化和使用。

4、使用范围进行粗粒度访问控制

        OAuth 范围限制访问令牌的功能。如果被盗的客户端凭据范围有限，攻击者的权力就会小得多。因此，您应该始终发行功能有限的令牌。可以在 API 网关上验证令牌范围，以限制到达您的 API 的恶意流量。您应该使用 Scopes 来实现粗粒度的访问控制。此控制可以包括检查具有给定访问令牌的请求是否可以查询给定资源或验证客户端是否可以使用给定 Content-Type。

5. 在 API 级别使用声明进行细粒度访问控制

        您应该始终在 API 级别实现细粒度的访问控制。这种访问控制的架构应该使得即使恶意请求通过网关，API 仍然会拒绝它。这种做法可以防止攻击者绕过网关的情况。

        API 应该验证请求是否可以到达给定的端点。它还应该检查调用者是否拥有数据的权限，以及根据调用者的身份（对于客户端和用户）可以返回哪些信息。OWASP 将损坏的访问控制列为十大 API 安全漏洞之一，因此值得记住这一点。

6、采用零信任理念

        保持神秘。对于内部或外部沟通，任何事情都不应一目了然。加密会将您的信息转换为代码。这将使敏感数据更难落入坏人之手。

        您和您的合作伙伴应该使用 TLS（SSL 的后续版本）加密所有交换，无论是单向加密（标准单向 TLS）还是更好的相互加密（双向 TLS）。

        使用最新的 TLS 版本来阻止使用最弱的密码套件。

        零信任不仅仅是一个流行词——你的 API 应该限制对传入流量的信任。时期。建立零信任的第一步是对所有 API 流量使用 HTTPS。如果可能，请在内部使用 HTTPS，以便无法嗅探服务之间的流量。

        您的服务应始终验证传入的 JWT，即使它们是由网关从不透明令牌转换而来的。这再次有助于缓解请求设法绕过您的网关的情况，从而防止恶意行为者在您的公司或基础设施内部进行操作。

7、为 JWT 验证创建或重用库

        正确的 JWT 验证对于 API 的安全性至关重要。然而，如果每个团队都实施自己的 JWT 验证解决方案，您可能会增加整个系统的漏洞。错误更常见，并且很难修复错误。

        相反，为 JWT 验证创建一个公司范围的解决方案，最好基于市场上可用的库并根据您的 API 需求量身定制。标准化公司范围的 JWT 验证流程将有助于确保所有端点的安全级别相同。出现问题时，团队可以更快地解决问题。对于 JWT 验证等安全敏感任务，快速解决威胁非常重要。

8、不要混合认证方法

        不要混合使用相同资源的身份验证方法。身份验证方法可以具有不同的安全级别，例如基本身份验证和多重身份验证。如果您有一个以较高信任级别保护的资源，例如具有有限范围的 JWT，但允许以较低信任级别访问，这可能会导致 API 滥用。在某些情况下，这可能是一个重大的安全风险。

9、保护所有 API

        不要让您的任何 API 不受保护。即使是内部 API 也应该实施保护。这样，您就可以确保 API 免受来自组织内部的任何威胁。

        API 通常只为内部使用而创建，并在稍后向公众提供。在这种情况下，往往会忽略适当的 API 安全性。当对外发布时，API 容易受到攻击。

        请记住，不建议使用默默无闻的安全性。仅仅因为您为端点或 Content-Type 创建了一个复杂的名称并不意味着 API 是安全的。有人找到端点并滥用它只是时间问题。

10、为网络内的内部客户端发布 JWT

        如果您的内部客户端仅在您的网络内运行，您可以让 OAuth 服务器为此类客户端发出 JWT，而不是不透明的令牌。这将避免不必要的令牌翻译。但是，您应该仅在 JWT 不离开您的网络时应用此策略。如果您有外部客户端，或者如果令牌在外部使用，您应该将它们隐藏在不透明令牌后面，如前所述。

11、使用 JSON Web 密钥集进行密钥分发

        要验证 JWT 的完整性，API 必须访问公钥。您可以通过多种方式完成此操作：您可以硬编码键的值或在服务启动时查询某个端点并缓存结果。

        推荐的方法是从 OAuth 服务器公开的 JWKS 端点获取密钥。API 应缓存下载的密钥以限制不必要的流量，但应在找到不知道的签名密钥时再次查询 JWKS 端点。

        这允许简单的密钥轮换，OAuth 服务器可以按需处理，而不会妨碍 API 服务。使用密钥集代替密钥还允许客户端无缝密钥轮换。只要旧公钥是密钥集的一部分，OAuth 服务器就可以开始发布使用新密钥签名的新令牌并验证现有令牌。

12、始终审核

        从安全和设计的角度来看，保持 API 的高标准并非易事。因此，请考虑在不同的人群之间划分职责，并让其他团队审核您的 API。

        有不同的方法来设置对 API 的治理。您可以有一个专门的 API 专家团队审查设计和安全方面，或者创建一个从不同组中挑选的 API 专家公会来提供指导。无论您如何组织治理，请确保您始终有额外的眼睛检查您的 API。

13、使用服务网格

        与 API 网关一样，服务网格技术在将请求从一个服务路由到下一个服务时应用不同的管理和控制层。服务网格优化了这些移动部件协同工作的方式，包括正确的身份验证、访问控制和其他安全措施。

        随着微服务使用的增加，服务网格变得尤为重要。API 管理正在转向服务通信层，服务网格可以为具有多个 API 的大型部署提供自动化和安全性。

14、使用速率限制和节流

        随着 API 变得流行，它们对攻击者变得更有价值。API 现在是拒绝服务 (DoS) 攻击的主要目标。对 API 调用的方法和频率设置速率限制，以防止 DoS 攻击，并防止可能影响性能和安全的峰值流量。速率限制还可以通过调节用户连接来平衡访问和可用性。 

结论

        维护高标准的 API 安全性是最重要的问题。正如我们在上面看到的，在设计授权流程时需要考虑许多技术策略，如果被破坏，会直接影响 API 安全性。只有使用负责证书生成和处理声明的安全、集中的 OAuth 服务器才能建立更强大的基础。许多建议还围绕着对待内部 API 与面向公众的端点一样小心。通过遵循这些保护措施，您可以充分保护 API 并阻止不需要的行为。