1. 项目概述从“绕过”视角看Web安全实战最近在带新人入门Web安全发现很多朋友对“绕过”这个概念既熟悉又陌生。熟悉是因为在各种CTFCapture The Flag题目、渗透测试报告里这个词高频出现陌生是因为一旦自己上手面对一个具体的“绕过”场景往往不知从何入手思路卡壳。正好我最近系统性地复盘了Bugku平台上一些经典的Web题目特别是那些以“绕过”为核心的关卡感觉很有必要把这些零散的技巧和背后的逻辑串联起来形成一套可复用的解题框架。“绕过”的本质是什么在我看来它是一场开发者与安全测试者或攻击者之间的思维博弈。开发者基于对业务逻辑和安全规范的理解设置了一道道“门”和“锁”而我们的任务就是找到那些未被锁死、被遗忘的“窗户”或者发现“锁”本身的制造缺陷。这个过程不是为了破坏而是为了理解防御体系的薄弱点从而构建更健壮的系统。Bugku的Web题目尤其是那些标题里带着“绕过”、“各种绕过”字眼的就像是精心设计的“思维健身房”每一关都在锻炼你从不同角度审视代码逻辑、协议规范和数据处理流程的能力。这篇文章我将抛开简单的答案罗列带你深入这些“绕过”题目的内核。我们会一起拆解客户端校验、服务端逻辑、输入过滤、协议特性等层面的常见防御措施并探讨如何系统性地寻找“绕过”路径。无论你是刚接触Web安全的新手还是想梳理知识体系的老手相信这套基于实战的“绕过”方法论都能给你带来启发。我们不止步于“怎么做”更要深究“为什么能这么做”以及“下次我该如何设计才能防住”。2. 绕过体系的核心维度解析Web安全中的“绕过”并非玄学它通常针对的是安全防护机制中存在的逻辑不严谨、过滤不完整或信任关系错误等问题。我们可以将其系统性地划分为几个核心维度每个维度都对应着开发者不同的防御意图和常见的疏漏点。2.1 客户端绕过信任的错觉这是最常见也最基础的绕过场景。开发者常常会出于用户体验或减轻服务器压力的考虑将部分校验逻辑放在前端浏览器执行例如JavaScript进行的表单验证、输入格式检查、按钮状态控制等。然而前端的一切对用户都是透明的、可控制的。核心原理浏览器只是一个执行环境用户拥有对发送到服务器的最终请求数据的完全控制权。前端JavaScript校验无法阻止恶意用户直接构造并发送HTTP请求。典型场景与绕过手法JavaScript禁用与修改最简单的就是直接禁用浏览器JavaScript。但很多现代应用禁用JS后功能不全。更通用的方法是使用浏览器开发者工具F12。修改HTML元素比如将input type“hidden” name“isAdmin” value“0”中的value值从“0”改为“1”。修改JavaScript函数在Sources面板找到校验函数直接在线修改其逻辑或返回值例如将function check(){return false;}改为function check(){return true;}然后执行。拦截并修改请求在Network面板找到提交请求通常是POST右键选择“Edit and Resend”直接修改参数值后重发。本地文件绕过有些题目会要求你上传一个文件并在前端用JavaScript检查文件扩展名如只允许.jpg。你可以先准备一个符合要求的文件如shell.jpg在上传请求被浏览器拦截后将文件名改为shell.jpg.php再发送。因为最终校验在服务器前端检查形同虚设。实操心得不要满足于一次修改。有时前端校验有多层需要逐步跟踪JavaScript执行流程。熟练使用Chrome DevTools的断点调试在事件监听器或函数入口打上断点可以让你清晰地看到数据流和逻辑分支这是理解题目设计者思路的绝佳方式。2.2 服务端逻辑绕过思维定式的陷阱服务端逻辑的绕过需要更深入地理解应用程序的业务流程和状态管理。这类问题往往源于开发者对用户行为序列做了过于理想化的假设。核心原理应用程序的状态转换存在漏洞允许用户以非预期的顺序或方式访问资源、执行操作。典型场景与绕过手法条件竞争Race Condition常见于支付、兑换、抽奖等“先检查后操作”的场景。例如系统先查询余额是否足够足够则扣款并发放物品。攻击者同时发送大量并发请求可能在“检查”通过后、“扣款”发生前多个请求都成功执行了“发放物品”的操作。实战工具使用Burp Suite的Intruder模块配置为“Sniper”或“Cluster bomb”模式设置大量线程并发发送请求。或者编写Python脚本利用threading或asyncio库实现高并发。步骤跳过/顺序绕过完成一个任务需要A-B-C三步每步会检查上一步是否完成通常通过session或数据库状态位。如果检查不严可能直接访问C的URL就能完成任务。排查方法仔细分析每个请求的URL参数、Cookie和POST数据尝试直接访问最终步骤的端点或修改中间步骤的状态参数。参数污染HPP与参数解析差异当同一个参数名在URL、Body、Cookie中多次出现时不同后端技术PHP/Apache, JSP/Tomcat, ASP.NET/IIS的解析规则可能不同。这可能导致过滤被绕过或逻辑判断出错。测试方法同时提交?id1id2观察后端实际处理的是哪一个值。在Burp中可尝试在多个位置添加同名参数。2.3 输入过滤与编码绕过矛与盾的进化这是Web安全攻防的主战场之一。开发者使用各种函数如addslashes(),mysql_real_escape_string(),preg_replace()对用户输入进行过滤以防御SQL注入、XSS等攻击。绕过这些过滤需要了解过滤器的具体行为和不同上下文的解析差异。核心原理过滤函数往往有特定的匹配模式或转义规则当输入以非预期的方式构造或经过多重编码/解码后可能逃逸过滤在最终解析时还原为恶意代码。典型场景与绕过手法SQL注入绕过关键字替换/双写如果过滤了select尝试selselectect假设过滤函数只替换一次或SeLeCt大小写混淆。编码绕过使用URL编码%xx、十六进制0x...、Unicode编码等。例如union可能被过滤但u%6eionn被URL编码或UNI%4fNO被编码可能绕过简单的字符串匹配。注释符混淆利用/**/内联注释分割关键字如sel/**/ect。等价函数/语句替换substring()可以用mid(),substr()代替‘admin’可以用like ‘admin%’或in (‘admin’)代替。XSS过滤绕过事件处理器当script标签被过滤可以尝试HTML标签的事件属性如img src1 onerroralert(1)。伪协议在a标签的href或iframe的src中使用javascript:alert(1)。编码与大小写类似SQL注入对标签或事件名进行HTML实体编码如变成lt;或大小写变换ScRiPt取决于浏览器的解析策略。利用解析差异在textarea或title标签中HTML实体可能会被先解码。例如输入/titlescriptalert(1)/script如果页面结构是title用户输入/title就可能提前闭合title标签注入脚本。文件上传绕过扩展名绕过除了前端绕过服务端可能通过黑名单禁止.php,.asp等或检查文件头Magic Number来防御。黑名单遗漏尝试.php5,.phtml,.phps,.php7等可能被解析为PHP的扩展名。大小写.PHP,.Php。点号/空格.php.Windows下最后一个点会被去除.php末尾空格。双重扩展名.jpg.php可能被解析为PHP。文件内容绕过在文件开头添加图片的文件头如GIF89a后面再拼接PHP代码。如果服务器只检查文件头可能绕过。同时利用?php标签被过滤的情况可以使用短标签?或script language“php”等。2.4 协议与规范层面的绕过这类绕过利用了HTTP协议、服务器配置或中间件特性中的一些“特性”或模糊地带。核心原理服务器、负载均衡器、WAFWeb应用防火墙对HTTP请求的解析与后端应用框架如PHP, Tomcat的解析可能存在不一致。典型场景与绕过手法HTTP参数污染HPP如前所述发送多个同名参数利用中间件与后端解析差异。请求方法混淆后端可能只对GET或POST方法的参数进行安全检查。尝试将参数放在其他HTTP方法如PUT,DELETE,HEAD的请求中或者将GET参数放在POST请求的Body里。请求包拆分/畸形请求通过添加额外的换行符、空格、修改Content-Length、使用分块传输编码Transfer-Encoding: chunked等方式构造非标准的HTTP请求可能绕过一些简单的基于正则匹配的WAF规则。URL编码与多重编码WAF可能只解码一次而后端应用框架会解码两次。例如单引号‘被过滤但发送%2527%27的URL编码可能绕过WAF解码一次得到%27认为无害后端再解码一次得到‘成功注入。利用服务器解析特性例如在Apache中如果文件名为shell.php.jpg且.jpg未被定义为处理器Apache可能会向后寻找已知处理器最终交给php模块处理从而执行PHP代码。这依赖于特定的AddHandler配置。3. 实战演练拆解典型“绕过”题目理论需要结合实践。我们选取几个Bugku中具有代表性的题目模拟真实解题过程将上述绕过手法融会贯通。请注意这里侧重思路分析不直接提供flag。3.1 场景一客户端JS验证绕过“你从哪里来”类题目题目特征页面有一个输入框或按钮查看源码发现有JavaScript函数对输入进行校验或者通过alert、console.log给出提示。解题流程信息收集按F12打开开发者工具。Elements面板查看HTML表单注意disabled属性、hidden输入框、onclick事件绑定的函数名。Sources面板查看引用的所有JS文件搜索关键字如check,verify,validate,submit。Console面板查看页面加载或操作时的错误信息和console.log输出。静态分析找到关键的校验函数。通常函数最后会返回一个布尔值true/false或决定是否提交表单。分析其判断逻辑比如是否检查了某个特定的Referer头、某个输入值是否等于一个固定字符串。动态调试在关键函数入口或条件判断处打上断点重新触发操作如点击提交观察变量值的变化理解逻辑分支。实施绕过直接修改在Console中重新定义该函数使其直接返回true。例如function check(){return true;}。修改DOM如果校验的是某个输入框的值直接通过Elements面板修改其value属性。拦截重放如果修改JS复杂就让校验通过前端的“假验证”然后在Network面板拦截即将发出的请求直接修改其中的关键参数再Forward放行或Repeater重放。案例延伸有一类题目要求“请求来自https://www.google.com”。这其实是检查HTTP请求头中的Referer字段。你无法控制别人的网站指向你但你可以完全控制自己发出的请求。使用Burp Suite的Repeater模块在请求头部手动添加一行Referer: https://www.google.com然后发送即可绕过。3.2 场景二服务端逻辑漏洞“秋名山车神”类题目这类题目往往涉及计算、速度或条件竞争。解题流程理解业务逻辑首先正常与页面交互。题目可能是一个快速计算题给你一个算式要求你在很短时间内提交答案。或者是一个抽奖页面每次点击消耗一个积分但积分获取有限。寻找瓶颈如果题目是计算题瓶颈在于“人手算不过计算机”。你需要用脚本Python来抓取页面上的算式解析并计算然后自动提交。这里的关键是维持会话Session Cookie使用requests.Session()对象。编写自动化脚本import requests import re session requests.Session() # 1. 访问初始页面获取算式 resp1 session.get(‘http://靶机地址/’) # 使用正则表达式提取算式例如div算式: 123*456789/div match re.search(r‘算式:\s*([\d\-*/()\s])’, resp1.text) if match: expression match.group(1) # 注意eval有安全风险仅用于CTF题目环境 answer eval(expression) # 2. 构造POST数据提交答案 data {‘answer’: answer} resp2 session.post(‘http://靶机地址/submit’, datadata) print(resp2.text) # 查看返回结果可能包含flag处理条件竞争如果是“限量抢购”或“快速点击”类题目需要高并发。使用多线程import threading import requests def attack(): session requests.Session() # 登录或获取初始Cookie的逻辑 # ... # 发送兑换请求 resp session.post(‘兑换URL’) print(resp.text) threads [] for i in range(50): # 启动50个线程并发 t threading.Thread(targetattack) threads.append(t) t.start() for t in threads: t.join()注意事项高并发请求可能对靶机造成压力请在比赛规则允许或个人实验环境下进行。同时注意处理网络异常和服务器响应避免脚本因单个请求失败而终止。3.3 场景三文件上传与内容过滤绕过这是Bugku的经典题型综合性强。解题流程探测过滤规则尝试上传一个纯文本文件观察返回信息。分别上传.php,.jpg,.png,.php.jpg等看是前端报错还是后端报错。上传一个内容为?php phpinfo();?的test.php文件如果被拦截尝试修改扩展名、文件头。查看源码或错误信息有时会提示使用了什么过滤函数如黑名单.php/.asp。绕过扩展名检测黑名单绕过尝试.php5,.phtml,.phps,.htaccess如果能上传并覆盖可配置解析规则。大小写/点号/空格.Php,.php.,.php。配合解析漏洞如果服务器是IIS尝试.php;.jpg或.php:.jpg冒号数据流。如果是Nginx特定版本可能存在解析漏洞。绕过内容检测文件头欺骗在PHP文件开头添加GIF89a或ÿØÿàJPEG文件头。标签替换如果过滤了?php尝试script language“php”phpinfo();/script仅旧版本PHP支持或短标签?phpinfo();?需要开启short_open_tag。编码/混淆使用Base64编码然后通过?php eval(base64_decode(‘编码后字符串’));?执行。但eval和base64_decode本身也可能被过滤。利用图片马使用copy /b normal.jpg shell.php webshell.jpgWindows或cat normal.jpg shell.php webshell.jpgLinux制作图片马。如果服务器只检查文件头能上传。但需要配合文件包含漏洞才能执行其中的PHP代码。获取文件路径与访问上传成功后页面通常会返回文件的存储路径或文件名。如果没有尝试常见的目录如/upload/,/images/,/assets/结合文件名进行访问。如果上传的是.htaccess文件内容为AddType application/x-httpd-php .jpg那么之后上传的.jpg文件也会被当作PHP执行。4. 工具链与调试技巧高效“绕过”的助推器工欲善其事必先利其器。一套顺手的工具和高效的调试方法能极大提升解题效率。4.1 核心工具集工具主要用途在“绕过”中的典型应用场景浏览器开发者工具前端代码分析、网络监控、DOM修改、JS调试客户端JS绕过、修改请求头/参数、查看源码注释和隐藏信息Burp SuiteHTTP代理、请求拦截/修改、重放、扫描、爆破所有需要修改HTTP请求的场景参数篡改、请求头注入、并发测试、编码解码Python Requests库编写自定义自动化脚本复杂逻辑自动化、条件竞争、计算题自动求解、会话维持Curl / Postman发送自定义HTTP请求快速测试某个端点、构造特殊格式的请求编码解码工具各种编码转换URL, Base64, Hex, Unicode等生成绕过过滤的Payload分析服务器响应4.2 调试与排查心法对比分析法这是最有效的方法之一。用Burp抓取一次“正常操作”的请求和响应再抓取一次“被拦截/失败操作”的请求和响应。使用Comparer功能进行逐字对比差异点往往就是关键所在比如多了一个Token某个参数值变了。输入输出追踪法在可能存在漏洞的点如搜索框、登录框输入一个特殊但无害的测试字符串如‘“test123。然后观察这个字符串在页面回显反射型XSS、数据库查询结果报错型注入、生成的文件名或日志中的样子。它是否被改变、被截断、被编码这能帮你快速判断过滤规则。边界值测试法对于数字型参数测试-1,0,1,99999等。对于字符串测试空值“”、超长字符串、特殊字符组合。服务器对边界值的异常处理如报错、返回空、逻辑紊乱常常能暴露漏洞。“白盒”辅助法虽然CTF中通常没有源码但有时错误信息会泄露部分信息如PHP Warning会显示文件名和行号。如果题目提供了“源码审计”类文件哪怕只是一小段也要逐字逐句分析画出数据流图理解每一个if判断和过滤函数。4.3 常见问题速查与解决在实战中你肯定会遇到各种意想不到的问题。这里记录一些我踩过的坑和解决方案问题现象可能原因排查思路与解决方案修改了JS/参数但请求依然失败1. 有多个校验环节。2. 使用了Token或一次性凭证。3. 请求被二次编码或签名。1. 系统性地跟踪整个提交流程从点击按钮到收到响应检查每一个环节。2. 在第一次请求的响应中搜索token,csrf,nonce等关键字将其提取并填入下一次请求。3. 使用Burp的Logger或浏览器Network面板查看最终发出的请求确认修改是否生效。Python脚本无法维持会话每次请求被视为独立会话。使用requests.Session()对象。所有通过该session发起的请求会自动处理Cookies。确保登录和后续操作使用同一个session实例。并发脚本导致结果混乱或漏判服务器处理有延迟或脚本逻辑不严谨。1. 在脚本中加入随机延时time.sleep(random.uniform(0.1, 0.5))模拟真人操作。2. 为每个线程分配独立的会话Session对象避免共享状态冲突。3. 仔细分析服务器成功响应特征在脚本中精确判断避免误判。上传的文件访问不到4041. 路径猜错。2. 文件名被重命名。3. 有访问权限控制。1. 查看上传成功后的页面提示或抓包看响应体常包含路径。2. 尝试常见目录原文件名或常见目录时间戳命名等模式。3. 如果返回了重命名后的文件名务必使用新名字访问。4. 检查是否有.htaccess或web.config文件限制了访问。WAF/过滤规则过于严格常规Payload无效可能使用了语义分析或更高级的过滤引擎。1.分拆Payload将union select分两次请求发送或利用参数污染在不同位置注入。2.使用生僻语法如MySQL的/*!50000select*/版本号注释。3.混淆绕过结合多种编码如双重URL编码、添加大量空白符/注释、使用非标准SQL语句。4.研究WAF特性有些云WAF默认规则可能对某些HTTP方法如PUT或特定路径如/api/检查较松。5. 防御视角从“绕过”中学习安全编码作为开发者或安全工程师我们研究“绕过”的终极目的是为了更好地防御。从这些题目中我们可以提炼出一些普适的安全编码原则永不信任客户端所有来自客户端的输入包括URL参数、POST数据、HTTP头部、Cookie、文件上传都必须视为不可信的。前端校验仅为提升用户体验服务端必须进行严格、一致的校验和过滤。白名单优于黑名单对于文件上传、输入格式等尽可能使用白名单机制。只允许已知安全的类型而不是试图列出所有危险的类型。例如只允许上传.jpg,.png,.gif图片并检查文件内容头与扩展名是否匹配。使用预编译语句参数化查询这是防御SQL注入最根本、最有效的方法。它从原理上分离了代码和数据使得用户输入永远被当作数据处理而非代码执行。实施最小权限原则Web应用程序连接数据库时不应使用root或sa等高权限账户。应创建仅具有必要权限的专用账户。文件上传目录应设置为不可执行脚本。保持框架和组件更新许多“绕过”利用的是已知的框架漏洞或服务器解析漏洞。定期更新服务器、中间件、开发框架和库可以堵上很多已知的“窗户”。安全的会话管理使用足够长度和随机性的会话ID设置合理的过期时间使用Secure和HttpOnly属性保护Cookie。对于关键操作如支付、改密使用二次确认或重新认证。输入规范化与输出编码在接收输入时进行规范化如统一字符编码。在输出数据到不同上下文HTML, JavaScript, URL, CSS时使用对应的编码函数如htmlspecialchars,encodeURIComponent确保数据被正确解释为文本而非代码。部署WAF但不过度依赖WAF可以作为一道有效的补充防线拦截已知的攻击模式。但它不能替代安全的代码。攻击者总会找到绕过WAF规则的方法。安全的核心在于应用自身。回过头看Bugku上这些“各种绕过哟”的题目就像一个个微缩的战场。它们将真实世界中复杂的安全问题抽象、提炼让我们能在安全的环境中反复练习攻防思维。解题的过程就是不断切换视角的过程时而扮演攻击者绞尽脑汁寻找逻辑缝隙时而扮演防御者思考如何堵上这些漏洞。这种思维训练的价值远大于记住几个特定的Payload或技巧。当你再面对一个真实的系统时这种对“信任边界”的敏感性和系统性审视的习惯将成为你最宝贵的能力。最后一个小建议建立一个自己的“武器库”笔记记录下每次遇到的新奇绕过手法、有效的Payload和工具配置并定期回顾。时间久了你会发现很多问题都似曾相识而你的解题速度也会大大提升。