https和接口签名、api接口安全

为什么有了https  还需要做签名验证?

当用户在浏览器当中加载受HTTPS保护的网站时,浏览器实际上只会验证两件事:网站是否提供了证书;证书是不是浏览器(操作系统)信任的根证书CA机构颁发的。实际上我们是在相信每个根CA机构都已尽全力来验证你要连接的服务器的身份。但是实际上有时候根CA机构会被骗。我们还相信每个根CA机构都能够保护自己的系统。但是实际上有时候根CA会被盗用。
安装个代理工具(fiddler)的证书,就可以用代理工具抓到https请求的内容,还可以篡改数据。
签名可以防止篡改数据,因为签名的密钥没有在网络中进行传输(服务器端线下颁发给客户端或者客户端自己输入的登陆密码作为密钥,甚至登陆使用的短信验证码也可以作为密钥)

https算法本质

https 采用 rsa+aes 结合
ras 为了 生成aes的密钥不被发现
aes 可以防止数据被偷窥

签名的作用

1、防止数据不被串改
如果aes的密钥被代理工具发现了(毕竟密钥会在网络中传输一次)导致数据被偷窥(获取到用户的登陆token), 例如黑客获取到了用户的token,在正常的客户端浏览器模拟此用户发送请求,此时签名防止数据不被串改,因为签名的密钥没有在网络中进行传输。
2、过滤很多无效请求
签名还能过滤很多无效请求 https 不保证传送的数据对系统是 “无害”,例如平台内部伪造支付请求(没有签名验证模块,无法甄别是否来源于商户),或者大量无效请求直接发送到业务服务器上。
3、防止内网中 https过后 的 http传输被篡改
签名可以防止内网中 https过后 的 http传输被篡改   签名HMAC是应用层采用的手段来保护数据安全,SSL/TLS是传输层保护数据的机密与数据安全。
总结就是签名可以兜底保证数据不被修改+过滤

如果只用签名 不用https

黑客可以获取到 用户发送的 签名信息和明文请求参数 以及签名算法 暴力破解出 签名的密钥
暴力破解需要时间,如果超过服务器设置token失效时间,则破解出来的密钥也失效了,万一被破解了 及时修改密钥或者 两者一起更换
所以目前最安全的是 https + 签名+token 过期(定期更换token或者密钥或者 两者一起更换) 保证接口安全

签名规则

1.已指定顺序拼接字符串 secret+method+param+token+timestamp+secret    签名规则:md5(secret+method+param+token+secret+timestamp)    此处算法可以使用 MD5、SHA、HMAC    param格式:
    1、参数排序
    将需要签名的内容根据参数名称进行排序,排序规则按照第一个字符的ASCII码值递增排序(字母升序排序),如果遇到相同字符则按照第二个字符的ASCII码递增排序,以此类推。将参数内容进行排序,可以保证签名、验签双方参数内容的一致性。
    为什么会产生不一致?
    签名方以 Json 格式将参数内容发送给验签方,验签方需要将 Json 格式的参数内容反序列化为对象,由于验签方可能使用不同的编程语言,不同的 Json 框架,所以会导致双方的参数顺序不一致。
    2、参数拼接
    将排序后的参数与其对应值,组合成“参数=参数值”的格式,并且把这些参数用&字符连接起来,此时生成的字符串为待摘要字符串。
2.使用MD5进行加密,在转化成大写

签名的目的

  1. 防串改         因为param封装到 sign里面了  如果被修改  sign就不通过
    2. 防伪造         因为secret在客户端,不容易被恶意获取
    3. 防重复使用签名  基于timestamp  这个实际戳可以设置10分钟后小于系统时间就失效  关于服务器和客户端时间不一致差额可以服务器返回header包含一个时间和客户端时间差额下次客户端请求加上差额
        (推荐)此处可以另外加入流水号nonce字段(防止重复提交 可以为时间戳加上随机数值),至少为10位。针对查询接口,流水号只用于日志落地,便于后期日志核查。 针对办理类接口需校验流水号在有效期内的唯一性,以避免重复请求。

    防重放的另一种思路

    客户端第一次访问时,将签名sign存放到服务器的Redis中,超时时间设定为跟时间戳的超时时间一致,二者时间一致可以保证无论在timestamp限定时间内还是外 URL都只能访问一次,如果被非法者截获,使用同一个URL再次访问,如果发现缓存服务器中已经存在了本次签名,则拒绝服务。如果在缓存中的签名失效的情况下,有人使用同一个URL再次访问,则会被时间戳超时机制拦截,这就是为什么要求sign的超时时间要设定为跟时间戳的超时时间一致。拒绝重复调用机制确保URL被别人截获了也无法使用(如抓取数据)。

密钥泄露怎么办(特指两个服务器端访问使用的接口密钥)

当您遇到如下情况:
1、您的某一个密钥发生了泄露,您可能想要保留该密钥与 API 的绑定关系,但是想要修改密钥的 Key 和 Secret。
2、当您操作将密钥应用于 API 时,可能该 API 已经绑定了某个密钥,需要替换密钥。
以上两种情况都建议按照下面的流程来操作:
先在后端同时支持两个密钥:原来的密钥和即将修改或替换的密钥,确保切换过程中的请求能够通过签名验证,不受修改或替换的影响。
后端配置完备后,完成修改,确定新 Key 和 Secret 生效后再将之前已泄露或废弃的密钥删除。

开发者首页 wechat
欢迎您扫一扫上面的微信公众号