硬怼
硬怼的话,主要是从下面这些方法入手去操作。
(1)fuzz后缀名
看看有无漏网之鱼(针对开发自定义的过滤可能有机会,针对waf基本不可能。更多的情况是php的站寻找文件包含或者解析漏洞乃至传配置文件一类的,但是对于这种也大可不必fuzz后缀名了)
(2)http头变量改造
首先要明确waf的检测特征,一般是基于某种特定的情况下,去针对相应的拦截。几个例子,文件上传的时候,大多数Content-Type都是application/multipart-formdata这种,name对于waf来说,如果针对这种规则,对xxe ,sql注入,上传,命令执行,内容等所有都去做一波扫描是及其浪费内存的,所以有可能针对不同的类型,做了不同的校验规则。此时通过对Content-Type进行修改,可能会绕过waf。其他的http头添加删除等也是类似。
(3)文件后缀构造
这个和第一个有相似的就是都针对后缀名进行改造,不同的在于这里可能会利用waf的截取特征,比如回车换行绕过waf的检测,但是对于后端来说接收了所有的传入数据,导致了绕过waf。
(4)其他方法
这种就比较杂了,但是又不属于迂回打击的一类,比如重写等方法。接下来就实战来试试
第一步,先来对waf的规则做一个简单的判断。这里我的习惯是从内容,后缀两个方向进行判断。简单来说,基本分为这几种情况
(1)只判断后缀(基本碰到的比较少了,因为很多时候白名单开发都可以完成) (2)只判断内容(也比较少,因为一般的waf都会带后缀的判断)
(3)内容后缀同时判断(这种情况比较多,相对于来说会安全一点) (4)根据文件后缀来判断内容是否需要检测(较多)
(5)根据Content-Type来判断文件内容是否需要检测
暂时只想到这么多,以后碰到了再单独记吧。
有了思路,那么接下来就好说了。举个例子我这里的情况
(1)传脚本后缀(被拦截,判断了后缀) (2)传脚本后缀加不免杀代码(被拦截,可能后缀内容同时拦截)
(3)传非脚本名(可自己fuzz一个能过waf的任意后缀,里面加恶意内容,被拦截。也就是说同时会对内容和后缀进行判断)
说说我这里的情况,会对内容和后缀进行拦截。检测到上传jsp文件,任意内容都会被拦截。
先来fuzz一波能利用的后缀名,这里可以包括中间件的一些配置文件。希望不大,一点都不出意外,全部被拦截了。
既然我们需要对后缀名进行改造,就对后缀名后面加特殊符号做一个fuzz试试