如何构建和设计以确保 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. 身份验证和授权   通常情况下，身份验证和授权是同步发生的。  

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

（编辑：淮安站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!