初级工程师建议收藏|企业级 APIs 安全实践指南

导语：作为互联网人，不管你是工程师，抑或实施支持，是产品经理，抑或产品运营，我相信大部分人应该都听说过 API 这个词。不管是做移动端产品，还是做 SaaS 产品，或者是企业服务产品，都离不开 API。这篇文章结合日常开发场景，向大家简单通俗地介绍了什么是 API，如何设计出更安全有效的 API。

前言​

我们许多人都听说过 API（Application Programming Interface）这个名词，我们可以简单的说，API 为一个程序提供了访问另一个程序的信息和功能的方法。

我们常说的 APIs 一般是指 Web API，这些 API 可以通过不同的方式实现。最常见的例如 REST，RPC，gRPC，SOAP 等。

类似上图，一个最简单的服务模型至少包含两种角色，客户端或服务端（也可称为服务消费者和服务提供者）。API 作为一个接口，描述了可用的服务并定义了请求服务必须遵循的规则。使用 API 作为客户端和服务端交换数据的“中介”有以下两点优势：

语言无关性 - 客户端能够请求不同语言实现的服务端应用程序的数据。

实现细节透明 - 请求者不需要了解服务端是如果完整一类功能和返回数据的具体过程，开发人员只需要知道如何以正确的方式请求服务。

这两点改变了开发人员编写应用程序的方式。开发人员既可以提供自身应用程序的 APIs 给外部使用，又可以作为外部 APIs 的消费者，将外部数据源或核心功能以外的其他功能集成到自身应用程序中，而不用关心具体细节，以适应消费者不断变化的需求和愿望。基于 APIs 的规则约定也可以在服务后端实现发生变化时，开发人员不需要更新或很少修改他们的程序就可以保证调用继续有效。

几乎每家公司，无论大小都会公开一些 APIs 将企业本身的能力开放给其他使用者。一些企业通过免费公开的 APIs 提供他们的品牌知名度，更多的企业将 APIs 作为一种服务形式并从中获得了惊人的利润。

01.理解 APIs 中隐含的风险

鉴于上述优势，APIs 已经成为了构建应用程序必要的手段。本质上来说，APIs 会将数据暴露给外部人员，每个 API 背后的实际提供者可能是 Web 服务器或数据库。其隐含的巨大利益必然会吸引很多不怀好意的人试图攻击你的 APIs，不止企图获取 APIs 提供的未授权数据，还可能作为潜在入口点攻击企业内部基础设施内的其他系统。

在最坏的情况下，一旦发生数据泄漏或不可恢复的数据破坏，可能会损害企业的品牌和声誉，并附带巨额的罚款和收入损失。

所以作为开发人员，无论是设计 APIs 还是使用其他服务提供的 APIs，都必须小心。尤其是公开可用的 APIs。

02.针对 APIs 常见的攻击方法

Injection - 注入攻击是指攻击者给程序提供恶意的输入，解析方法把恶意输入作为命令或查询的一部分，从而改变了应用的执行逻辑。SQL Injection 是其中的一种，攻击者可以通过恶意输入控制 SQL 数据库；Cross-Site Scripting 也是注入攻击的一种，攻击者通过将恶意脚本（一般是 JavaScript）插入 Web 应用程序或网页中，执行恶意代码。

Distributed Denial-of-Service (DDoS) - 多个不同位置攻击者同时对同一目标网站在较短的时间内发起大量请求，大规模消耗目标网站的资源，造成无法对正常请求提供服务。

Man-in-the-Middle (MitM) - 中间人攻击是指攻击者恶意拦截两个系统之间流量并相互模仿，篡改原始数据达到其目的。

Credential stuffing - 凭证填充，习惯称为“撞库”。攻击者利用其他服务数据泄漏中获得的登录凭证尝试登录到另一个系统。

03.如何设计一个安全的 API

作为一个开发人员，我们在设计和使用 APIs 有一些高效的实践手段可以有效抵御一些常见的攻击：

优先考虑安全问题 - 思想上，要正视安全问题。不要认为保障 APIs 安全问题是基础设施团队和运维团队才需要考虑的问题，开发人员在设计 APIs 阶段就要将安全作为基本需求构建到应用程序中。

持续加固 API 认证授权机制 - 针对 APIs 的认证和授权机制是控制外部调用 APIs 的主要手段。不认证客户端的合法身份或不良的身份认证设计是造成 APIs 被攻击的主要因素。应用程序应持续完善相关访问控制逻辑，尽可能使用可靠的、经过验证的身份验证和授权机制的解决方案，例如 OAuth2.0 和 OpenID Connect。下文对一些常见的 API 认证授权方式做了介绍。

