毕设记录

 蛋疼 写累了记录一下目前毕设的情况

一开始思路很明确,涉及到的内容主要有:
Web展示页面部分【最后做
实装为了达到毕设要求的其他exp模块【中期之后或者中期前看有没时间做
一个爬虫用于爬取页面中的url和参数【完成
一个用于获取经过动态渲染后的页面源代码的模块【完成
XSS检测模块【进行中

然后初步先判定输入输出点数据是否经过过滤或编码,根据编码或过滤的情况加载不同的payload去尝试,根据页面回显中内容进行判断
剩下的就是一些数据转换啦编码啦之类的小函数

但是写着写着就有点,偏离了原本的想法。。。

不管中间payload的选择模版怎么判断 最后的判定一定以输入输出对应为主 不同的payload的选择仅仅只是根据filter的类型选择不同模版而已

但是 最后的判定这个函数 也可以根据输出点的不同 来判断,然而这样需要判断其过滤方式 且payload本身的选择在这部分之前,,因此输出点的判断要在payload选择方式之前判断完成
和正则杠上了
现在结果流程比较 明确了 但是还有个问题就是 网络部分的实例声明 为了代码简洁应该不在不同函数中声明多个实例去处理,还需要修改

为什么不采用hook事件的方式 因为感觉过滤会过滤很多事件 但是从扫描中等难度以上的XSS来看 根据输入输出过滤情况和输出位置来判断是否存在XSS然后进行预警 再人工进行查找 结果是 会减少一部分利用稍难的漏报,当然 漏报也会增加 但是如果是用于平时挖src和辅助人工测试xss角度来看, 这种结果我是可以接受的

还有个问题 关于 迭代替换的问题 如果从过滤方式的角度出发 感觉 会有很多个filter的判断分支 不如直接根据输出点的简单的几个点的过滤情况 去做判断 这样就不用构造可用的比如script img on事件这样的完整关键字 如果只从符号的角度去判断的话 误报又会增加 我们就默认具有关键字过滤 采用二次编码的方式去探索是否存在这样的绕过,也不去给编号而是独立在filter探测之外给个字母
上了个厕所的功夫 觉得是不是可以 filter就是filter 该怎么过滤就检查怎么过滤 把双写绕过和uriencode绕过单独作为一个绕过模块来检测 然后给中危人工提示

对于输出点的检查 是否双引号过滤单引号过滤 还是>x< 就够了 如果在<script>x</script> 中间的话,再判断是否有" 的情况

为了方便以后扩展 决定不在输入检查部分检查绕过方式二次之类的, 便于之后的根据[inputfilter,outputtype,bypasstype]来扩展payload
这个部分思路清晰之后 果然就好写很多啊,在这里纠结了两天
写死我了

写着写着 在output的判断上 可能会存在一些不同的利用方式,考虑是在payload上加强对这部分呢的验证呢,还是在output检查上对这方面提前进行判断
涉及到网络请求的部分实在是太慢了,之后可能会将requests库换成urllib 所以考虑还是不在output上做文章了吧,发出一个web请求就大大的增加了检查的时间
在bypass做检测的话
只需要检测输出点在双引号中间还是外面就可以了
反正dom型 最终也会输出到页面的呀
想了想还是要检测三种 一个是是不是在>x< 一个是是不是<引号x引号> 一个是是不是在script标签里

那么 现在问题又来了,,可以直接根据outputposition和filter 判断是否存在xss啊。。bypass可以辅助增加准确性。
就基本上不需要payload去试了啊。。。。搞毛啊

DSXS 正则的匹配 有很多问题啊。。和这个的区别在于 不专门去检测DOMXSS 因为DOM最后通过渲染的页面中也是会出现的
xssfork,,暴力payload+各种绕过打 通过hook检测,主要精力就放在hook的js文件上了,但是有个好处,payload多 ,检测范围就大,误报率因为检测了事件,误报率比较低。
而我的是打算放在 检测脚本里,但是这样 还是有很多问题啊,主要就是正则匹配寻找输出点的问题,其他都还好,这部分能做好之后,就可以减少很多误报漏报了

和正则杠上了 以下为对位置的判定正则 如有指教请评论 ,掉头发中
大概类似。。r'<[^>]*?(?:(?:k4brtao[^"|\'])|(?:[^"|\']k4br))[^>]*?>'
其实可能 会有 <a value = " k4brtao " >的情况出现对不对 ,甚至<a value = " xxxk4brtaoxxx " >? 让我思考一下》。。

crawler的部分很快出结果,目前打算把多线程放到对 结果的不同url 去 就 url params 作为参数 放到 sniffer里去,然后存档 ,然后用一个专门的xss匹配结果判断就行

目前看来可以基本检测到输出点位置、过滤方式、是否存在简单绕过了,简单试了试还是符合预期的,过几天完善后找个靶场试试。
文章是想起了就记录下,免得之后忘记中间是做了什么,到时候论文都不知道咋写OTZ。

对各项判断结果的处理,采取针对某种触发方式才判断的情况,其余没在规则内的先放过,会出现漏报,但是误报会少点,规则会尽可能详细,因为目前是想打造一款比较针对性的检测,之前的检测中速度是比较慢的,这个问题在之后主函数中加入线程可能会有所缓解。

准确度很高,就是太慢了。。。。

想到其他几个东西 ,一个是爬取得深度,可以对第一次爬取得结果去掉param部分,因为效率关系,我想再往下3层或5层,最后对url进行去重就可以。
还有一个就是 对于中间产生的url数据,可以考虑放在全局里或者放在对应hash名称的文件里,这样的话会可以对后续的其他漏洞或者情况扫描节省掉数据搜集的时间。
这样不仅可以用在辅助判断上,平日里工作的时候也可以当小脚本来用

对输出点的结果更改了一下,增加了一个 多个输出点的判断(可能作为一个威胁提示

想我家猫了....

蛋疼,论文格式也是问题,字数也,实施性工作 不太好写论文啊。。。

最后发现,其实这样设计不好,有好处也有坏处,应该不是一个比较好的方法,只能说个人用的话还行/
尤其是输出位置+解析后的页面内容判断,不太好。


发表评论 暂无评论

*