性能文章>保证接口数据安全的10种方案>

保证接口数据安全的10种方案原创

254434

前言

大家好呀,我是捡田螺的小男孩。

我们日常开发中,如何保证接口数据的安全性呢?个人觉得,接口数据安全的保证过程,主要体现在这几个方面:一个就是数据传输过程中的安全,还有就是数据到达服务端,如何识别数据,最后一点就是数据存储的安全性。今天跟大家聊聊保证接口数据安全的10个方案。

8DE44133-0700-41D3-94C7-F411A7514347.png

1.数据加密,防止报文明文传输。

我们都知道,数据在网络传输过程中,很容易被抓包。如果使用的是http协议,因为它是明文传输的,用户的数据就很容易被别人获取。所以需要对数据加密。

1.1 数据如何加密呢?

常见的实现方式,就是对关键字段加密。比如,你一个登录的接口,你可以对密码加密。一般用什么加密算法呢?简单点可以使用对称加密算法(如AES)来加解密,或者哈希算法处理(如MD5)。

什么是对称加密:加密和解密使用相同密钥的加密算法。

EA6B3277-BB93-4D7D-96D5-45E34B948B71.png


非对称加密:非对称加密算法需要两个密钥(公开密钥和私有密钥)。公钥与私钥是成对存在的,如果用公钥对数据进行加密,只有对应的私钥才能解密。


更安全的做法,就是用非对称加密算法(如RSA或者SM2),公钥加密,私钥解密。

A32062FA-93FF-498C-8211-EDB984F94DF5.png


如果你想对所有字段都加密的话,一般都推荐使用https协议。https其实就是在http和tcp之间添加一层加密层SSL。

1.2 小伙伴们,是否还记得https的原理呢?

面试也经常问的,如下:

75678D32-11F1-427E-806B-EE75FB81959B.png


1、客户端发起Https请求,连接到服务器的443端口。
2、服务器必须要有一套数字证书(证书内容有公钥、证书颁发机构、失效日期等)。
3、服务器将自己的数字证书发送给客户端(公钥在证书里面,私钥由服务器持有)。
4、客户端收到数字证书之后,会验证证书的合法性。如果证书验证通过,就会生成一个随机的对称密钥,用证书的公钥加密。
5、客户端将公钥加密后的密钥发送到服务器。
6、服务器接收到客户端发来的密文密钥之后,用自己之前保留的私钥对其进行非对称解密,解密之后就得到客户端的密钥,然后用客户端密钥对返7、回数据进行对称加密,酱紫传输的数据都是密文啦。
8、服务器将加密后的密文返回到客户端。

客户端收到后,用自己的密钥对其进行对称解密,得到服务器返回的数据。

日常业务呢,数据传输加密这块的话,用https就可以啦,如果安全性要求较高的,比如登陆注册这些,需要传输密码的,密码就可以使用RSA等非对称加密算法,对密码加密。如果你的业务,安全性要求很高,你可以模拟https这个流程,对报文,再做一次加解密。

2. 数据加签验签

数据报文加签验签,是保证数据传输安全的常用手段,它可以保证数据在传输过程中不被篡改。以前我做的企业转账系统,就用了加签验签。

2.1 什么是加签验签呢?

数据加签:用Hash算法(如MD5,或者SHA-256)把原始请求参数生成报文摘要,然后用私钥对这个摘要进行加密,就得到这个报文对应的数字签名sign(这个过程就是加签)。通常来说呢,请求方会把数字签名和报文原文一并发送给接收方。

01656237-0DA6-4AF1-92EC-BD09E26431F3.png


验签:接收方拿到原始报文和数字签名(sign)后,用同一个Hash算法(比如都用MD5)从报文中生成摘要A。另外,用对方提供的公钥对数字签名进行解密,得到摘要B,对比A和B是否相同,就可以得知报文有没有被篡改过。

770E31A4-30D7-4735-ACA8-51CD68D644EC.png


其实加签,我的理解的话,就是把请求参数,按照一定规则,利用hash算法+加密算法生成一个唯一标签sign。验签的话,就是把请求参数按照相同的规则处理,再用相同的hash算法,和对应的密钥解密处理,以对比这个签名是否一致。


再举个例子,有些小伙伴是这么实现的,将所有非空参数(包含一个包AccessKey,唯一的开发者标识)按照升序,然后再拼接个SecretKey(这个仅作本地加密使用,不参与网络传输,它只是用作签名里面的),得到一个stringSignTemp的值,最后用MD5运算,得到sign。


服务端收到报文后,会校验,只有拥有合法的身份AccessKey和签名Sign正确,才放行。这样就解决了身份验证和参数篡改问题,如果请求参数被劫持,由于劫持者获取不到SecretKey(仅作本地加密使用,不参与网络传输),他就无法伪造合法的请求啦

