公司、个人开发的系统上线后,系统中 API 暴露到网络上会存在一定的安全风险,比如:爬虫、恶意访问、错误访问等。API没有安全性,用户可以任意注册即可无限次访问和调用API,且没有请求与特定用户数据关联的简单方法,就无法防止恶意用户的恶意请求等。
常用 API 接口安全措施如下几种:
(1)数据加密
数据在互联网传输过程很容易被抓包,如果直接传输,那么用户数据可能被其他人获取,导致系统安全性等问题,所以必须对数据加密。常见的做法是对关键字段加密,比如用户密码直接通过 md5 加密。
(2)数据签名
数据在传输过程中经过加密,理论上就算被抓包,也无法对数据进行篡改,但是我们一般加密的部分其实只是在外网,现在很多服务在内网中都需要经过很多服务跳转,如果被攻入内网,则可以在任意节点篡改数据,所以这里的加数据签名可以防止内网中数据被篡改。数据签名就是由发送者产生一段无法伪造的一段数字串,来保证数据在传输过程中不被篡改。md5算法是常用的数据签名算法,其原理是将需要提交的数据通过某种方式组合成一个字符串,然后通过md5算法生成一段加密字符串,这段加密字符串就是数据包的签名。为保证安全性,最后的密钥会在客户端和服务端各备一份。
(3)添加时间戳
经过如上的加密,加签处理,就算拿到数据也不能看到真实的数据;但是有些攻击者不关心真实的数据,而是直接拿到抓取的数据包做恶意请求,以达到攻击的目的。我们可以使用时间戳机制,在每次请求的时候加入当前的时间,服务器端会拿到当前时间和消息中的时间相减,看看是否在一个固定的时间范围内,超过时间差的请求就视为非法请求。
(4)限流机制
如果有用户出现频繁调用接口的情况;这种情况需要给相关用户做限流处理,常用的限流算法包括:令牌桶限流,漏桶限流,计数器限流。令牌桶限流:系统以一定速率向桶中放入令牌,填满了就丢弃令牌;请求来时会先从桶中取出令牌,如果能取到令牌,则可以继续完成请求,否则等待或者拒绝服务。令牌桶允许一定程度突发流量,只要有令牌就可以处理,支持一次拿多个令牌。漏桶限流:按照固定常量速率流出请求,流入请求速率任意,当请求数超过桶的容量时,新的请求等待或者拒绝服务,因此漏桶算法可以强制限制数据的传输速度。计数器限流:这是一种比较简单粗暴的算法,主要用来限制总并发数,比如数据库连接池、线程池、秒杀的并发数;计数器限流只要一定时间内的总请求数超过设定的阀值则进行限流。
(5)黑名单限流
如果此用户进行过很多非法操作,或者说专门有一个中黑系统,经过分析之后直接将此用户列入黑名单,所有请求直接返回错误码。我们可以给每个用户设置一个状态比如包括:初始化状态,正常状态,中黑状态,关闭状态等等;或者我们直接通过分布式配置中心,直接保存黑名单列表,每次检查是否在列表中即可。
常用的安全防范有以下方式:API Keys、Basic Auth、Hmac、OAuth。本文主要讨论基于OAuth协议的API安全验证。本文主要介绍基于OAuth协议(Client Credentials)的实践。
下图是一个笔者亲身经历的一个例子,到目前为止,运转良好。API服务服务网关采用基于Kong API网关的实现,认证中心是实现OAuth 2.0协议的权限认证系统,服务提供系统设置基于IP的白名单访问。
OAuth 2.0是一种用户验证和授权用户的流行方法,此方法依赖于身份验证服务器和API服务器进行通信以授予访问权限,在笔者的前面的文章中已经详细阐述OAuth的原理,在这里就不在赘述,想看的读者可以翻看历史记录找到该篇文章。下图标注了详细的流程。
JWT(全称:Json Web Token)是一个开放标准(RFC 7519),它定义了一种紧凑的、自包含的方式,用于作为JSON对象在各方之间安全地传输信息。该信息可以被验证和信任,因为它是数字签名的。如有读者想了解详细的JWT规范,可以访问RFC7519的官方网站:https://datatracker.ietf.org/doc/html/rfc7519。
JWT由3部分组成:标头(Header)、有效载荷(Payload)和签名(Signature)。在传输的时候,会将JWT的3部分分别进行Base64编码后用。进行连接形成最终传输的字符串。JWTString=Base64(Header).Base64(Payload).HMACSHA256(base64UrlEncode(header)+"."+base64UrlEncode(payload),secret)。
下图为一个简单的JWT的解码出来的例子:
以上图为例,JWT的数据结构一般是一个三段式的字符,以“.”隔开:xxxxx.yyyyy.zzzzz。
JWT第一部分是Header头部分,它是一个描述JWT元数据的Json对象,通常如下所示。alg属性表示签名使用的算法,默认为HMAC SHA256(写为HS256),typ属性表示令牌的类型,JWT令牌统一写为JWT。最后,使用Base64 URL算法将上述JSON对象转换为字符串保存。
JWT第二部分是Payload,也是一个Json对象,除了包含需要传递的数据,还有七个默认的字段供选择。分别是,iss:发行人、exp:到期时间、sub:主题、aud:用户、nbf:在此之前不可用、iat:发布时间、jti:JWT ID用于标识该JWT。也可以加上自定义字段。需要注意的是,默认情况下JWT是未加密的,任何人都可以解读其内容,因此如果一些敏感信息不要存放在此,以防信息泄露。JSON对象也使用Base64 URL算法转换为字符串保存。
JWT第三部分是Signature签名。是这样生成的,首先需要指定一个secret,该secret仅仅保存在服务器中,保证不能让其他用户知道。然后使用Header指定的算法对Header和Payload进行计算,然后就得出一个签名哈希。也就是Signature。
那么Application Server如何进行验证呢?可以利用JWT前两段,用同一套哈希算法和同一个secret计算一个签名值,然后把计算出来的签名值和收到的JWT第三段比较,如果相同则认证通过。
JWT的优点包括如下:JSON格式的通用性,所以JWT可以跨语言支持,比如JAVA、JavaScript、php、Node等等。可以利用Payload存储一些非敏感的信息。便于传输,JWT结构简单,字节占用小。不需要在服务端保存会话信息,易于应用的扩展。
下图是Kong认证的实际过程。
如果配置中允许OPTIONS请求,并且请求的方法确实是OPTIONS,放行。
如果配置中设置了匿名消费者,并且有凭证,放行。这里是为了实现多重认证,通过配置匿名消费者来实现逻辑或的认证,此时必须有其他认证插件,当其他认证插件通过,jwt插件就不再验证,若不设置匿名,则既要jwt验证也要其他认证插件验证。
先后从query params,request header中查找token(根据配置的变量),token的格式为\s*[Bb]earer\s+(.+),如果从query params找到就返回了,不会再根据request header找。
如果没有找到token,或者token格式不对,并且不允许匿名,返回401。
如果没有找到token,并且允许匿名,根据配置的匿名的id查询消费者,增加request header:X-Consumer-ID、X-Consumer-Username和X-Anonymous-Consumer=true,id是自动生成的,username是配置时填写的,设置这个消费者的凭证是nil,放行。
如果找到token,且格式合法,jwt解码这个token,验证token的 clAIm,消费者,签名验证,过期验证,全部通过后,同匿名一样,增加步骤5中的request header,并且清除X-Anonymous-Consumer这个header。
以下是Kong网关集成OAuth插件的例子,首先启用OAuth插件,然后在将插件添加到需要集成权限的Service上。
请求的时候只要在HTTP Header带上“Content-Type:application/json”和“Authorization: Bearer 认证中心申请的JWT令牌”即可访问到所需的资源。
Spring Cloud Gateway是Spring官方基于Spring 5.0、Spring Boot 2.0和Project Reactor等技术开发的网关,Spring Cloud Gateway旨在为微服务架构提供一种简单而有效的统一的API路由管理方式。Spring Cloud Gateway作为Spring Cloud生态系中的网关,目标是替代ZUUL,其不仅提供统一的路由方式,并且基于Filter链的方式提供了网关基本的功能,例如:安全,监控/埋点,和限流等。
使用Gateway全局过滤器获取JWT Token后进行用户认证及鉴权。下图为实现该过滤器的代码。
1、登录获取token
2、将token设置到Request Header后,访问资源服务
3、当没有token访问资源服务时就会返回401
最后讲讲JWT的缺点,任何技术都不是完美的,所以我们得用辩证思维去看待任何一项技术。安全性没法保证,所以jwt里不能存储敏感数据。因为jwt的payload并没有加密,只是用Base64编码而已。无法中途废弃。因为一旦签发了一个jwt,在到期之前始终都是有效的,如果用户信息发生更新了,只能等旧的jwt过期后重新签发新的jwt。
续签问题。当签发的jwt保存在客户端,客户端一直在操作页面,按道理应该一直为客户端续长有效时间,否则当jwt有效期到了就会导致用户需要重新登录。那么怎么为jwt续签呢?最简单粗暴就是每次签发新的jwt,但是由于过于暴力,会影响性能。如果要优雅一点,又要引入redis解决,但是这又把无状态的jwt硬生生变成了有状态的,违背了初衷。所以印证了那句话,没有最好的技术,只有适合的技术。感谢大家的阅读,希望看完之后能对你有所收获。
本文简单的讨论API权限认证,关于API的限流等,后续将持续分享其他内容。码字不易,欢迎关注、点赞、收藏。