校验参数 - 针对请求中的输入参数值、类型、格式执行校验，可以避免出现不合法或恶意的请求。引入一些参数校验框架也可以有效抵御注入的风险。同时也要针对请求数据大小做限制，防止应用尝试解析不合法的超大数据造成资源消耗。

遵循最小特权原则 - 只分配给客户端完成所需功能的最小权限，严格控制访问不属于该客户端的其他 APIs。

避免暴露敏感数据 - 只返回与本次请求相关且满足客户端需求的最小集合数据，避免敏感数据无意泄漏。

请求限流 - 设置一个阈值，控制 APIs 的访问速率。常见的限流算法有漏桶算法（Leaky Bucket），令牌桶算法（Token Bukcet），固定窗口（Fixed Window），滑动窗口算法（Slide Window）。一些方案也会基于 Redis 或 Zookeeper 实现。

使用 https - APIs 只使用 https 作为双方通信的协议。TLS 加密流量可以有效抵御中间人攻击。

API 网关 - 引入 API 网关针对 APIs 请求来源或特征进行过滤，只允许合法请求通过。防火墙是其中的一种实现形式。

完善 APIs 的管理 - 一些 API 管理工具可以帮助开发人员管理应用程序的所有 APIs 情况，例如 Postman，Swagger 等。一些强大的 API 管理工具，还可以在 Devops 阶段扫描应用程序中新增或移除的 APIs 以及其他 API 版本控制功能。

APIs 调用情况监控和预警 - 一些工具或监控大盘可以让开发人员时刻关注应用程序中 APIs 的调用情况，针对异常情况及时预警，以便迅速作出反应。

04.几种常见的 APIs 认证和授权方式

No Auth 无

API Key 将 key:value 信息添加到请求头/查询参数/请求体中

Basic Auth 将 Authorization: Basic base64(username:password) 信息添加到请求头中

Bearer Token

将 Authorization: Bearer <Token> 信息添加到请求头中

Basic Auth

将 Authorization: Basic base64(username:password) 信息添加到请求头中

上面的几种方式特点是：

1. 其本质将用户凭证信息通过某种方式对凭证信息进行编码，添加到每一个请求中（请求头/请求查询参数/请求体），通过网络发送给服务端。因此，会给攻击者提供很长的攻击窗口，且凭证信息很容易转换成明文。

2. 客户端应用程序需缓存或保存每个用户的用户凭证信息，容易被泄漏或窃取。

3. 优点是轻量且易于实现，服务内部的 APIs 调用因为有防火墙保护，可以使用上述几种方式。

4. 基于 OAuth 的授权方式允许用户在不暴露登录信息的情况下授权客户端应用程序通过三方服务提供的 APIs 访问用户的数据。

OAuth 1.0

术语表名称

请求地址

Temporary Credential Request: https://photos.example.net/initiate

Resource Owner Authorization URI: https://photos.example.net/authorize

Token Request URI: https://photos.example.net/token

Callback URI: https://printer.example.com/ready

授权流程

1.client 使用 appKey 和 appSecret 向 server 申请一个临时访问凭证

POST /initiate HTTP/1.1Host: photos.example.netAuthorization: OAuth realm="Photos",  oauth_consumer_key="dpf43f3p2l4k3l03",  oauth_signature_method="HMAC-SHA1",  oauth_timestamp="137131200",  oauth_nonce="wIjqoS",  oauth_callback="http%3A%2F%2Fprinter.example.com%2Fready",  oauth_signature="74KNZJeDHnMBp0EMJ9ZHt%2FXKycU%3D"
//server认证client身份后，下发一个临时凭证HTTP/1.1 200 OKContent-Type: application/x-www-form-urlencoded
  oauth_token=hh5s93j4hdidpola&oauth_token_secret=hdhd0244k9j7ao03&  oauth_callback_confirmed=true

2.client 重定向用户到三方服务授权页面，获取用户的授权

https://photos.example.net/authorize?oauth_token=hh5s93j4hdidpola

3.server 要求用户输入登录信息，并确认授予 client 访问数据的权限，server 按照请求中的 oauth_callback 重定向用户到 client

http://printer.example.com/ready?oauth_token=hh5s93j4hdidpola&oauth_verifier=hfdp7dh39dks9884

4.client 使用 accessToken，返回该 token 的信息及对应的用户信息

