如何构建和设计以确保 API 的安全性

　　如何构建和设计以确保 API 的安全性

　　面对常见的OWASP十大威胁、未经授权的访问、拒绝服务攻击、以及窃取机密数据等类型的攻击，企业需要使用通用的安全框架，来保护其REST API，并保证良好的用户使用体验。本文向您介绍四种类型的API安全保护方式。

　　管理好API安全性 API的安全性涉及到各种端到端的数据保护，它们依次包括：来自客户端的请求经由网络到达服务器/后端，由服务器/后端发送相应的响应，响应横跨网络，最后到达客户端，这一系列的过程。因此，API的安全性可以大致分为如下四种不同的类别，我们将逐一进行详细讨论：

　　(1)传输中的数据安全

　　· 保护客户端与API网关之间的动态数据

　　· 保护API网关与后端服务之间的动态数据

　　(2)访问控制与抵御拒绝服务(DoS)攻击

　　(3)身份验证与授权：使用OAuth2.0或OpenID Connect，来可靠地识别最终用户的信息

　　(4)数据保密与屏蔽个人身份信息(Personally Identifiable Information，PII) 1. 传输中的数据安全 对于所有公共且不受保护的API来说，我们必须用到TLS。如今随着硬件的进步，TLS的实施开销几乎可以忽略不计了，而且随着延迟在逐渐减小，越来越多的最终用户会处于安全考虑而选用TLS。总的说来，TLS具有如下主要特点：

　　· TLS应当在北向(northbound)和南向(southbound)端点同时实施。

　　· 应确保使用TLS的最新版本，并对客户端、API网关和目标后端予以支持。

　　· 证书密钥、以及信任凭证的存储都应该受到高度保护和加密。

　　· 只有经过授权的用户才能访问证书密钥、以及信任凭证。 2. 访问控制与抵御拒绝服务(DoS)攻击

　　(1) 网络级别的防御:如果API网关被托管在云端，则需要使用由云服务商所提供的 DDoS防御机制，例如：由Apigee(Google)所运营的Apigee Edge托管云平台、 GCP(Google云平台)和AWS(Amazon Web)，它们都提供了网络级别的DDoS防御。

　　(2) 内容交付网络：像Akamai、Neustar和Rackspace之类的CDN，都可以用于缓解那些对于API的DDoS攻击。

　　(3) “僵尸”检测：如今各大API管理平台都已经针对僵尸/机器人类型的攻击，推出了检测API流量，识别各种恶意/非必要请求，并生成警报/阻止恶意请求到达的API网关服务。例如：Apigee(Google)提供了一种称为“Apigee Sense”的检测服务。它是一种智能数据驱动的API安全产品，它可以通过自动识别各种可疑的API客户端行为，以提供额外的保护层。同时，管理员也可以在此基础上通过纠正性措施，来保证用户的体验度，以及后端系统的安全性。

　　(4) 策略执行：我们应该在位于API客户端和客户后端之间的API代理上，通过强制实施各种策略，以严格管控合法用户对于API的访问。如下策略能够在一定程度上保护API免受恶意黑客的攻击：

　　· API速率限制：通过限速，我们可以减少大量导致拒绝服务的API请求，并抑制暴力攻击和服务滥用。特别是在API代理服务器上，我们可以采用如下限速的机制：

　　· 基于应用程序或个别API予以限速，以保证每个API或应用程序只能按照固定的请求数配额，去访问对应的服务。

　　· 基于GET或POST请求予以限速，当然具体的请求数设定，可以根据不同时段的GET或POST量而有所不同。