2.2 有了https等加密数据,为什么还需要加签验签

有些小伙伴可能有疑问,加签验签主要是防止数据在传输过程中被篡改,那如果都用了https下协议加密数据了,为什么还会被篡改呢?为什么还需要加签验签呢?


数据在传输过程中被加密了,理论上,即使被抓包,数据也不会被篡改。但是https不是绝对安全的哦。可以看下这个文章:可怕,原来 HTTPS 也没用。还有一个点:https加密的部分只是在外网,然后有很多服务是内网相互跳转的,加签也可以在这里保证不被中间人篡改,所以一般转账类安全性要求高的接口开发,都需要加签验签

3.token授权认证机制

日常开发中,我们的网站或者APP,都是需要用户登录的。那么如果是非登录接口,是如何确保安全,如何确认用户身份的呢?可以使用token授权机制。


3.1 token的授权认证方案

token的授权认证方案:用户在客户端输入用户名和密码,点击登录后,服务器会校验密码成功,会给客户端返回一个唯一值token,并将token以键值对的形式存放在缓存(一般是Redis)中。后续客户端对需要授权模块的所有操作都要带上这个token,服务器端接收到请求后,先进行token验证,如果token存在,才表明是合法请求。


token登录授权流程图如下:

671BEF24-7FDF-47E6-A5E0-7940C91011DA.png


1、用户输入用户名和密码,发起登录请求

2、服务端校验密码,如果校验通过,生成一个全局唯一的token。

3、将token存储在redis中,其中key是token,value是userId或者是用户信息,设置一个过期时间。

4、把这个token返回给客户端

5、用户发起其他业务请求时,需要带上这个token

6、后台服务会统一拦截接口请求,进行token有效性校验,并从中获取用户信息,供后续业务逻辑使用。如果token不存在,说明请求无效。

3.2 如何保证token的安全?token被劫持呢?

我们如何保证token的安全呢?


比如说,我如果拿到token,是不是就可以调用服务器端的任何接口?可以从这几个方面出发考虑:

  • token设置合理的有效期
  • 使用https协议
  • token可以再次加密
  • 如果访问的是敏感信息,单纯加token是不够的,通常会再配置白名单

说到token,有些小伙伴们可能会想起jwt,即(JSON Web Token),其实它也是token的一种。有兴趣的小伙伴可以去了解一下哈。

4. 时间戳timestamp超时机制

数据是很容易抓包的,假设我们用了https和加签,即使中间人抓到了数据报文,它也看不到真实数据。但是有些不法者,他根本不关心真实的数据,而是直接拿到抓取的数据包,进行恶意请求(比如DOS攻击),以搞垮你的系统。
我们可以引入时间戳超时机制,来保证接口安全。就是:用户每次请求都带上当前时间的时间戳timestamp,服务端接收到timestamp后,解密,验签通过后,与服务器当前时间进行比对,如果时间差大于一定时间 (比如3分钟),则认为该请求无效。

5.timestamp+nonce方案防止重放攻击

时间戳超时机制也是有漏洞的,如果是在时间差内,黑客进行的重放攻击,那就不好使了。可以使用timestamp+nonce方案。
nonce指唯一的随机字符串,用来标识每个被签名的请求。我们可以将每次请求的nonce参数存储到一个“set集合”中,或者可以json格式存储到数据库或缓存中。每次处理HTTP请求时,首先判断该请求的nonce参数是否在该“集合”中,如果存在则认为是非法请求。
然而对服务器来说,永久保存nonce的代价是非常大的。可以结合timestamp来优化。因为timstamp参数对于超过3min的请求,都认为非法请求,所以我们只需要存储3min的nonce参数的“集合”即可。

6. 限流机制

如果用户本来就是就是真实用户,他恶意频繁调用接口,想搞垮你的系统呢?这种情况就需要接入限流了。
常用的限流算法有令牌桶和漏桶算法。大家可以看下我的这篇文章,面试必备:4种经典限流算法讲解
可以使用Guava的RateLimiter单机版限流,也可以使用Redis分布式限流,还可以使用阿里开源组件sentinel限流。比如说,一分钟可以接受多少次请求。

7. 黑名单机制

如果发现了真实用户恶意请求,你可以搞个黑名单机制,把该用户拉黑。一般情况,会有些竞争对手,或者不坏好意的用户,想搞你的系统的。所以,为了保证安全,一般我们的业务系统,需要有个黑名单机制。对于黑名单发起的请求,直接返回错误码好了。

8.白名单机制