POST /token HTTP/1.1Host: photos.example.netAuthorization: OAuth realm="Photos",  oauth_consumer_key="dpf43f3p2l4k3l03",  oauth_token="hh5s93j4hdidpola",  oauth_signature_method="HMAC-SHA1",    oauth_timestamp="137131201",  oauth_nonce="walatlh",  oauth_verifier="hfdp7dh39dks9884",  oauth_signature="gKgrFCywp7rO0OXSjdot%2FIHF7IU%3D"
// server验证请求，并返回访问数据的accessTokenHTTP/1.1 200 OKContent-Type: application/x-www-form-urlencoded
  oauth_token=nnch734d00sl2jdk&oauth_token_secret=pfkkdhi9sl3r4s00

5.client 使用 accessToken，返回该 token 的信息及对应的用户信息

GET /photos?file=vacation.jpg&size=original HTTP/1.1Host: photos.example.netAuthorization: OAuth realm="Photos",  oauth_consumer_key="dpf43f3p2l4k3l03",  oauth_token="nnch734d00sl2jdk",  oauth_signature_method="HMAC-SHA1",  oauth_timestamp="137131202",  oauth_nonce="chapoH",  oauth_signature="MdpQcU8iPSUjWoN%2FUDMsK2sui9I%3D"
// Ignore

凭证信息

• OAuth 2.0

Abstract Flow

不同的授权方式都包含 3 个 大致一样的流程：

1. 向用户索要授权 - 基本逻辑是重定向用户到服务网站填写登录信息并批准授权。

2. 客户端根据返回的授权信息，换取 access_token。

3. 使用 access_token 调用 API 获取数据。

Refresh Token

refresh_token 用于在 access_token 失效或过期后获取新的 access_token。refresh_token 并不是一个必须的流程，取决于服务端的实现。

OAuth 2.0

支持的四种不同的授权方式，分别是：

Authorization Code - 授权码 Implicit - 隐藏式 Resource Owner Password Credentials - 密码式 Client Credentials - 客户端凭证以授权码方式的授权流程为例：

4.client 重定向用户到三方网站的授权页面，携带信息包含 response_type, client_id，scope, state, redirect_url

GET https://github.com/login/oauth/authorize?response_type=code&client_id=b480708cdf67d45c1645&redirect_uri=http%3A%2F%2F127.0.0.1%3A8081%2Fcallback

5.用户在 server 端授权通过后，重定向用户到第一步中指定的 redirect 地址

GET http://127.0.0.1:8081/callback?code=eb641fc1ed18937056be

1. 用户通过上一步获取的 code 获取 access_token

POST /login/oauth/access_token?client_id=b480708cdf67d45c1645&client_secret=e6945adce6b7820b661199e8b970f251c1efc218&code= eb641fc1ed18937056be&redirect_uri=http://127.0.0.1:8081/callback HTTP/1.1
// responseaccess_token=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&scope=&token_type=bearer

注意要区分 redirect url，callback url, webhook url。redirect url，callback url 一般指用户授权结束后重定向的地址，有的服务提供商会 webhook url 的配置，用于后端接收授权成功后的回调。

OAuth 方案可以看作是重定向用户授权流程 + 基于 token 方案的结合。

凭证信息名称

总结

以上只是对常见的 API 认证授权方式做了介绍，很多 APIs 认证和授权方案都是基于以上几种方式实现的单一方案或混合方案，一些厂商也会在此基础上做一些定制化的方案，例如会设计自己的签名和数据加密方法。了解常见的授权方式，既能帮助开发人员设计更加安全的 APIs，也可以快速理解并应用其他厂商提供的 APIs 服务。

文档引用

OAuth 1.0：https://oauth.net/1/OAuth 1.0 RFC5849：https://datatracker.ietf.org/doc/html/rfc5849OAuth 2.0：https://oauth.net/2/OAuth 2.0 RFC6749：https://datatracker.ietf.org/doc/html/rfc6749

关于领创集团

（Advance Intelligence Group）

领创集团成立于 2016 年，致力于通过科技创新的本地化应用，改造和重塑金融和零售行业，以多元化的业务布局打造一个服务于消费者、企业和商户的生态圈。集团旗下包含企业业务和消费者业务两大板块，企业业务包含 ADVANCE.AI 和 Ginee，分别为银行、金融、金融科技、零售和电商行业客户提供基于 AI 技术的数字身份验证、风险管理产品和全渠道电商服务解决方案；消费者业务 Atome Financial 包括亚洲最大的先享后付平台 Atome 和数字信贷服务。2021 年 9 月，领创集团宣布完成超 4 亿美元 D 轮融资，融资完成后领创集团估值已超 20 亿美元，成为新加坡最大的独立科技创业公司之一。

▼ 如果觉得这篇内容对你有所帮助，有所启发，欢迎点赞收藏：

1、点赞、关注领创集团，获取最新技术分享和公司动态。

2、关注我们的公众号「领创集团 Advance Group」，了解更多行业动态。