　　(5) 正则表达式保护：应当根据预定义的正则表达式(如DELETE、UPDATE和EXECUTE)来评估入栈请求的URI路径、查询参数、包头、表格参数、变量、XML有效负载、以及JSON负载。任何匹配上了预定义表达式的请求都将被视为威胁，并被立即拒绝掉。请参阅OWASP top 10(https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project#OWASP_Top_10_for_2013)，以了解具体有关要如何验证正则表达式的信息。

　　(6) JSON输入验证：对于PUT/POST/DELETE之类请求的负载，我们应执行JSON验证，以通过指定对于各种JSON结构的限制(如最大深度、对象的最大数量、最长字符串长度的名称、以及数组中所允许的最大元素数等)，来最小化可能受到的攻击面。

　　(7) XML输入验证：应当对PUT/POSTE/DELETE之类请求的负载执行XML验证。具体可使用如下方法来根据配置的限制，以检测XML负载的各类攻击、以及监控针对XML的威胁：

　　· 根据XML的架构(.xsd)来验证消息

　　· 根据特定黑名单里的关键字与模式，来评估消息内容 · 在分析消息之前，检测出已损坏或格式错误的消息

　　(8) 验证请求 · 验证输入HTTP动词：适当地对那些允许类动词做出限制，而对于其他所有动词，则返回相应的响应代码(如：“403禁止错误”)。

　　· 验证包头：应当根据API所支持的功能，显式地验证“内容类型”、“接受”和“内容长度”等包头。此外，还应该执行针对强制性包头(如：授权、以及特定类型的API包头)的验证。

　　· 验证入栈内容类型：对于PUT/POST/DELETE之类入栈请求的内容类型(例如：应用/XML或应用/JSON)、以及内容类型的包头值进行验证。对于缺少内容类型的包头、或异常内容类型的包头，应当直接拒绝，并返回“406不可接受”的响应内容。

　　· 验证响应类型：不要简单地将“接受”包头复制到响应内容类型的包头中。如果“接受”包头中并没有明确地包含允许的类型，应当直接拒绝该请求，并返回“406不可接受”的响应内容。

　　· 处置不支持的资源：适当通过限制资源，只开放可供调用的资源;而对于其他所有未实现的资源，则应返回“未知资源”之类相应的响应代码。

　　(9) 访问控制：通过配置策略，只允许来自特定IP地址、域名或区域的请求。而那些未通过此类条件的请求，应当被网关直接拒绝掉。

　　3. 身份验证和授权 通常情况下，身份验证和授权是同步发生的。

　　· 身份验证常被用于识别最终用户。

　　· 授权则被用于授予已识别用户访问某些资源的权限。 在API领域中，OAuth和OpenID Connect是最为常用的机制。它们通过利用现有的IAM架构，并以交换访问令牌的方式，来验证用户的身份，进而保护API的各个端点。通过OAuth和OpenID Connect，我们不需要每次都构建单独的系统，以存储用户名和密码的方式，来匹配用户可以访问的API资源。

　　OAuth OAuth通常采用不透明(OPAQUE)令牌，来实现委托访问(Delegated Access)的目的。OAuth2.0授权框架使得第三方应用能够获得对于HTTP服务的有限访问权限。通常，用户不应当为了访问某些存储在第三方的受保护数据，而在公网上传输自己的密码。而OAuth恰好能够为用户访问自己的数据，提供了信任凭据的安全保护。

　　OAuth不是一种身份验证协议，而是授权协议。由于身份验证通常发生在颁发访问令牌之前，因此我们很容易理解为在接受访问令牌时，也进行了身份验证。然而，仅凭拥有访问令牌，并不能证明用户的身份。在OAuth中，令牌被设计为对客户端来说是不透明的，客户端仅能从令牌中获取权限信息，而不会涉及到用户名与密码。

　　不透明令牌:在许多的具体实现中，OAuth2.0会返回OPAQUE字符串，用以换取被称为访问令牌的用户凭据，而这些令牌将被进一步用于访问各种API的资源。不透明令牌并非用来存储用户身份标识与信息，而是指向了某个数据库里的具体数据项。例如：我们可以用Redis来存储各种键-值(key-value)。而Cassandra之类的NoSQL数据库则非常适合利用内存中的哈希表，根据I/O来查找有效负载。由于用户角色是直接从数据库中被读出的，因此我们可以通过更改后端的角色，来传递并展现给用户。

　　OpenID Connect OpenID Connect采用ID令牌和访问令牌，来实现用户识别与委托访问。OpenID Connect是进行用户身份验证的标准。由于直接构建在OAuth2.0之上，因此在大多数情况下，OpenID Connect是与OAuth架构一起被部署的。在交付形式上，它还为客户端提供OpenID Connect令牌。该身份令牌是一个已签名的JSON Web令牌(JWT)，它与常规的OAuth访问令牌一起被提交给客户端应用程序。

　　· JSON Web令牌：JWT令牌实际上是一个完整的JSON对象。它经历了base64编码之后，使用对称共享密钥、或公/私钥的方式进行签名。JWT可以包含诸如：主题、user_id、令牌颁发时间、以及过期时间等信息。通过密钥签名，它可以确保只对拥有授权访问密钥的系统才能生成令牌。不过值得注意的是，系统在对JWT进行签名时，JWT通常不会被加密(当然，您也可以选择对其进行加密)。那么，这就意味着任何拥有令牌访问权限的人都可以读取令牌里的数据。因此，业界的最佳实践是：只把用户标识(如user_id)放在令牌中，而不是个人身份信息(如电子邮件或社会保障号码)。此外，它们应当通过TLS之类的加密通道来进行传递。

　　· JWT限制：鉴于日常对于用户的禁用、以及添加或删除角色往往需要一段时间才能同步生效，而且由于令牌存储在客户端，即使我们在数据库中对其所颁发的JWT用户进行了禁用标记的话，也无法直接让该令牌及时无效。虽然JWT采取了预定义到期的机制，但是用户仍然需要等待到期。显然这会影响到用户的服务架构，特别是那些电商类的应用。

　　当然，业界也提供了一些变通的方法。例如：您可以使用带有令牌或user_id的黑名单，但是这需要向数据库引入新的认证机制。因此，一种推荐的方法是：通过黑名单以确保每个令牌都带有一个JTI声明(或带有一个存储在数据库中的JWT Id)。因此，只要您希望注销的令牌数量远小于应用程序中的用户数量，那么操作起来就非常灵活。

　　可见，对于那些拥有管理员、项目所有者、服务客户经理等多种角色的企业应用来说，切换用户的不同角色并不会对JWT立即生效。例如：管理员修改了某个授权用户的角色，那么只要他不去刷新JWT，也就无法获悉该变更。

　　下面是OpenID Connect的三种实现用例：

　　· 出栈方向的Web单一登录(SSO)：向企业用户提供对于SaaS应用、以及合作伙伴应用的访问管控，但并不公开本企业的用户名与密码。

　　· 入栈方向的Web单一登录：允许社交账号/第三方登录，但无需存储外部用户与密码。

　　· 实现各种本地应用的原生单一登录。

　　OAuth和OpenID Connect都支持OAuth2规范所指定的四种授权类型，下图描述了其中一种授权流程图。API开发人员可以根据手头项目所需的约束与实现方案，来选用不同的授权类型。

　　4. 数据保密与屏蔽个人身份信息 众所周知，由于密码、安全令牌和API密钥包含了不同程度的内部信息，它们不应该出现在URL中，或者被Web服务器的日志所捕获。此外，诸如UserID、密码、帐号、信用卡号码等个人身份信息，也应该处于“被打码”的状态，哪怕是在交易和审计日志中。

　　公共API的安全实践 由于独立于任何用户，因此公共API的设计初衷就是为了公开各种非敏感、以及只读的数据(例如天气类API)，当然也就不必添加任何身份验证与授权环节。不过，我建议您通过如下的方面，来打造能够应对各种威胁与滥用的API：

　　· 在IP地址级别上应用速率限制的相关策略。

　　· 使用API密钥验证的方式。通过存储在网关上的方式，保证API的密钥不会被公布给任何客户端。因此，当拒绝服务攻击使用无效密钥访问API、或是在其他策略已无法阻断黑客攻击时，API密钥验证方式能够有效地发挥作用。

　　· 采用配额策略(单个或多种配额机制)，来实现API的使用限制。

　　· 如果API被用于特定地理区域的服务器进行通信，那么就应当在地理级别上(县/区等)采取IP地址的筛选。

　　· 开发人员应尽量采用一次性注册的方式，并使用自己的API密钥去调用API。

　　结论

　　在企业内部、以及企业之间需要集成不同的应用时，开发人员能够通过API来快速且方便地予以实现。不过，如果没有恰当地保护好API，那么就会让整个企业面临各种风险与威胁。因此，我们需要在开发和实施之前，就对API的安全性进行良好的构建和设计，从而提高企业的整体安全态势。