精华内容
下载资源
问答
  • java 如何保证接口安全性

    万次阅读 2017-12-07 09:55:45
    在开发过程中,肯定会有和第三方或者app端的接口调用。在调用的时候,如何来保证非法链接或者恶意攻击呢? 1.签名  根据用户名或者用户id,结合用户的ip或者设备号,生成一个token。在请求后台,后台获取http的...

      在开发过程中,肯定会有和第三方或者app端的接口调用。在调用的时候,如何来保证非法链接或者恶意攻击呢?

    1.签名

        根据用户名或者用户id,结合用户的ip或者设备号,生成一个token。在请求后台,后台获取http的head中的token,校验是否合法(和数据库或者redis中记录的是否一致,在登录或者初始化的时候,存入数据库/redis)

    在使用Base64方式的编码后,Token字符串还是有20多位,有的时候还是嫌它长了。由于GUID本身就有128bit,在要求有良好的可读性的前提下,很难进一步改进了。那我们如何产生更短的字符串呢?还有一种方式就是较少Token的长度,不用GUID,而采用一定长度的随机数,例如64bit,再用Base64编码表示:

        var rnd = new Random();
        var tokenData = userIp+userId;
        rnd.NextBytes(tokenData);
        var token = Convert.ToBase64String(tokenData).TrimEnd('=');

    由于这里只用了64bit,此时得到的字符串为Onh0h95n7nw的形式,长度要短一半。这样就方便携带多了。但是这种方式是没有唯一性保证的。不过用来作为身份认证的方式还是可以的(如网盘的提取码)。

    2.加密

       客户端和服务器都保存一个秘钥,每次传输都加密,服务端根据秘钥解密。

       

    客户端:

        1、设置一个key(和服务器端相同)

        2、根据上述key对请求进行某种加密(加密必须是可逆的,以便服务器端解密)

        3、发送请求给服务器

    服务器端:

        1、设置一个key

        2、根据上述的key对请求进行解密(校验成功就是「信任」的客户端发来的数据,否则拒绝响应)

        3、处理业务逻辑并产生结果

        4、将结果反馈给客户端

    3.第三方支持

      比如spring security-oauth 

    有兴趣的,可以参考这篇帖子

    http://wwwcomy.iteye.com/blog/2230265

    展开全文
  • APP、前后端分离项目都采用API接口形式与服务器进行数据通信,传输的数据被偷窥、被抓包、被伪造时有发生,那么如何设计一套比较安全的API接口方案呢? 一般的解决方案如下: 1、Token授权认证,防止未授权用户获取...

    APP、前后端分离项目都采用API接口形式与服务器进行数据通信,传输的数据被偷窥、被抓包、被伪造时有发生,那么如何设计一套比较安全的API接口方案呢?

    一般的解决方案如下:

    1、Token授权认证,防止未授权用户获取数据;

    2、时间戳超时机制;

    3、URL签名,防止请求参数被篡改;

    4、防重放,防止接口被第二次请求,防采集;

    5、采用HTTPS通信协议,防止数据明文传输;

    一、Token授权认证

    HTTP协议是无状态的,一次请求结束,连接断开,下次服务器再收到请求,它就不知道这个请求是哪个用户发过来的,但是对我们有权限访问限制的模块而言,它是需要有状态管理的,以便服务端能够准确的知道HTTP请求是哪个用户发起的,从而判断他是否有权限继续这个请求。

    Token的设计方案是用户在客户端使用用户名和密码登录后,服务器会给客户端返回一个Token,并将Token以键值对的形式存放在缓存(一般是Redis)中,后续客户端对需要授权模块的所有操作都要带上这个Token,服务器端接收到请求后进行Token验证,如果Token存在,说明是授权的请求。

    Token生成的设计要求:

    1、应用内一定要唯一,否则会出现授权混乱,A用户看到了B用户的数据;

    2、每次生成的Token一定要不一样,防止被记录,授权永久有效;

    3、一般Token对应的是Redis的key,value存放的是这个用户相关缓存信息,比如:用户的id;

    4、要设置Token的过期时间,过期后需要客户端重新登录,获取新的Token,如果Token有效期设置较短,会反复需要用户登录,体验比较差,我们一般采用Token过期后,客户端静默登录的方式,当客户端收到Token过期后,客户端用本地保存的用户名和密码在后台静默登录来获取新的Token,还有一种是单独出一个刷新Token的接口,但是一定要注意刷新机制和安全问题;

    根据上面的设计方案要求,我们很容易得到Token=md5(用户ID+登录的时间戳+服务器端秘钥)这种方式来获得Token,因为用户ID是应用内唯一的,登录的时间戳保证每次登录的时候都不一样,服务器端秘钥是配置在服务器端参与加密的字符串(即:盐),目的是提高Token加密的破解难度,注意一定不要泄漏;

    二、时间戳超时机制

    客户端每次请求接口都带上当前时间的时间戳timestamp,服务端接收到timestamp后跟当前时间进行比对,如果时间差大于一定时间(比如:1分钟),则认为该请求失效。时间戳超时机制是防御DOS攻击的有效手段。

    例:http://url/getInfo?id=1&timetamp=1559396263

    三、URL签名

    写过支付宝或微信支付对接的同学肯定对URL签名不陌生,我们只需要将原本发送给server端的明文参数做一下签名,然后在server端用相同的算法再做一次签名,对比两次签名就可以确保对应明文的参数有没有被中间人篡改过。

    首先我们需要分配给客户端一个私钥用于URL签名加密,一般的签名算法如下:

    1、首先对通信的参数按key进行字母排序放入数组中(一般请求的接口地址也要参与排序和签名,那么需要额外添加url=http://url/getInfo这个参数);

    2、对排序完的数组键值对用&进行连接,形成用于加密的参数字符串;

    3、在加密的参数字符串前面或者后面加上私钥,然后用md5进行加密,得到sign,然后随着请求接口一起传给服务器。

    例如:

    http://url/getInfo?id=1&timetamp=1559396263&sign=e10adc3949ba59abbe56e057f20f883e

    服务器端接收到请求后,用同样的算法获得服务器的sign,对比客户端的sign是否一致,如果一致请求有效;

    注意:对于客户端的私钥一定要妥善处理好,不能被非法者拿到,如果针对于H5的项目,H5保存私钥是个问题,目前没有更好的方法,也是一致困扰我的问题,如果大家有更好的方法可以留言一起探讨。

    四、防重放

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

    以上方案流程如下:

    1、客户端通过用户名密码登录服务器并获取Token;

    2、客户端生成时间戳timestamp,并将timestamp作为其中一个参数;

    3、客户端将所有的参数,包括Token和timestamp按照自己的签名算法进行排序加密得到签名sign

    4、将token、timestamp和sign作为请求时必须携带的参数加在每个请求的URL后边

    例:

    http://url/request?token=h40adc3949bafjhbbe56e027f20f583a&timetamp=1559396263&sign=e10adc3949ba59abbe56e057f20f883e

    5、服务端对token、timestamp和sign进行验证,只有在token有效、timestamp未超时、缓存服务器中不存在sign三种情况同时满足,本次请求才有效;

    五、采用HTTPS通信协议

    众所周知HTTP协议是以明文方式发送内容,不提供任何方式的数据加密,如果攻击者截取了客户端和服务器之间的传输报文,就可以直接读懂其中的信息,因此HTTP协议不适合传输一些敏感信息,比如信用卡号、密码等。

    为了解决HTTP协议的这一缺陷,需要使用另一种协议:安全套接字层超文本传输协议HTTPS,为了数据传输的安全,HTTPS在HTTP的基础上加入了SSL协议,SSL依靠证书来验证服务器的身份,并为客户端和服务器之间的通信加密。

    HTTPS也不是绝对安全的,如下图所示为中间人劫持攻击,中间人可以获取到客户端与服务器之间所有的通信内容。

    中间人截取客户端发送给服务器的请求,然后伪装成客户端与服务器进行通信;将服务器返回给客户端的内容发送给客户端,伪装成服务器与客户端进行通信。
    通过这样的手段,便可以获取客户端和服务器之间通信的所有内容。
    使用中间人攻击手段,必须要让客户端信任中间人的证书,如果客户端不信任,则这种攻击手段也无法发挥作用。

    2 针对安全性要求一般的app,可采用通过校验域名,证书有效性、证书关键信息及证书链的方式;

    总结:所有的安全措施都用上的话有时候难免太过复杂,在实际项目中需要根据自身情况作出取舍,比如可以只使用签名机制就可以保证信息不会被篡改,或者定向提供服务的时候只用Token机制就可以了,如何取舍,全看项目实际情况和对接口安全性的要求。

    转载于:https://www.cnblogs.com/xingxia/p/API_secrute.html

    展开全文
  • 接口如何保证 API 的安全性

    千次阅读 2021-05-08 11:51:27
    接口如何保证 API 的安全性的问题 1. 接口协议采用 Https 协议 SSL+证书 443 2. 使用 MD5 对我们的接口实现验证签名 防止接口参数不能能篡改 移动 App 项目 3. 对我们的数据实现加密 rsa 非对称加密 不能别人...

    接口如何保证 API 的安全性的问题

    1. 接口协议采用 Https 协议 SSL+证书 443

    2. 使用 MD5 对我们的接口实现验证签名 防止接口参数不能能篡改 移动 App 项目

    3. 对我们的数据实现加密 rsa 非对称加密 不能别人看到明文的数据

    4. 使用 nginx 或者网关、整合阿里巴巴 sentinel 对 api 接口实现限流、黑名单和白名单机制

    5. 使用网关对整个微服务参数的入口实现防止 xss、sql 注入的问题

    6. 定期对我们代码实现 bug 扫描、每周代码实现评估、遵循 java 开发规范

    展开全文
  • 因为服务没用户系统,但是我只想让有我Token的人访问(一个微信小程序)。 Token放在请求头Authorization 里 我就想问下,这个Token会被别人抓到吗? ...被别人抓到这个Token不就没什么意义了么。...
  • 如何保证API接口安全

    千次阅读 2020-01-08 16:30:43
    APP、前后端分离项目都采用API接口形式与服务器进行数据通信,传输的数据被偷窥、被抓包、被伪造时有发生,那么如何设计一套比较安全的API接口方案呢? 一般的解决方案如下: 1、Token授权认证,防止未授权用户...

     https://www.cnblogs.com/xingxia/p/API_secrute.html

    APP、前后端分离项目都采用API接口形式与服务器进行数据通信,传输的数据被偷窥、被抓包、被伪造时有发生,那么如何设计一套比较安全的API接口方案呢?
    
    一般的解决方案如下:
    
    1、Token授权认证,防止未授权用户获取数据;
    
    2、时间戳超时机制;
    
    3、URL签名,防止请求参数被篡改;
    
    4、防重放,防止接口被第二次请求,防采集;
    
    5、采用HTTPS通信协议,防止数据明文传输;
    
    一、Token授权认证
    
    HTTP协议是无状态的,一次请求结束,连接断开,下次服务器再收到请求,它就不知道这个请求是哪个用户发过来的,但是对我们有权限访问限制的模块而言,它是需要有状态管理的,以便服务端能够准确的知道HTTP请求是哪个用户发起的,从而判断他是否有权限继续这个请求。
    
    Token的设计方案是用户在客户端使用用户名和密码登录后,服务器会给客户端返回一个Token,并将Token以键值对的形式存放在缓存(一般是Redis)中,后续客户端对需要授权模块的所有操作都要带上这个Token,服务器端接收到请求后进行Token验证,如果Token存在,说明是授权的请求。
    
    Token生成的设计要求:
    
    1、应用内一定要唯一,否则会出现授权混乱,A用户看到了B用户的数据;
    
    2、每次生成的Token一定要不一样,防止被记录,授权永久有效;
    
    3、一般Token对应的是Redis的key,value存放的是这个用户相关缓存信息,比如:用户的id;
    
    4、要设置Token的过期时间,过期后需要客户端重新登录,获取新的Token,如果Token有效期设置较短,会反复需要用户登录,体验比较差,我们一般采用Token过期后,客户端静默登录的方式,当客户端收到Token过期后,客户端用本地保存的用户名和密码在后台静默登录来获取新的Token,还有一种是单独出一个刷新Token的接口,但是一定要注意刷新机制和安全问题;
    
    根据上面的设计方案要求,我们很容易得到Token=md5(用户ID+登录的时间戳+服务器端秘钥)这种方式来获得Token,因为用户ID是应用内唯一的,登录的时间戳保证每次登录的时候都不一样,服务器端秘钥是配置在服务器端参与加密的字符串(即:盐),目的是提高Token加密的破解难度,注意一定不要泄漏;
    
    二、时间戳超时机制
    
    客户端每次请求接口都带上当前时间的时间戳timestamp,服务端接收到timestamp后跟当前时间进行比对,如果时间差大于一定时间(比如:1分钟),则认为该请求失效。时间戳超时机制是防御DOS攻击的有效手段。
    
    例:http://url/getInfo?id=1&timetamp=1559396263
    
    三、URL签名
    
    写过支付宝或微信支付对接的同学肯定对URL签名不陌生,我们只需要将原本发送给server端的明文参数做一下签名,然后在server端用相同的算法再做一次签名,对比两次签名就可以确保对应明文的参数有没有被中间人篡改过。
    
    首先我们需要分配给客户端一个私钥用于URL签名加密,一般的签名算法如下:
    
    1、首先对通信的参数按key进行字母排序放入数组中(一般请求的接口地址也要参与排序和签名,那么需要额外添加url=http://url/getInfo这个参数);
    
    2、对排序完的数组键值对用&进行连接,形成用于加密的参数字符串;
    
    3、在加密的参数字符串前面或者后面加上私钥,然后用md5进行加密,得到sign,然后随着请求接口一起传给服务器。
    
    例如:
    
    http://url/getInfo?id=1&timetamp=1559396263&sign=e10adc3949ba59abbe56e057f20f883e
    
    服务器端接收到请求后,用同样的算法获得服务器的sign,对比客户端的sign是否一致,如果一致请求有效;
    
    注意:对于客户端的私钥一定要妥善处理好,不能被非法者拿到,如果针对于H5的项目,H5保存私钥是个问题,目前没有更好的方法,也是一致困扰我的问题,如果大家有更好的方法可以留言一起探讨。
    
    四、防重放
    
    客户端第一次访问时,将签名sign存放到服务器的Redis中,超时时间设定为跟时间戳的超时时间一致,二者时间一致可以保证无论在timestamp限定时间内还是外 URL都只能访问一次,如果被非法者截获,使用同一个URL再次访问,如果发现缓存服务器中已经存在了本次签名,则拒绝服务。如果在缓存中的签名失效的情况下,有人使用同一个URL再次访问,则会被时间戳超时机制拦截,这就是为什么要求sign的超时时间要设定为跟时间戳的超时时间一致。拒绝重复调用机制确保URL被别人截获了也无法使用(如抓取数据)。
    
    以上方案流程如下:
    
    1、客户端通过用户名密码登录服务器并获取Token;
    
    2、客户端生成时间戳timestamp,并将timestamp作为其中一个参数;
    
    3、客户端将所有的参数,包括Token和timestamp按照自己的签名算法进行排序加密得到签名sign
    
    4、将token、timestamp和sign作为请求时必须携带的参数加在每个请求的URL后边
    
    例:
    
    http://url/request?token=h40adc3949bafjhbbe56e027f20f583a&timetamp=1559396263&sign=e10adc3949ba59abbe56e057f20f883e
    
    5、服务端对token、timestamp和sign进行验证,只有在token有效、timestamp未超时、缓存服务器中不存在sign三种情况同时满足,本次请求才有效;
    
    五、采用HTTPS通信协议
    
    众所周知HTTP协议是以明文方式发送内容,不提供任何方式的数据加密,如果攻击者截取了客户端和服务器之间的传输报文,就可以直接读懂其中的信息,因此HTTP协议不适合传输一些敏感信息,比如信用卡号、密码等。
    
    为了解决HTTP协议的这一缺陷,需要使用另一种协议:安全套接字层超文本传输协议HTTPS,为了数据传输的安全,HTTPS在HTTP的基础上加入了SSL协议,SSL依靠证书来验证服务器的身份,并为客户端和服务器之间的通信加密。
    
    HTTPS也不是绝对安全的,如下图所示为中间人劫持攻击,中间人可以获取到客户端与服务器之间所有的通信内容。
    
    
    
     
    
    中间人截取客户端发送给服务器的请求,然后伪装成客户端与服务器进行通信;将服务器返回给客户端的内容发送给客户端,伪装成服务器与客户端进行通信。 
    通过这样的手段,便可以获取客户端和服务器之间通信的所有内容。 
    使用中间人攻击手段,必须要让客户端信任中间人的证书,如果客户端不信任,则这种攻击手段也无法发挥作用。
    
     
    
     
    
    2 针对安全性要求一般的app,可采用通过校验域名,证书有效性、证书关键信息及证书链的方式;
    
    总结:所有的安全措施都用上的话有时候难免太过复杂,在实际项目中需要根据自身情况作出取舍,比如可以只使用签名机制就可以保证信息不会被篡改,或者定向提供服务的时候只用Token机制就可以了,如何取舍,全看项目实际情况和对接口安全性的要求。

     

    展开全文
  • 由于前端和后端分离,后端需要提供前端满足的所有的接口,有些接口获取的信息是涉及到客户隐私,有些接口是给和我公司存在合作方的才能使用,有些是调用的第三方的接口,那么这些接口如何保证其访问的安全性呢实际...
  • SpringBoot前后端分离API接口怎么保证API接口安全性?前端用vue写的,直接放在nginx下面,后端使用SpringBoot作为服务端提供API接口给前端访问,前端分为公共访问页面和登录后访问页面。登录后访问的可以使用JWT...
  • API接口安全性设计

    千次阅读 2018-10-28 13:21:09
    接口安全性主要围绕token、timestamp和sign三个机制展开设计,保证接口的数据不会被篡改和重复调用,下面具体来看: Token授权机制: 用户使用用户名密码登录后服务器给客户端返回一个Token(通常是UUID),并将...
  • 怎么保证APP接口传数据的安全性

    千次阅读 2019-08-21 13:19:24
    第一种方案: 用户登录时传给服务器一个用户的唯一标识...来确保数据传输的安全性。 第二种方案: 用ssl(SSL依靠证书来验证服务器的身份,并为浏览器和服务器之间的通信加密。)做双端验证。用Https协议做通信。 ...
  • 今天小编就为大家分享一篇关于连续调用多个外部系统写接口保证数据一致的思路,小编觉得内容挺不错的,现在分享给大家,具有很好的参考价值,需要的朋友一起跟随小编来看看吧
  • 最近有个项目需要对外提供一个接口,提供公网域名进行访问,而且接口和交易订单有关,所以安全性很重要;这里整理了一下常用的一些安全措施以及具体如何去实现。 安全措施 个人觉得安全措施大体来看主要在两个方面,...
  • 【安全测试】接口安全性

    千次阅读 2019-05-04 21:33:49
    之前这边负责的项目后来被主管说接口这里有些风险,特此参考学习接口安全性测试点。 一.接口防刷 1.为什么会有人要刷接口? 牟利:黄牛在 12306 网上抢票再倒卖。 恶意攻击竞争对手:如短信接口被请求一次,会...
  • 接口安全性主要围绕Token、Timestamp和Sign三个机制展开设计,保证接口的数据不会被篡改和重复调用,下面具体来看: Token授权机制:用户使用用户名密码登录后服务器给客户端返回一个Token(通常是UUID),并将...
  • web接口安全性设计

    2019-06-02 22:47:10
    接口安全性主要围绕Token、Timestamp和Sign三个机制展开设计,保证接口的数据不会被篡改和重复调用,下面具体来看 Token授权机制 用户使用用户名密码登录后服务器给客户端返回一个Token(通常是UUID),并将Token-...
  • Spring Cloud中如何保证各个微服务之间调用的安全性?

    千次阅读 多人点赞 2021-08-19 15:39:58
    导读:在微服务的架构下,系统会根据业务拆分为多个服务,各自负责单一的职责,在这样的架构下,我们需要确保各api的安全性,也就是说服务不是开放的,而是需要授权才可访问的,避免接口被不合法的请求所访问。...
  • 保证调用第三方接口安全性

    千次阅读 2019-07-17 17:18:25
    https://blog.csdn.net/fzy198926/article/details/93310354 https://blog.csdn.net/ityouknow/article/details/80603617 https://www.jianshu.com/p/a29ab3f97f3f
  • 接口安全性设计

    千次阅读 2018-08-15 10:36:28
    接口安全性主要围绕Token、Timestamp和Sign三个机制展开设计,保证接口的数据不会被篡改和重复调用,下面具体来看: Token授权机制:用户使用用户名密码登录后服务器给客户端返回一个Token(通常是UUID),并将...
  • 外网API接口安全性问题

    千次阅读 2020-02-26 21:51:36
    写开放的API接口时是如何保证数据的安全性的?我们通过http post 和get请求服务器的时候,会面临安全性的问题 一.思考 安全性问题包括那些? 如何能做到足够安全? 安全性问题:(解决一下四个问题就能保证安全...
  • 浅谈如何保证API接口安全性

    千次阅读 2020-06-12 13:42:18
    在实际的业务中,需要通过定义各种接口规范来保证传输的安全性。 token 访问令牌access token,用于标识接口调用者的身份、凭证,减少用户名和密码的传输次数。一般情况下客户端(接口调用方)需要先向服务器端申请...
  • 接口安全性解析

    千次阅读 2016-10-20 11:55:20
    1、因为是非开放的,所以所有的接口都是封闭的,只对公司内部的产品有效; 2、因为是非开放的,所以OAuth那套协议是行不通的,因为没有中间用户的授权过程; 3、有点接口需要用户登录才能访问; 4、有点接口...
  • //由此来分析该ip的用户是否是正常的用户,如果调用太频繁,比如连续一周或数周都在调用该接口,系统可以暂时禁用该ip发来的请求,或者降低该手机号获取短信验证码的次数 //一般大网站通常都得使用大数据来...
  • 开放接口API安全性

    千次阅读 2018-09-28 11:24:40
    服务端对外开放API接口,尤其对移动应用开放接口的时候,更需要关注接口安全性的问题,要确保应用APP与API之间的安全通信,防止数据被恶意篡改等攻击。 安全考量点 Token机制 开放接口时最基本需要考虑到接口不...
  • 用户登录接口的设计,首先要考虑的是防止用户的账号被...但是我们真正的目的是为了保证用户的账号安全,屏蔽攻击者的恶意调用的同时,又要保证真实用户的正常使用,此时就应该提供重置登录密码的操作,密码重置成...
  • java接口安全性解决方式

    千次阅读 2019-09-09 17:27:43
    在前后端分离的开发中,后台提供的接口如何能保证访问权限安全? 解决方案: 主要是身份验证、数据加密、访问控制(访问频率、访问次序,每个IP次数) 一、.签名 根据用户名或者用户id,结合用户的ip或者设备号,...
  • 接口安全性问题(面试)

    千次阅读 2018-08-30 20:02:27
    接口安全性知识面很广,我只是写下冰上一角,只是从java开发层面去写一点自己的理解 写这篇文档的缘由还要从我上家公司说起,离职后接到第一家公司的面试电话,简单的电话沟通后留下了面试的地点和时间,觉得这家公司还...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 472,731
精华内容 189,092
关键字:

如何保证接口安全性