接口安全问题及解决方案

╰半夏微凉° 2023-03-12 07:18 19阅读 0赞

1.  数据在网络中传输，中间会经历无数路由器，而每个路由器都可以抓包。
2.  为防止被窃取需要加密，有对称加密和非对称加密。

对称加密：两个密钥一样。（安全隐患，密钥会被泄露）
    非对称加密：密钥不一样。非对称更安全，性能低。
    如果黑客拿到密文，也没啥用，因为密钥他不知道。
    加密（对称加密DES,AES，非对称加密RSA）,
    
    加解密：https://www.sojson.com/encrypt.html，可以测试我们java加解密正确否，和外部调试。

对称和非对称加密应用的典型场景：https。

### https原理 ###

传输内容用对称加密，证书验证阶段用非对称加密
    
    为什么数据传输是用对称加密?
    首先，非对称加密的加解密效率是非常低的，而 HTTP 的应用场景中通常端与端之间存在大量的交互，非对称加密的效率是无法接受的。
    另外，在 HTTPS 的场景中只有服务端保存了私钥，一对公私钥只能实现单向的加解密，所以 HTTPS 中内容传输加密采取的是对称加密，而不是非对称加密。
    
    
    如果证书不是CA颁发的。会发生中间人攻击。
    
    为什么需要 CA 认证机构颁发证书? 在win控制面板中搜索证书，就会有。
    本地负责证书的认证。
    
    HTTP 协议被认为不安全是因为传输过程容易被监听者勾线监听、伪造服务器，而 HTTPS 协议主要解决的便是网络传输的安全性问题。
    
    首先我们假设不存在认证机构，任何人都可以制作证书，这带来的安全风险便是经典的“中间人攻击”问题。
    
    证书也可以自己颁发。自己生成得证书一般都提示风险。

解决办法：https

再退一步，数据密文被窃取后，黑客拿着原来的密文，继续访问。怎么办？

过期时间  
加密内容是：（有效信息+时间戳），时间的有效期，看自己业务情况。越小越好。（没有绝对的安全）

解密后：截取掉后13位。分成： 有效信息+时间戳。判断时间戳是否在自己设置的时间范围内。

如果被人拿到内容，别人在进行访问，也还是可以的。如何处理？

建立密文黑名单，如果此密文被用过了，则不能用了。降低了性能，换来了安全。

用set做个例子。生产环境，应该放到redis的set中。

别人篡改数据。用签名，利用散列加密，区块链中也有应用，相同的值，生成得hash相同，不同的值hash有可能相同，概率极低，反正知道hash值，无法推断出 原值。加上一个sign=xxx（也成校验位），加盐（盐不在网络中传输）。

sign=md5（(参数=参数值&参数=参数值+盐)）

md5 结果是固定长度字符串，不可逆。但是现在已经能被碰撞，有网站专门收集。

Hash，一般翻译做"散列"，也有直接音译为"哈希"的，就是把任意长度的输入，变换成固定长度的输出，该输出就是散列值。这种转换是一种压缩映射，也就是，散列值的空间通常远小于输入的空间，不同的输入可能会散列成相同的输出，而不可能从散列值来唯一的确定输入值。简单的说就是一种将任意长度的消息压缩到某一固定长度的消息摘要的函数。  
MD5与SHA1都是Hash算法，MD5摘要是128位的，SHA1摘要是160位的，MD5比SHA1快，SHA1比MD5强度高。  
网页端。token(服务端存储，客户端存储)。此方案存在的问题：

每个接口，都需要带token，对后台业务开发侵入性太大。用拦截器，统一处理。

**对前端：用cookie和session。**

1、用https保证通道安全。去申请证书。  
2、为了减少敏感信息暴露，用token代替用户名和密码等，无token用户不能使用服务。  
3、请求中携带：参数，timestamp，token,sign(md5(参数字母排序+加盐))   
4、timestamp 有有效期，如果被人篡改，超时无效。  
5、签名，签名的黑名单。防止重复请求。

JWT(JSON Web Token)  
两个原因：

由于token，需要和用户做对应，会增加服务端存储负担。所以有了无状态的jwt。  
集群中要进行session共享。需要将session放到一个公共地方去，比如db。如果db挂了。咋整。  
JWT是一种基于JSON的令牌安全验证(在某些特定的场合可以替代Session或者Cookie)

JWT组成：

**1.头部信息(header)**  
    作用:指定该JWT使用的签名

{
         "alg": "HS256",// 签名算法
         "typ": "JWT" //token类型    
     }

将上面的json，用Base64URL 算法转成字符串，即为header。

**2.消息体，也就是负载，java中用Claims(playload)**

{
    "iss" (issuer)：签发人
    "exp" (expiration time)：过期时间
    "sub" (subject)：主题,一般用用户id
    "aud" (audience)：受众
    "nbf" (Not Before)：生效时间
    "iat" (Issued At)：签发时间
    "jti" (JWT ID)：编号
    }

这个 JSON 对象也要使用 Base64URL 算法转成字符串。  
作用:JWT的请求数据，

**3.签名( signature)**  
Signature 部分是对前两部分的签名，防止数据篡改。  
需要指定一个密钥（secret）。这个密钥只有服务器才知道，不能泄露给用户。然后，使用 Header 里面指定的签名算法（默认是 HMAC SHA256），按照下面的公式产生签名。  
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload),secret)

最终：把 Header、Payload、Signature 三个部分拼成一个字符串，每个部分之间用"点"（.）分隔，就可以返回给用户。  
header.payload.signature  
demo：

JwtUtil

一般将jwt值放在：header中的Authorization中。设备码（或者ip，有时候我们换个wifi，银行客户端都提示网络环境改变，需要重新登录）也放header中。