精华内容
下载资源
问答
  • 解决跨域请求和接口安全问题

    千次阅读 2019-06-16 13:09:18
    写在前面:最近一个月因为事杂且多,没有抽出时间来整理技术点。...同源策略(Same origin policy)是一种约定,它是浏览器最核心也最基本的安全功能。为了保护本地数据不被JavaScript代码获取回...

    写在前面:最近一个月因为事杂且多,没有抽出时间来整理技术点。早就想好写这方面的内容了,这周末才勉强挤出时间整理下。

    步入正题,既然是解决跨域请求,那么要知道什么是跨域请求,为什么会有跨域请求。

    一、什么是跨域请求:

    首先引入一个概念:同源策略。

    同源策略(Same origin policy)是一种约定,它是浏览器最核心也最基本的安全功能。为了保护本地数据不被JavaScript代码获取回来的数据污染,因此拦截的是客户端发出的请求回来的数据接收,即请求发送了,服务器响应了,但是无法被浏览器接收。如果缺少了同源策略,则浏览器的正常功能可能都会受到影响。可以说Web是构建在同源策略基础之上的,浏览器只是针对同源策略的一种实现。

    正是有了这个同源策略,传统的单web请求一般都是在同一个域下,那么请求就是符合同源策略的,不会产生跨域请求。相对的如果web的请求不在同一个域下,那就会产生跨域请求。

    二、为什么会有跨域请求:

    既然符合同源策略的请求是浏览默认支持并且相对安全的。那为什么web还要跨域请求呢。同源策略只是浏览器的默认安全功能,也并非就是一定安全的。跨域也好,不跨域也好,安全都是要解决的问题。跨域并非一定意味不安全,况且跨域还有很多好处。我们今天生活在高度信息化产品的时代,而为了让我们享受到更快,更好的信息服务,那就必须把服务精准分布,使服务具有专业性,而不是像传统的大杂烩一样。提供专业的服务需要业务的分离部署,此外为了将前后端能更好的提供服务,一般的前后端都会分离部署,分离部署也是一种对后台服务的保护。服务是分布的,前后端是分离的,那用户页面请求服务就必然会产生跨域问题,什么样的请求是跨域的,是否允许通信,具体的如下表所示:

    URL

    说明

    是否允许通信

    http://www.test.com/a.js

    http://www.test.com/b.js

    http://www.test.com/c

    同一域名,不同文件或路径

    允许

    http://www.test.com/a.js

    http://www.test.com:8080/b.js

    同一域名,不同端口

    不允许

    http://www.test.com/a.js

    https://www.test.com/b.js

    同一域名,不同协议

    不允许

    http://www.test.com/a.js

    http://192.168.10.26:80/a.js

    域名和域名对应ip

    不允许

    http://www.test.com/a.js

    http://x.test.com/b.js

    http://test.com/c.js

    主域相同,子域不同

    不允许

    http://www.test.com/a.js

    http://www.dev.com/a.js

    不同域名

    不允许

     三、如何解决跨域请求问题:

    从表中可以看出,跨域请求的现象是服务端和浏览器端不允许通信。当然安全问题不是跨域独有,不跨域也同样有安全问题。无论跨域与否,安全问题是一样的,都要解决,下文在单独说明。

    目前前后端分离模式、服务抽象分布日益流行的情况下,跨域问题有了不少的解决方案。本文暂且说明三种方法:

    1、修改请求的方式:jsonp

    2、CORS设置

    3、使用nginx代理

    下面将对这三种方法分别进行说明和比较。

    1、修改请求的方式:jsonp

    该方案极不推荐,jsonp能够跨域是因为javascript的script标签,通过服务器返回script标签的code,使得该代码绕过浏览器跨域的限制。并且在客户端页面按照格式定义了回调函数,使得script标签返回实现调用。ajax实现如下。

    $.ajax({

    Url:’http://www.an.com:80/login’,

    Type:’get’,

    dataType:’jsonp’, //请求方式为jsonp

    jsoonpCallback:’Back’, //自定义回调函数名

    data:{}

    })

     如果采用jsonp方式。第一、在编码上jsonp会单独因为回调的关系,在传入传出还有定义回调函数上都会有编码的”不整洁”感。第二、jsonp只支持get请求。第二点是jsonp的死穴,对请求的限制一般会阻止很多人选择这种方法。

    2、CORS设置

    同第三种nginx代理都是目前主流的解决方法。通常跨域请求浏览器端会因为Access-Control-Allow-Origin不允许而导致无法接受后台的服务返回。跨域请求也分为简单跨域和非简单跨域。

    简单跨域就是GET,HEAD和POST请求,但是POST请求的"Content-Type"只能是application/x-www-form-urlencoded, multipart/form-data 或 text/plain。反之,就是非简单跨域,此跨域有一个预检机制,说直白点,就是会发两次请求,一次OPTIONS请求,一次真正的请求。

    通常我们使用的是非简单跨域请求,该种请求会有一个预检机制,请求方式是option,该预检机制可以知道服务是否正常,是否提供了此服务,也可以知道鉴权是否通过。一般的不合法的请求可以大大减少,也减少了后台服务的压力。

    CORS方法简单来说就是要实现服务允许被接受以及支持更多的请求方式。设置一般来说可以有两种方式实现,单本质是一样的。

    1)对网关中的CORS对象进行设置,实现如下:

    @Bean
    public CorsFilter corsFilter() {
        final UrlBasedCorsConfigurationSource source = new UrlBasedCorsConfigurationSource();
        final CorsConfiguration config = new CorsConfiguration();
        config.setAllowCredentials(true); // 允许cookies跨域
        config.addAllowedOrigin("*");// #允许向该服务器提交请求的URI,*表示全部允许,在SpringMVC中,如果设成*,会自动转成当前请求头中的Origin
        config.addAllowedHeader("*");// #允许访问的头信息,*表示全部
        config.setMaxAge(18000L);// 预检请求的缓存时间(秒),即在这个时间段里,对于相同的跨域请求不会再预检了
        config.addAllowedMethod("OPTIONS");// 允许提交请求的方法,*表示全部允许
        config.addAllowedMethod("HEAD");
        config.addAllowedMethod("GET");// 允许Get的请求方法
        config.addAllowedMethod("PUT");
        config.addAllowedMethod("POST");
        config.addAllowedMethod("DELETE");
        config.addAllowedMethod("PATCH");
        source.registerCorsConfiguration("/**", config);
        return new CorsFilter(source);
    }

    2)通过拦截器对请求方式和返回限制的解除设置,实现如下:

     response.setHeader("Access-Control-Allow-Origin", "*");
     response.setHeader("Access-Control-Allow-Credentials", "true");
     response.setHeader("Access-Control-Allow-Methods", "POST,GET,OPTIONS,PUT,DELETE");
     response.setHeader("Access-Control-Allow-Headers", "Authentication,Origin, X-Requested-With, Content-Type, Accept,token");
    

     3、nginx代理

    在使用nginx代理之前,先说一下nginx。nginx是一款自由的、开源的、高性能的HTTP服务器和反向代理服务器;同时也是一个IMAP、POP3、SMTP代理服务器;nginx可以作为一个HTTP服务器进行网站的发布处理,另外nginx可以作为反向代理进行负载均衡的实现。

    1)nginx反向代理

    这里的代理和我们生活中的代理有点相似。就是类似与一种角色或者一个渠道。

    既然有反向代理,那会不会有正向代理?答案是有的。那就先说说正向代理。生活中我们买东西一般的都是自己去买,当然也有不自己去买的,那不自己去买的人一般会找一个人---代理或者中间人。由这个人去把要买的东西买好给我们。我们无需知道代理人或者中间人是怎么去买的,而卖方也不知道是我们要买的,卖方是和代理人打交道的。这样对于卖方,就隐去的我们的信息。像这种提供服务的一方不知道真正买方的方式,一般的叫正向代理。

    而反向代理一个典型的例子就是我们生活中常用的淘宝。由于有大量的用户,单服务已经无法满足巨量的请求,因此网站就需要把不同的服务进行拆分并且分布式部署,而且同一种服务也进行多份分布式部署。这样才能满足人们的需求。用户一般的只需要知道网站的地址就行,当请求向指向该地址服务器时,服务器就是一个nginx代理,会将用户信息以及请求按照既定规则分发到不同的服务,然后再将服务返回的信息转发给用户。这样请求的服务是哪一台是不明确的,但是无论是哪一台服务接到请求,该服务都会知道用户的信息的。

    2)负载均衡

    在上述中的反向代理中,nginx扮演了反向代理服务器的角色,它是以依据什么样的规则进行请求分发的呢?不同的项目应用场景,分发的规则是否可以控制呢?

    负载均衡使用的场景是超大负载量,单服务无法满足的情况下。负载量是客户端发送的、nginx反向代理服务器接收到的请求数量。请求数量按照一定的规则进行分发到不同的服务器处理的规则,就是一种均衡规则。因此将服务器接收到的请求按照规则分发的过程,称为负载均衡。

    负载均衡在实际项目操作过程中,有硬件负载均衡和软件负载均衡两种,硬件负载均衡也称为硬负载,如F5负载均衡,相对造价昂贵成本较高,但是数据的稳定性安全性等等有非常好的保障;更多的公司考虑到成本原因,会选择使用软件负载均衡,软件负载均衡是利用现有的技术结合主机硬件实现的一种消息队列分发机制。

    nginx支持的负载均衡调度算法方式如下:

    1. weight轮询(默认):接收到的请求按照顺序逐一分配到不同的后端服务器,即使在使用过程中,某一台后端服务器宕机,nginx会自动将该服务器剔除出队列,请求受理情况不会受到任何影响。 这种方式下,可以给不同的后端服务器设置一个权重值(weight),用于调整不同的服务器上请求的分配率;权重数据越大,被分配到请求的几率越大;该权重值,主要是针对实际工作环境中不同的后端服务器硬件配置进行调整的。
    2. ip_hash:每个请求按照发起客户端的ip的hash结果进行匹配,这样的算法下一个固定ip地址的客户端总会访问到同一个后端服务器,这也在一定程度上解决了集群部署环境下session共享的问题。
    3. fair:智能调整调度算法,动态的根据后端服务器的请求处理到响应的时间进行均衡分配,响应时间短处理效率高的服务器分配到请求的概率高,响应时间长处理效率低的服务器分配到的请求少;结合了前两者的优点的一种调度算法。但是需要注意的是nginx默认不支持fair算法,如果要使用这种调度算法,请安装upstream_fair模块。
    4. url_hash:按照访问的url的hash结果分配请求,每个请求的url会指向后端固定的某个服务器,可以在nginx作为静态服务器的情况下提高缓存效率。同样要注意nginx默认不支持这种调度算法,要使用的话需要安装nginx的hash软件包。

    上面简单介绍了nginx。那么在跨域请求中,我们如何使用nginx呢。回想一下跨域请求产生的原因--请求的协议、域名、端口号不同,浏览器和服务端不允许通信。而nginx恰恰可以使用反向代理将前端页面和后台服务代理到同一个域下,那么前后端即便分离,服务即便分布部署,利用这种“瞒天过海”或者“暗渡陈仓”的手段,让浏览器认为和服务端在同一个域下,那跨域就不存在了,也就没有了跨域问题。nginx反向代理配置如下:

    server{
        listen 80;
        server_name localhost;
        #access_log c:/access.log combined;
        #index index.html index.htm index.jsp index.php;
        location / {
            root   /home/page;#文件根目录
            index  index.html index.htm;#默认起始页      
        }
        location /api { #将localhost:80域    中的api拦截进行代理转发  
                proxy_pass   http://localhost:8080/api;
        }
    }

    nginx监听本机的80端口,访问80端口就会在代理下转发到真正的页面index。对于80端口下的所有/api的请求路径进行拦截并转发到8080端口。这样浏览中就是在80域中操作,而实际页面和请求分别到了对应的地方。

    到此跨域问题基本解决了。

    四、接口安全问题

    无论跨域还是不跨域,接口都有一样的安全风险。接口安全涉及的范围较广,这里我仅对数据和权限的安全进行说明。

    一般的解决安全的手段有很多,如:

        1、通信使用https。

        2、请求签名,防止参数被篡改。

        3、身份确认机制,每次请求都要验证是否合法。

        4、对所有请求和响应都进行加解密操作。

        5、APP中使用ssl pinning防止抓包操作。

        6、其他安全设计方案。

     很显然,方案有很多种,没有绝对的安全,但是当项目中做的越多,也意味着安全性也更高。但安全和效率是成反比的,所以我们一般都需要按照实际情况采取最合适的方案。

    如果对数据的安全性要求高,需要以下实现:

    1、当有POST请求的数据发出时,前端统一加密。

    2、后台将返回的数据加密处理。

    3、前段统一处理数据的响应,在渲染到页面之前进行解密操作。

    前端加密可以一定层度提高接口的安全性,但是前端服务本质上是不够安全的,不可靠的。如果采用AES对称加密。那么前端必然会导致加密的key泄露。针对这种情况,只能借助后端提供一种动态的加密key的方式。利用RSA非对称加密和AES对称加密结合。AES加密效率高,RSA安全性高但运行速度慢,用RSA来加密传输AES的秘钥,用AES来加密数据,两者相互结合,优势互补。如下:

       1、客户端启动,发送请求到服务端,服务端用RSA算法生成一对公钥和私钥,我们简称为pubkey1,prikey1,将公钥pubkey1返回给客户端。

        2、客户端拿到服务端返回的公钥pubkey1后,自己用RSA算法生成一对公钥和私钥,我们简称为pubkey2,prikey2,并将公钥pubkey2通过公钥pubkey1加密,加密之后传输给服务端。

        3、此时服务端收到客户端传输的密文,用私钥prikey1进行解密,因为数据是用公钥pubkey1加密的,通过解密就可以得到客户端生成的公钥pubkey2。

        4、然后后端生成对称加密,也就是我们的AES,相对于我们配置中的那个16位长度的加密key,生成了这个key之后就用公钥pubkey2进行加密,返回给客户端,因为只有客户端有pubkey2对应的私钥prikey2,只有客户端才能解密,客户端得到数据之后,用prikey2进行解密操作,得到AES的加密key,最后就用加密key进行数据传输的加密,至此整个流程结束。

    以上过程和https的方式有点类似。如果对接口权限要求高,那就需要对接口进行鉴权操作。目前主流的鉴权方式往往是采用JWT的方式进行加密。流程如下:

    1、用户输入正确的账户密码,登录成功,后台利用JWT工具,可以结合用户的基本信息,时间戳等动态生成一串token口令。

    2、用户拿到口令后,每次请求将该口令添加到请求头Header中

    3、后台对其他非授权的接口进行token口令验证。验证通过,则放行,否则拦截。

    对请求的拦截一般放到filter拦截器中进行验证。token口令一般的保障了用户的合法性,但是在对于用户权限控制要求高的场景是远远不满足的。往往需要在Interceptor拦截器中进行权限的校验。在springboot项目中,该种实现方式是对WebMvcConfigurerAdapter继承并重写注册Interceptor拦截器。如下:

    @Configuration
    @ConditionalOnWebApplication
    public class WebApplicationAutoConfig extends WebMvcConfigurerAdapter{
    @Autowired
    private ThreadProfileInterceptor threadProfileInterceptor;
    @Bean
    public UnableRepeatRequestInterceptor unableRepeatRequestInterceptor(){
        UnableRepeatRequestInterceptor unableRepeatRequestInterceptor = new UnableRepeatRequestInterceptor();
        return unableRepeatRequestInterceptor;
    }
    @Bean
    public AuthenticationInterceptor authenticationInterceptor() {
        AuthenticationInterceptor authenticationInterceptor = new AuthenticationInterceptor(properties.isAuth(), properties.isToken());
        return authenticationInterceptor;
    }
    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(unableRepeatRequestInterceptor());
        /**
         * 服务的interceptor,用来做慢的服务调用统计
         */
        registry.addInterceptor(threadProfileInterceptor);
    
        /**
         * 限流拦截器的注册
         */
        if (rateLimiterProperties.isEnabled()) {
            RateLimitInterceptor interceptor = new RateLimitInterceptor(rateLimiterProperties.getGlobalRate());
            interceptor.setLimitMappings(rateLimiterProperties.findRuleList());
            registry.addInterceptor(interceptor);
        }
       
        /**
         * AuthenticationInterceptor 拦截器注册
         */
        InterceptorRegistration authenticationRegistration = registry.addInterceptor(authenticationInterceptor());
        Arrays.stream(properties.getInterceptorPattern()).forEach(authenticationRegistration::addPathPatterns);    Arrays.stream(properties.getExcludeInterceptorPattern()).forEach(authenticationRegistration::excludePathPatterns);
    }
    }

     

    public class AuthenticationInterceptor extends HandlerInterceptorAdapter implements InitializingBean {
    private static final String HTTP_METHOD_OPTIONS = "OPTIONS";
    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        //跨域请求,2rows
        if (HTTP_METHOD_OPTIONS.equals(request.getMethod())) {
            return true;
        } else if (!(handler instanceof HandlerMethod)) {
            return true;
        }
        executeLoginAuth(request, response, (HandlerMethod) handler);//该方法自己定义实现,根据权限和业务编写
        return true;
    }
    }

     以上就是MvcConfigurer和Interceptor和实现和注册。

    展开全文
  • 用最简单方法解决api接口安全问题,几乎无法破解

    万次阅读 热门讨论 2019-01-01 11:47:07
    接口涉及到核心功能,如何保证接口安全。防止伪造身份、篡改数据? 思路 保障数据安全最好的方法,当然是加密了。无法解析内容,自然无法伪造,篡改。 可是使用https证书需要收费的。有其它方法么? 有的。 消息...

    场景描述

    项目需要为第三方提供api服务接口。接口涉及到核心功能,如何保证接口安全。防止伪造身份、篡改数据?

    思路

    保障数据安全最好的方法,当然是加密了。无法解析内容,自然无法伪造,篡改。
    
    可是使用https证书需要收费的。有其它方法么?
    
    有的。
    
    消息哈希认证(hmac)。
    

    算法描述

    • 访问者
    1. 当访问接口时, 将参数按key值排序,组成key1=value1&key2=value2&....&secret_key=...
    2. 然后对上面结果做md5,生成签名sign
    3. 将sign放到加入请求的参数
    
    • 被访问者
    密钥是被访问者提供了,它也有访问者的secret_key.
    1.根据app_id查到secret_key
    2.处理请求参数,按规则组成key1=value1&key2=value2....&secret_key=...
    3.对上一步结果做md5,生成sign。比较两个sign,相等则身份验证通过
    

    效果

    1. 密钥只存在双方机器上,不可能被截取
    2. 签名无法伪造,同样身份无法伪造、消息无法被篡改

    使用了hmac认证,接口被破解基本是不可能的

    python实现

    import md5
    
    app_id=123
    secret_key="xxxxxxxx"
    
    request_param = dict(
        key1="value1",
        key2="value2",
        key3="value3"
    )
    
    def sign():
        params = ["%s=%s" % (key, value) for key, value in sorted(request_param.items(), key=lambda item: item[0])]
        params.append("secret_key=%s" % secret_key)
        str_param = "&".join(params)
        print str_param
        md = md5.md5()
        md.update(str_param)
        return md.hexdigest()
    
    if __name__ == '__main__':
        print(sign())
    

    来源
    用最简单方法解决api接口安全问题,几乎无法破解

    此生必看的科学实验-水知道答案
    《了凡四训》详解之改过之法
    印光大师十念法(胡小林主讲第1集)
    精神病为什么治不好
    百病之源

    展开全文
  • php接口安全问题

    千次阅读 2016-02-22 11:52:08
    在平时工作或者正式项目中,做接口在所难免,而接口安全问题首当其冲,为了防止接口被别人恶意调用,一般会做一个加密的工作,不同的公司,都有一套不同的处理方式。我们公司也有一套处理方式,即:做了一个加密的...

      在平时工作或者正式项目中,做接口在所难免,而接口的安全问题首当其冲,为了防止接口被别人恶意调用,一般会做一个加密的工作,不同的公司,都有一套不同的处理方式。我们公司也有一套处理方式,即:做了一个加密的token,该token为时间戳和一个特殊字符串(这个字符串只能调用和被调用方知道)的md5,我也一直用这个处理方式来做接口。


      有一次在帮部门的一个同事做接口的时候,他忽然跟我说起接口的事情,如果这个接口的url被别人随便用一个工具抓到,比如:firebug,那么人家就可以进行恶意调用了,其实这个token没什么用,因为别人可以保留这个请求。一下提醒我了,之前一直没有注意到这个问题,简单的认为这个url不会被轻易抓到(虽然自己一直用firebug),即使被抓到,也绕不过token的检查。后面跟这位同事大概讨论了一下这个问题的处理办法,他建议通过ip来判断,判断同一个ip的请求频率,如果频率过高则为恶意调用,当然这个方法也可行,只是稍微麻烦了一些,后面想到了一个更为简单的方法,即:时间的有效性。因为token是由时间戳和特殊字符串md5而成,那么每次调用接口的时候,我可以把当前调用的时间戳记录下来(比如保存在一个数组中,以文件的形式存放),然后在下次调用时判断请求的url中的时间戳在数组中是否存在,若存在则为恶意调用(因为若为正常调用,每次请求的url中的时间戳都是不一样的)。如此,便可防止接口被恶意调用。另外,随着调用次数的增加,存放时间戳的文件会越来越大,针对这个问题,可以不定期删除,即使有人*的保存一个url很长时间,然后某一天心血来潮,再来一次调用,接口也只会被恶意调用一次,不会产生影响。


      php安全问题,不仅仅是接口安全,还有诸多安全问题,比如常见的SQL注入,XSS攻击等,这些的防范,都需要平时coding的时候从一开始就重视起来,否则到时候不但难于查找,也比较被动,甚至可能会因为这些安全问题,会给项目带来毁灭性的的打击,当然也会让你痛不欲生!


    展开全文
  • 接口安全问题(面试)

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

                        接口安全性知识面很广,我只是写下冰上一角,只是从java开发层面去写一点自己的理解

          写这篇文档的缘由还要从我上家公司说起,离职后接到第一家公司的面试电话,简单的电话沟通后留下了面试的地点和时间,觉得这家公司还可以就去了,跑了很远的路程到了自己很想进的这家公司,面试的细节我记的不是很清楚了,已经大概有一年多了,现在能记得的就是跟标题有关系的这个面试问题.

          我说我主要做的提供接口,面试官问我你们是怎么保证接口的安全性的,我说我们接口就是加上用户的id,通过用户id来判断用户的,其实我这样的回答,现在想想其实也没有回答啥,可能我当时用户id这个也没有说吧,记得不清楚了(后来就没有后来了),在上家公司主要做的是提供接口给Android端,接口字段传用户id,其他的也没有做安全性考虑,小公司做的是水利方便,对接口的安全性方面也没有太高的要求,目前自己做的主要是支付,所以对接口的安全性有一定的要求,所以现在记录下自己理解的几点分两种:

    第一种:支付系统项目中在用的处理方式:

      1:加密
          1.1:项目中是独立的支付系统,对外我们提供的接口都是加密,所以请求和返回都需要对参数进行加密,对外系统我们提供公钥和私钥,公钥解密,私钥加密,对于不同的系统公私钥是不同的(公司目前的项目是对所有的参数都进行加密),

      2:解密

           2.1:验签的目的,我的理解是在网络传输的过程中会被截取和修改,接受到对方的结果后,进行验签目的调撤销(支付系统),不同的系统可能有不同处理方式,需要根据具体的业务来处理.

        //支付中台   
            //公钥验签, 私钥解密   用公钥加密 私钥加签
        //商户系统 
            //公钥加密 私钥加签  公钥验签 私钥解密

     

    第二种:支付宝,中行 ,工行第三方的处理方式

      3:加签

          3.1:将请求的报本本地+部分字段加密 组装请求对象,对方拿到后以约定好的字段和加密方式进行加密,然后和传过去的加密字段相比较,是否相等,相等则验签成功,否则失败

      4:验签

          4.1:将响应的报文本地+部分字段加密 组装响应对象,接收到后以同样的方式进行验签

    这个过程中我写的都是些流程,里面的一些细节处理没有写上去,有不理解的可以留言,有时间会给回复.希望给大家面试的时候问道的时候有的说,知道思路!

    请求:公钥验签,私钥解密 

    返回:公钥加密 私钥加签

    :公钥加密 私钥解密,我之前一直不理解这两个,分不清!  公钥验签 私钥 加签  公钥大家随便拿,但是私钥不能随便透露。

    生产公私钥 ,单向的 ,调用方 和被调用方用的是相同的公私钥

     public String generateBizSecurityKeys(){
            LOGGER.info("generateBizSecurityKeys");
            Map<String, String> keysMap = new HashMap<>();
            try {
                // 获取当前系统换行符
                String lineSeparator = System.getProperty("line.separator");
                // 生成RSA的公钥、私钥
                KeyPairGenerator keyPairGenerator = KeyPairGenerator.getInstance("RSA");
                keyPairGenerator.initialize(2048);
                KeyPair keyPair = keyPairGenerator.generateKeyPair();
                String privateKey = new BASE64Encoder().encodeBuffer(keyPair.getPrivate().getEncoded());
                String publicKey = new BASE64Encoder().encodeBuffer(keyPair.getPublic().getEncoded());
                // 替换掉换行符
                privateKey = StringUtils.replace(privateKey, lineSeparator, StringUtils.EMPTY);
                publicKey = StringUtils.replace(publicKey, lineSeparator, StringUtils.EMPTY);
                // 放入结果集合
                keysMap.put("privateKey", privateKey);
                keysMap.put("publicKey", publicKey);
                keysMap.put("success", "true");
            } catch (Exception e) {
                LOGGER.logException(e);
                LOGGER.warn("生成密钥异常:", e);
                LOGGER.logException(e);
                keysMap.put("success", "false");
            }
            // 转为Json以便返回前端
            String resJson = JsonUtil.objectToJson(keysMap);
            LOGGER.info(resJson);
            return resJson;
        }

     

     

    展开全文
  • 接口api开发中安全问题

    千次阅读 2018-04-26 10:50:31
    user_id=333的请求,然后服务器端直接根据user_id来做相应的会员操作,这是及其危险的接口处理,等于把当前的会员系统全暴露出来了,只要对方改一下user_id既可操作所有会员对应的接口。一般在PC端,我们是通过加密的...
  • webService的soap风格的接口安全问题

    千次阅读 2017-09-13 01:45:58
    ws接口安全问题 1 接口调用者身份验证问题 Rsa:私钥加密,公钥解密 Cxf:usernameToken 1 在请求中加入wsse的安全协议 2 在wsse中用安全令牌(用户名/密码)来验证用户的身份 3 cxf在发送和接受ws的soap请求时...
  • APP与后台接口间的数据传输加密使用3DES加密,但是3DES的密钥需要保存在APP中,这样很容易被获取,一旦密钥被获取,数据加密将不复存在。 所以我想使用RSA非对称加密方式传输3DES的密钥,用户登录时从服务器获取3DES...
  • java接口安全性解决方式

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

    万次阅读 热门讨论 2018-06-10 10:44:12
    互联网发展至今,已由传统的前后端统一架构演变为如今的前后端分离架构,最初的前端网页大多由JSP、ASP、PHP等动态...前后端的传输通过HTTP进行传输,也带来了一些安全问题,如果抓包、模拟请求、洪水攻击、参数劫...
  • 在前后端分离的开发中,后台提供的接口如何能保证访问权限安全?主要是身份验证、数据加密、访问控制(访问频率、访问访问次序,每个IP次数) 一、.签名 根据用户名或者用户id,结合用户的ip或者设备号,生成一个...
  • 微信小程序———接口安全

    万次阅读 2018-05-28 08:44:24
    我们写的每个小程序都要有接口,而这些接口不能向外公开,所以要有一个方法来保护自己的接口; //身份验证 public function checksession($code){ // if(!session('?openid') || !session('?session_key')){ /...
  • 如何保证HTTP接口请求的安全呢?

    万次阅读 2017-03-19 00:59:01
    那我们要如何对接口请求进行一个安全校验或者拦截非法请求呐? 1、选择拦截过滤器。 在请求的时候对请求方法进行一次拦截处理。比如非正常访问的方法已经注入插入可执行语句参数验证等在拦截中进行一次安全校验...
  • 开放API接口安全设计

    千次阅读 2019-09-04 14:19:26
    为什么前后分离需要关注接口安全问题 攻击方式有哪些 如何保障接口的安全 一、前后分离和传统项目的区别 1:前端渲染方式不同 传统项目是前后端不分离的,后端通过模板渲染引擎在后端渲染前端页...
  • webservice的安全问题

    千次阅读 2019-01-05 20:55:07
    webservice的安全问题     1 身份校验 1 在需要进行验证的接口中加入拦截器 2 对拦截器进行配置,对调用接口的身份进行拦截 3 usernameToken 2 信息加密 Wssj=webservice security for java...
  • 保证调用第三方接口安全

    千次阅读 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
  • 接口安全解决方案

    千次阅读 2019-03-21 08:36:53
    下面就简单列举几种措施来对付接口安全问题。 Token 机制 开放接口时最基本需要考虑到接口不应该被别人随意访问,而我也不能随意访问到其他用户的数据,从而保证用户与用户之间的数据隔离。这个时候我们就有必要引入...
  • 微信支付接口开发的安全规范

    千次阅读 2017-06-13 17:18:22
    商户回调接口使用HTTPS协议可以保证数据传输的安全性。所以微信支付建议商户提供给微信支付的各种回调采用HTTPS协议。请参考: HTTPS搭建指南 。 本人提供微信、支付宝的银行接口通道,QQ932636688/电话...
  • 1、将下载的txt文件放入nginx的安装目录,/usr/...这样我们用域名+txt文件在游览器就能访问了,但是还有一个域的问题。 2、修改nginx.cong配置文件中的location标签: 加入(proxy_set_header X-Real-IP $remote_a...
  • API安全接口安全设计

    万次阅读 2019-07-13 22:07:58
    如何保证外网开放接口安全性。 使用加签名方式,防止数据篡改 信息加密与密钥管理 搭建OAuth2.0认证授权 使用令牌方式 搭建网关实现黑名单和白名单 一令牌方式搭建搭建API开放平台 方案设计: 1第三方...
  • APP接口设计安全问题

    万次阅读 2014-09-10 10:39:22
    用PHP做服务器接口客户端用http协议POST访问安全性一般怎么做
  • tp5开发接口:接口安全设计

    千次阅读 2019-03-19 16:05:43
    登陆安全接口设计 1.username = red_panda 2.password = 123456 3.时间戳 timestamp = 17988732 token = md5(api_md5(red_panda) + md5(123456) + md5(timestamp)_api); service_token = md5(api_md5(red_pan...
  • 这篇博文跟大家分享下如何配置微信公众号网页授权域名和JS接口安全域名配置。
  • 关于Fiddler工具,早在之前的《Python接口自动化测试框架实战开发(一)》、《自动化接口实战(一)》、《电商项目测试实战(四)》系列博客中有详细介绍使用 文章目录一、Fiddler 基础1.什么是 Fiddler2.Fiddler 的...
  • 业务安全接口调用安全

    千次阅读 2018-09-04 22:54:24
    关于接口设计安全,主要需要考虑两个方面的安全问题,一是接口访问验证及权限问题,主要解决接口访问的合法性(用户登录验证、来源验证、频率控制等);另外是数据传输安全,主要解决接口数据被监听篡改和接口错误...
  • 接口常见安全漏洞说明

    千次阅读 2019-12-31 18:19:48
    这个问题在基于API的应用程序中非常常见,因为服务器组件通常不完全跟踪客户机的状态,而是更多地依赖于从客户机发送的参数(如对象id)来决定访问哪些对象 具体表现: 没有检查已登录的用户是否有权对请求的对象执行...
  • Http接口安全整理

    万次阅读 2018-02-08 12:14:21
    1.Http接口安全概述:  1.1、Http接口是互联网各系统之间对接的重要方式之一,使用http接口,开发和调用都很方便,也是被大量采用的方式,它可以让不同系统之间实现数据的交换和共享,但由于http接口开放在互联网...
  • 接口安全保护策略

    千次阅读 2018-11-09 15:07:37
    服务端对外开放API接口,尤其对移动应用开放接口的时候,更需要关注接口安全性的问题,要确保...下面就简单列举几种措施来对付接口安全问题。 Token机制 开放接口时最基本需要考虑到接口不应该被别人随意访问,而我...
  • 如何保证API接口安全

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

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 720,713
精华内容 288,285
关键字:

接口安全问题