博文

目前显示的是 三月, 2019的博文

XXE漏洞解决记录

图片
        内网漏洞平台报了一个XXE漏洞,是我们一个服务域名的根路径,刚一看还以为是弄错了,查了一下代码,果然存在这样的跟路径Controller。看了下逻辑,该服务是用于接收微信的事件通知的,微信是以xml格式提交过来的请求,代码中对XML的解析没有做特殊处理,于是乎。。。         接到工单后,搜了一下xxe漏洞,简单作个了解,原因XML协议中允许引入外部实体声明。这个外部实体的引用就给了不法分子很大的想象空间。外部的实体引用是个url,写成内部文件路径,可以扫描系统任意路径的文件,写成黑各自己服务的路径,可以收集服务器的信息,写成内网服务地址,可以攻击内网服务,再随意更换ip和端口,可以扫描端口等等。小小一个漏洞,可以利用的地方居然这么多,赶紧修复。 先在本地用postman构造注入的xml内容,模拟注入请求,服务B按预期收到了服务A的请求。 SAXReader reader = new SAXReader(); reader.setFeature("http://xml.org/sax/features/external-general-entities", false);  reader.setFeature("http://xml.org/sax/features/external-parameter-entities", false);  Document document = reader.read(xml); 加上以上红色的代码后,再次发送注入请求,服务B不再收到服务A的请求。 自测没问题后,开始上线流程,上完线后,自己用微信关注,取关公众号,服务均能正常接收微信上报过来的事件报文,回归完毕。 参考: https://blog.csdn.net/zhengpeitao/article/details/82142869 https://www.cnblogs.com/r00tuser/p/7255939.html https://www.jianshu.com/p/77f2181587a4

关于redis分布式锁的几个疑问点

我们在分布式场景下,需要用到分布式锁,分布式锁的实现方案可以有redis实现,zk实现等,这里只讨论redis的方案 先稍微铺垫一下两个redis的不成熟方案, 一, Get,判断是否存在,如存在直接返回失败,不存在继续 Set,设置锁,key对应的value为1,并设置过期时间 Del,业务执行完毕释放锁 code如下:     private static long expireTime = 20000;     public static boolean getLock(String key) {         String lock = RedisUtil.get(key);         if (!"1".equals(lock)) {             RedisUtil.set(key, "1");             RedisUtil.expire(key, expireTime);             return true;         } else {             return false;         }     }     public static void releaseLock(String key) {         String check = RedisUtil.get(key);         if (check != null) {             RedisUtil.del(key);         }     } 此方案明显存在的问题就是,多个线程同时请求get,不存在,同时set,所以会有多个线程进入的可能 二, Setnx,key对应的value为1,判断返回结果,0为设置失败,已经存在key,直接返回失败,1设置成功,继续 Expire,设置过期时间 Del,业务执行完毕释放锁 code如下:     private static long expireTime = 20000;     public static boolean getLock(String key) {         long lock = Red

ThreadLocal理解

        关于ThreadLocal,网上已经有很多文章讲的也是很清楚了,至于应用场景,大多也就是使用demo的方式进行了讲解,达不到让人印象深刻的目的。虽然以前也多次遇到过别人讨论这个东西,大多是面试场景吧,只是直至目前,我也几乎没有在工作中用到过(做开发这么久了,没用过这个,实属汗颜啊),根据理解,用我自己的话把ThreadLocal来描述一遍,以此记录。         ThreadLocal,是线程本地变量,ThreadLocal为多线程编程提供了一个另一个思路,不用锁,不用共享变量等特点。它的实现思路是在每个线程中存放一个变量的map,这个map用于存放属于线程的变量,这个map的使用就是由ThreadLocal来管理。ThreadLocal有三个方法,get,set,remove,分别是获取变量,设置变量,移除变量。还有一个初始化方法,是给继承类用的。         对于它的应用场景,按上面的思路来说,就是某个变量是希望在多线程下使用,但又是可以允许不同线程之间互不影响的情况(按线程多例,每个线程一个实例)。比如在spring的web工程体系中,从接收到用户的一个请求到service到dao层都是同一个线程在为其服务,每个线程持有一个数据库连接的实例,这样对于每一个实例来说,都不存在线程安全的问题了         若以后有机会实际用到的时候,再来补充场景。

关于cookie是否能跨域的解读

        这篇文章目的是对CORS跨域携带cookie的理解作一个解释,之前一直对这里有一个误解,以为跨域是可以携带不同域名下的cookie,事实上,cookie的传递是要遵循同源策略的         问题引出         同事遇到了一个问题,希望在跨域ajax请求的时候,带上原域的cookie,希望被访问的目标域服务端能访问到原域的cookie,问到了我,我还比较自信的表示跨域这点小事肯定能搞定,因为之前也多次处理过跨域的问题,经过多次尝试,均以失败告终,很是汗颜,最后不断的找资料以及问大牛,得知,这种方式无法实现。         究其根本&原理说明         本次的两个域名涉及到跨域。 说到跨域就要说到同源策略,而同源策略,同源策略限制cookie的访问以及ajax请求。 本次的跨域AJAX请求是用的CORS实现方式,CORS是w3c的标准。 CORS方式,默认不允许携带cookie,如果允许携带,是需要客户端和服务端同时设置。CORS方式,携带的cookie,也是要遵循同源策略的,cookie只能携带被访问域名以及其父域下的,其它域的cookie是不被允许访问的         白话总结         两个域名下的cookie,是不能相互访问和传递的 对于有相同根域名(二级及以上),可以把cookie设置到根域上才能实现跨子域名的cookie访问(实际上,cookie并没有跨域) 相关问题,跨域的几种方式,每种方式的具体实现,适用场景,针对不同的语言的实现细节,这里就暂不讨论了 CORS,同源策略等名词,直接百科即可 对于在尝试解决问题的过程中,做的一些测试代码,附录如下 Node,原生XHR,document写cookie zcmtestop.58corp.com进行xhr请求zcmtestop1.58corp.com var xmlHttp=new XMLHttpRequest(); xmlHttp.open("GET","http://zcmtestop1.58corp.com/",false); xmlHttp.withCredentials = true; xmlHttp.send