API安全技术

　　自己在日常工作中会涉及到些安全的概念，但是没有成体系，因此最近研读了《API安全技术与实战》一书，在此做些文章记录。

　　API安全是从安全的角度关注API领域的安全问题和这些问题的解决方案，从技术和管理两个层面提高API自身和API周边生态的安全性。

1）OWASP API 安全漏洞类型

　　OWASP（Open Web Application Security Project）是一个开源的、非盈利的全球性安全组织，主要致力于应用软件的安全研究，它有很多开源项目，OWASP API安全Top 10就是其中的一个。

1. 失效的对象级授权：攻击者通过破坏对象级别授权的API，来获得未经授权的或敏感的数据，比如通过可预测订单ID值来查询所有订单信息。
2. 失效的用户认证：开发者对API身份认证机制设计存在缺陷或无保护设计，导致身份认证机制无效，比如弱密码、无锁定机制而被暴露破解、Token未校验或Token泄露导致认证机制失效等。
3. 过度的数据暴露：在API响应报文中，未对应答数据做适当的过滤，返回过多的、不必要的敏感信息。比如查询用户信息接口时却返回了身份证号、密码信息；查询订单信息时也返回了付款银行卡号、付款人地址信息等。
4. 缺乏资源和速率控制：在API设计中，未对API做资源和速率限制或保护不足，导致被攻击。比如用户信息接口未做频次限制，导致所有用户数据被盗；文本翻译接口没有速率限制导致大量文件上传耗尽翻译服务器资源。
5. 失效的功能级授权：与第一条类似，只不过此处主要指功能级的控制，比如修改HTTP方法，从GET改成DELETE便能访问一些非授权的API；普通用户可以访问api/userinfo的调用，直接修改为api/admininfo，即可调用管理类API。
6. 批量分配：在API的业务对象或数据结构中，通常存在多个属性，攻击者通过篡改属性值的方式，达到攻击目的。比如通过设置user.is_admin和user.is_manager的值提升用户权限等级；假设某API的默认接口调用参数为{"user_name":"user"，"is_admin":0}，而恶意攻击者修改请求参数，提交值为{"user_name":"attacker"，"is_admin":1}，通过修改参数is_admin的值来提升为管理员权限。
7. 安全性配置错误：系统配置错误导致API的不安全，比如传输层没有使用TLS导致中间人劫持；异常堆栈信息未处理直接抛给调用端导致敏感信息泄露。
8. 注入：与OWASP Web安全注入类型相似，主要指SQL注入、NoSQL注入、命令行注入、XML注入等。
9. 资产管理不当：对于API资产的管理不清，比如测试环境的、已过期的、低版本的、未升级补丁的、影子API等接口暴露，从管理上没有梳理清楚，导致被黑客攻击。
10. 日志记录和监控不足：对API缺失有效的监控和日志审计手段，导致被黑客攻击时缺少告警、提醒，未能及时阻断。比如没有统一的API网关、没有SEIM平台、没有接入Web应用防火墙等。

2）5A原则

　　5A原则是由5个首字母为A的单词构成的：

　　分别是Authentication（身份认证）、Authorization（授权）、AccessControl（访问控制）、Auditable（可审计性）、AssetProtection（资产保护），其含义是当做安全设计时，需要从这5个方面考量合理性。

1. 身份认证：身份认证的目的是为了知道谁在与API服务进行通信，是否是API服务允许的客户端请求。在普通的Web应用程序中，通常会提供注册、登录的功能，没有注册、登录的用户无法访问某些系统功能。其认证方式主要有用户名/密码认证、动态口令、数字证书认征、生物特征认证等。
2. 授权：授权通常发生在身份认证之后，身份认证是解决“你是谁”的问题，即对服务来说，谁在请求我。而授权解决的是“你能访问什么”的问题，即通过了身份认证之后，访问者被授予可以访问哪些API。某些API只有特定的角色才可以访问，比如只有内网的IP才可以调用某些服务、只有管理员用户才可以调用删除用户的API。赋予某个客户端调用权限的过程，通常为授权操作的过程。
3. 访问控制：访问控制是对授权后的客户端访问时的正确性验证。授权就是用户→角色→菜单这三个实体对象间建立相互关系的过程。如果这个相互关系设置正确，用户是不具备访问这个功能菜单的权限的，但如果用户访问这个功能菜单时，因访问控制没有限制，仍可以访问，这就是访问控制的缺陷。
4. 可审计性：审计的目的对于API来说，主要是为了记录接口调用的关键信息，以便通过审计手段及时发现问题，并在发生问题时通过审计日志进行溯源，找出问题的发生点。日志审计在API技术中通常是结合已有的日志服务一起使用，其目的是通过审计策略和日志分析，发现系统在某一时间段内发生的异常事件，通过事件关联和追溯，分析与事件相关联的内外部人员、系统、事件涉及的范围等。主要的产品有Elasticsearch、Logstash、Kibana等。
5. 资产保护：API安全中的资产保护主要是指对API接口自身的保护，比如限速、限流，防止恶意调用，除此之外，API接口传输的数据也是需要保护的一个重点内容。