有了黑名单机制,也可以搞个白名单机制啦。以前我负责的企业转账系统,如果有外面的商户要接入我们的系统时,是需要提前申请网络白名单的。那时候运维会申请个IP网络白名单,只有白名单里面的请求,才可以访问我们的转账系统。

9.数据脱敏掩码

对于密码,或者手机号、身份证这些敏感信息,一般都需要脱敏掩码再展示的,如果是密码,还需要加密再保存到数据库。
对于手机号、身份证信息这些,日常开发中,在日志排查时,看到的都应该是掩码的。目的就是尽量不泄漏这些用户信息,虽然能看日志的只是开发和运维,但是还是需要防一下,做掩码处理。
对于密码保存到数据库,我们肯定不能直接明文保存。最简单的也需要MD5处理一下再保存,Spring Security中的 BCryptPasswordEncoder也可以,它的底层是采用SHA-256 +随机盐+密钥对密码进行加密,而SHA和MD系列是一样的,都是hash摘要类的算法。

10. 数据参数一些合法性校验。

接口数据的安全性保证,还需要我们的系统,有个数据合法性校验,简单来说就是参数校验,比如身份证长度,手机号长度,是否是数字等等。
总结

本文给大家介绍了10种保证接口数据安全的方案。小伙伴们,如有还有其他方案的话,可以在留言区评论哈,一起交流学习。

如果这篇文章对您有所帮助,或者有所启发的话,可以关注公众号捡田螺的小男孩,您的支持是我坚持写作最大的动力。求一键三连:点赞、转发、在看。

💥看到这里的你,如果对于我写的内容很感兴趣,有任何疑问,欢迎在下面留言📥,会第一次时间给大家解答,谢谢!

 

请先登录,查看3条精彩评论吧
快去登录吧,你将获得
  • 浏览更多精彩评论
  • 和开发者讨论交流,共同进步

为你推荐

从一起GC血案谈到反射原理
前言 首先回答一下提问者的问题。这主要是由于存在大量反射而产生的临时类加载器和 ASM 临时生成的类,这些类会被保留在 Metaspace,一旦 Metaspace 即将满的时候,就会触发 Fu
类初始化导致死锁
一张图简单描述死锁 如上图,Thread1 拿到了 object1,Thread2 拿到了 object2,但是现在 Thread1 需要拿到 object2 的锁才能继续往下,Thread2 又要拿到 object1 才能继续往下
高并发服务优化篇:详解RPC的一次调用过程
只要涉及到分布式服务,就绕不开RPC调用。RPC是什么,我认为大部分同学都能说出个一二三。那么RPC一次调用,到底经历了哪些过程?一直在说RPC耗时优化,那到底时间耗在了哪里? 本篇带大家一起来梳理清
Java反射及性能
现如今的java工程中,反射的使用无处无在。无论是设计模式中的代理模式,还是红透半边天的Spring框架中的IOC,AOP等等,都存在大量反射的影子。我们今天不探讨框架层面的内容,暂且认为90%的框架
从20s优化到500ms,我用了这三招
前言接口性能问题,对于从事后端开发的同学来说,是一个绕不开的话题。想要优化一个接口的性能,需要从多个方面着手。其实,我之前也写过一篇接口性能优化相关的文章《聊聊接口性能优化的11个小技巧》,发表之后在全网广受好评,感兴趣的小伙们可以仔细看看。本文将会接着接口性能优化这个话题,从实战的角度出发,聊
保证接口数据安全的10种方案
前言大家好呀,我是捡田螺的小男孩。我们日常开发中,如何保证接口数据的安全性呢?个人觉得,接口数据安全的保证过程,主要体现在这几个方面:一个就是数据传输过程中的安全,还有就是数据到达服务端,如何识别数据,最后一点就是数据存储的安全性。今天跟大家聊聊保证接口数据安全的10个方案。1.数据加密,防
这样优化Spring Boot,启动速度快到飞起!
微服务用到一时爽,没用好就呵呵啦,特别是对于服务拆分没有把控好业务边界、拆分粒度过大等问题,某些 Spring Boot 启动速度太慢了,可能你也会有这种体验,这里将探索一下关于 Spring Boot 启动速度优化的一些方方面面。启动时间分析IDEA 自带集成了 async-profile 工
接口流量突增,如何做好性能优化?
大家好,我是树哥!对于提供接口服务的应用来说,很多都是用 SpringBoot 默认的 Servlet 容器 Tomcat。在一开始上线的时候,由于大多数流量较小,我们也并不会为 Tomcat 做专门的参数调整。但随着流量越来越大,应用的各项性能指标越来越差,此时我们大多数都会选择扩容。除了扩容
4
3