3）API安全技术栈

　　当用户通过浏览器或移动终端调用API访问后端服务时，除了通信链路使用HTTPS之外，由前端向后端依次通过速率控制、身份鉴别、授权访问控制、消息保护、审计监控等安全机制。

　　虽然与实际应用中各个安全机制杂糅在一起使用的情况不相符，但基本能表述清楚其中涉及的安全机制，把这些安全机制对应到具体的安全技术上，统称为API安全技术栈。

　　对常用的API安全技术进行了总结：

1. 最上面的WAF、API网关是API安全的基础套件，为API安全提供综合的安全支撑能力。
2. 认证与授权以OpenID Connect套件、OAuth 2.0套件为代表，提供API的身份认证和鉴权解决方案。
3. 而审计套件、JSON套件、XML套件为API的消息保护和安全审计提供技术支持。

4）身份认证

　　身份认证，是对于身份的认证或鉴别，在业务流程中结合技术手段，完成对某种身份的确认。

　　这里的某种身份可能是基于真实的自然人信息的用户身份，也可能是服务器、硬件设备、移动终端的身份，还有可能是运行的应用程序或服务的身份。

　　在计算机领域，身份认证的方式有很多，比较常见的有静态密码、动态口令、短信码、数字证书、生物特征等。典型的身份认证技术有OpenID Connect、WS-Security、JWT等。

1. 以API KEY签名认证作为身份认证技术的具体实现在API使用中出现较早，通常被称为HMAC认证。在API KEY签名认证中，API的接口调用是融入API的生命周期中去管理，任何客户端想调用API接口，都需要开发者先从API管理平台中申请接入密钥AccessKey（AK）和加密密钥SecretKey（SK）。然后在发起客户端API请求时，将参数和AK一起，使用SK签名后发送到服务端。使用API KEY签名认证的好处是在API客户端和服务器端使用了相同的签名算法，若传输过程中数据被篡改，则签名校验无法通过，有效地解决了请求参数被篡改的安全隐患。
2. 使用消息头作为身份认证技术在以XML为数据传输格式的API接口中较为常见，典型的如SOAP API中的Web Services服务安全规范WS-Security。在WS-Security安全规范中，详细地描述了如何将签名和加密头加入SOAP消息，以及在消息中加入安全令牌、X.509认证证书或Kerberos票据等，通过在应用层处理消息头信息，以保证端到端的API安全。
3. 基于Token系列认证，以OpenID Connect、JWT（JSON Web Token）、OAuth等技术为代表。

5）授权与访问控制

　　API的授权与访问控制技术可以归为两大类：

1. 基于使用者身份代理的授权与访问控制技术，典型的以OAuth 2.0。对于API的授权和可访问资源的控制依赖于使用者的身份，使用者可能是某个自然人用户，也可能是某个客户端应用程序，当得到使用者的授权许可后，即可访问该使用者授权的资源。
2. 基于使用者角色的授权与访问控制，典型的以RBAC（Role-Based Access Control）为代表。对于API的授权和资源访问依赖于使用者在系统中被授予的角色和分配的权限，不同的角色拥有不同的权限，比如功能权限、数据权限，访问资源时依据此角色分配的权限的不同可以访问不同的资源。

　　在API安全技术领域，功能级权限管理是指不同的用户或不同的角色对不同的API端点具备的权限的管理。

　　数据级权限管理是指不同的用户或不同的角色对不同的API端点中涉及的数据、图片、视频等资源，对于可操作资源的范围、范围内资源的增删改查的操作权限管理。

　　授权管理中很重要的一个设计原则是最小特权原则，即对用户和和API点授权时，在满足功能的前提下仅授予最小的权限，同时，不同的用户或角色，授权之间相互独立，否则会出现权限过大或违背业务独立性的要求。

　　访问控制是在授权正确的前提下，通过访问控制机制，保证用户或角色所访问的内容和资源与所授权范围一致。访问控制通常有三个要素组成：主体、客体、控制策略。

1. 主体是指访问动作的发起者，一般是某个用户、应用程序以及API端点。
2. 客体是指被访问的对象，一般是模块、功能、菜单、按钮、链接、资源、API端点等。
3. 控制策略是指为了满足授权要求而制订的控制规则。

　　假设存在着这样一条访问控制规则：外包人员只允许在13:00点之后才可以进入机房进行维护操作。那么这里的外包人员是主体，客体是机房及机房中的资源，控制策略是13:00点之后可以访问。

　　授权作为权限管理的决策机制，明确了权限与用户、角色的关系。访问控制作为执行单元，将权限管理落实到位。它们共同协作，维护着信息系统的稳定。

　　在RBAC模型中，定义了三条主要规则，其基本含义如下。

1. 角色分配：是指只有为某个用户（用户是指真实自然人或应用程序）分配了该角色后，才具有该角色对应的权限。
2. 角色授权：对应于安全设计原则中的最小特权原则，即用户被授予某个角色之后，仅能完成所授予权限内的活动。
3. 权限授权：是指仅当某个角色被授予权限后，该角色被分配的用户才具有此角色所授予的权限。

6）API的消息保护

　　针对API的消息保护一般从以下两个方面来实现安全保护机制。

1. 通信链路保护：主要是传输层保护，使用mTLS/SSL来提高通信链路的安全性。
2. 应用层消息加密和签名：在应用层，除了使用HTTPS、SFTP、SSH等安全协议外，还会对消息体进行加密和签名。加密用来保护数据的机密性，签名用来保护数据的防劫持和防篡改。

　　由于应用层API交互技术的不同，对消息体的保护更多是围绕具体的交互细节去实现，比如对认证令牌的保护、对访问令牌的保护、对敏感信息的保护等。

　　而JSON和XML作为消息传递的数据格式，其相关的技术标准(如JWT、JWE、JWS、WS-Security等)为消息保护提供了可操作指南。

　　JWT是RFC 7519标准为使用JSON数据格式作为传输对象的多方通信所提供的解决方案，通常以字符串形式表示，由标头、有效载荷、签名三部分组成，各个组成部分之间以点号（.）分隔。

7）API网关

　　API网关是当今互联网应用在前后端分离背景下，微服务架构、分布式架构、多端化服务等架构中重要的组成部分，作为应用层统一的服务入口，方便平台管理和维护众多的服务接口。

　　一般来说，API网关由核心控制系统和后台管理系统两部分组成。

1. 核心控制系统：为了满足业务需要所对外提供的核心API能力的总称，比如处理安全策略、流量控制、服务鉴权、熔断、参数校验、参数映射、协议转换、服务生命周期管理等所有核心业务能力。
2. 后台管理系统：用于辅助核心控制系统所提供的能力总称，比如用户管理、应用接入管理、SDK和API文档生成、服务授权控制、服务策略绑定等功能的管理能力，为管理人员提供可视化的操作界面，降低API管理难度。

　　在API网关的周边，与相邻应用程序的上下文关系如下。

1. 和后端API服务之间的关系：API提供者在提供稳定的API后，在API网关中注册并发布API或生成SDK，才可以被终端业务系统调用。
2. 和客户端应用程序之间的关系：不同的客户端/终端应用程序首先访问API网关，经过一系列的API控制器、网关路由到目标API。
3. 和运维监控系统之间的关系：API网关接入运维监控系统，一方面用于监控网关和服务器的运行情况，另一方面也可以监控各个已注册API的运行健康情况，并在异常时可以触发告警。
4. 和日志平台之间的关系：API网关接入日志平台，用于采集API的调用信息，完成问题分析、调用链跟踪、调用数据统计等。

　　使用API网关的系统架构中，API网关层将内部服务和外部调用隔离，客户端应用程序调用的后端服务都通过网关的映射来完成，很好地隐藏了内部服务数据，保障了服务的私密性和安全性。

　　同时，在整个架构上，能让业务使用者抽出更多的精力来关注核心业务能力建设，而不是通用的安全性、流控等边界特性的问题。这在快速增加新业务或改变原有应用系统、服务时，对现有架构和应用程序的影响能降低到最小。

　　API网关产品除了上节提及的在网络边界起到内外部隔离外，还有如下特点。

1. 减少客户端与服务端之间的耦合，后端服务可以独立发展。其主要表现为：客户端应用程序调用后端服务都是通过网关的映射完成的，在这样的场景下，内部服务的变更只需要通过修改网关定义即可，客户端应用程序不需要做任何变更。API网关通过统一标准的协议来整合现有不同架构、不同语言、不同协议的服务资源，实现业务互联互动，减少客户端或服务器端的改变对对方造成的影响。
2. 集成多种安全机制，保障服务交互的安全性。典型的有通信加密、身份认证、权限管理、流量控制等安全手段。API网关为每一个应用接入者提供不同的加密密钥或证书，支持多种加密方式和安全传输协议，在保障通信双方身份可信的前提下，可以防止数据在传输过程中被窃取或篡改。同时，依赖于API网关的多种安全保护机制，也为后端服务技术实现时在安全方面的投入减轻压力。
3. 支持服务熔断设置，根据熔断规则和熔断执行自动执行熔断策略，同时支持线上调试，比如Mock方式，能够更加方便API服务上线发布和测试操作。
4. 提供多种协议的接入、转换与代理功能，比如常见的接口协议RESTful、WebSocket、Dubbo、WebService、独立文件传输等协议，这也为后端服务的混合通信协议提供了可选择性。面向外部合作伙伴或第三方厂商通常提供基于RESTful或WebService形式的API，但后端服务内部可以在不同的业务部门或项目组之间使用不同的技术栈，比如RESTful、GraphQL、Dubbo等，而不用担心外部调用的不兼容性。