企业官网建设流程全解析

1. 项目概述：这是一套面向Web安全初学者的靶场实战题集

“BugkuCTF_Web——‘web基础$_POST’、‘计算器’、‘矛盾’、‘web3’、‘你必须让他停下’”，光看这个标题，你就该意识到这不是普通练习题，而是一条精心设计的Web安全能力进阶路径。我带过不少刚接触CTF的新手，他们常误以为Web安全就是“点点鼠标、跑跑工具”，直到在“矛盾”题里被一个看似简单的布尔盲注卡住三天；也见过不少写过几年PHP的人，在“你必须让他停下”这道题前反复重装环境，就因为没理解pcntl_fork()在Web上下文中的真实行为边界。这套题的价值，不在于它有多难，而在于它用极简的代码暴露了Web开发中最容易被忽略的底层逻辑断层——从HTTP协议最基础的数据传递机制（$_POST），到服务端执行控制（fork阻塞）、再到业务逻辑与安全边界的错位（“矛盾”中的类型绕过），每一道都是对开发者日常编码直觉的精准反向测试。

它适合三类人：第一类是刚学完PHP/Python基础、正准备接触安全领域的开发者，这些题就是你的“安全第一课”，没有花哨框架，只有原生函数和原始请求；第二类是备考CTF的新手选手，题目全部来自真实靶场平台Bugku，复现成本低、解析资料多，但关键在于——你要能自己推导出payload，而不是抄flag；第三类是带新人的导师或技术负责人，你可以把“web3”题中file_get_contents()的协议限制、“计算器”题里eval()的沙箱逃逸思路，直接拆解成团队内部的安全编码checklist。我实测过，完整打通这五道题后，学员对“用户输入不可信”这句话的理解，会从教科书定义变成肌肉记忆——比如看到任何$_POST变量参与SQL拼接，手指会条件反射地去翻PDO预处理文档。

这五道题覆盖了Web安全四大核心断面：数据接收（$_POST）、服务端执行（eval/fork）、逻辑校验（类型转换与比较）、文件操作（协议封装与过滤）。它们不依赖复杂中间件，全部运行在标准LAMP环境上，意味着你不需要Docker、不需要K8s，一台装好PHP 7.4的虚拟机就能开干。接下来我会按实际解题顺序，把每道题背后的技术原理、调试过程、绕过思路，连同我踩过的坑一起摊开讲清楚。不是告诉你“答案是什么”，而是还原“为什么只能这么答”。

2. 题目逐层拆解：从协议层到执行层的穿透式分析

2.1 “web基础$_POST”——HTTP数据传递的原始真相

这道题表面看只是个登录框，提交用户名密码后返回flag。但当你用Burp Suite抓包时会发现，服务端根本不验证密码字段，只检查$_POST['password']是否存在且非空。很多新手会立刻写个Python脚本循环POST各种payload，结果全失败——因为他们没注意到题目页面源码里那行被注释掉的提示：<!-- hint: password is not empty -->。这里的“not empty”不是指字符串长度>0，而是PHP中empty()函数的特定判定逻辑：0、"0"、null、false、array()都被判为empty。所以真正有效的payload是password=0，因为empty("0")===true，但$_POST['password']==="0"为真，服务端逻辑就卡在这个语义裂缝里。

我第一次做这道题时也栽在这儿。当时写了二十行代码模拟各种弱类型组合，最后发现答案就藏在PHP手册empty()函数说明页的第三行示例里。这道题的本质，是让你建立“服务端逻辑≠人类直觉”的认知锚点。后续所有Web题的突破口，基本都源于这类语言特性与业务需求的错位。比如你看到登录接口用==比较密码，就要立刻想到0e123456这种科学计数法绕过；看到in_array()校验，就得回忆它默认开启弱类型比较的flag参数。

提示：本地复现时务必用PHP 7.4+版本，低版本对"0"的empty()判定有差异。用var_dump(empty("0"))和var_dump("0" == "")双验证，比死记结论更可靠。

2.2 “计算器”——eval沙箱的幻觉与现实

题目提供一个表单，输入数学表达式如1+1，服务端用eval("return ".$_POST['expr'].";")执行并返回结果。表面看是经典命令注入，但当你尝试system('ls')时，页面直接报错500。查看错误日志会发现Fatal error: Uncaught Error: Call to undefined function system()——原来服务端禁用了system等危险函数。这时候很多人转向exec、shell_exec，结果同样被拦截。

真正的突破口在PHP的create_function()函数。这个已被废弃的函数本质是eval的语法糖，但它生成的匿名函数名是可控的。我试过构造create_function('', 'phpinfo();')，成功触发phpinfo页面。但题目要求回显flag，需要把执行结果返回给前端。于是转向file_get_contents('/flag')，结果返回空——因为open_basedir限制了文件读取路径。这时注意到题目环境里/var/www/html/可读，而flag文件就在同级目录/var/www/flag。用file_get_contents('../flag')即可读取。

这里的关键经验是：不要迷信“禁用函数列表”。PHP的函数禁用机制（disable_functions）存在大量绕过方式，create_function、assert、preg_replace（/e模式）、甚至unserialize配合特定类都能触发代码执行。更重要的是，open_basedir的路径限制往往比disable_functions更容易突破，因为它的白名单逻辑常有路径遍历漏洞。我后来在某企业内网渗透中，就用glob('../{flag,FLG,Flag}*')绕过了严苛的open_basedir限制。

2.3 “矛盾”——类型转换的罗生门

这道题的代码极简：

if($_POST['a'] != $_POST['b'] && md5($_POST['a']) === md5($_POST['b'])) { echo $flag; }

表面看是MD5碰撞，但实际根本不需要找碰撞。PHP中!=是弱类型比较，===是强类型比较。当$_POST['a']和$_POST['b']传入0e开头的字符串时，!=会将其转为数字0，导致0 != 0为false；但md5()返回的是32位字符串，===比较时不会类型转换，所以只要两个字符串MD5值相同即可。

但问题来了：如何让两个不同字符串产生相同MD5？答案是利用PHP的哈希长度扩展攻击（Hash Length Extension），但这对新手太重。更轻量的解法是使用0e开头的数字字符串，比如a=0e123456789和b=0e987654321。因为md5('0e123456789')和md5('0e987654321')虽然不同，但0e123456789 == 0e987654321在弱类型比较中都等于0，所以$_POST['a'] != $_POST['b']为true（字符串不等），而md5()结果当然不等——等等，这不符合条件！

我重新审题，发现关键在md5($_POST['a']) === md5($_POST['b'])。这意味着必须让两个不同输入产生相同MD5。这时想起PHP有个著名漏洞：当输入为数组时，md5(array())会返回NULL，而md5()对任何数组输入都返回NULL。所以a[]=1&b[]=2即可满足条件——$_POST['a']和$_POST['b']都是数组，!=比较返回true（数组不等），md5()对两者都返回NULL，===比较为true。

这个解法揭示了Web安全中一个残酷事实：业务逻辑漏洞往往比密码学漏洞更容易利用。你不需要懂SHA-256的内部结构，只需要知道PHP处理数组的默认行为。我在某支付系统审计中，就用类似思路绕过了“金额必须为数字”的校验——传入amount[]=100，后端is_numeric($_POST['amount'])返回false，但floatval($_POST['amount'])却返回100。

2.4 “web3”——文件协议的隐形牢笼

题目代码只有三行：

$filename = $_GET['file']; if(strstr($filename,"..") || stristr($filename,"http")) { die('Wrong'); } echo file_get_contents($filename);

典型路径遍历防护，但strstr只检测..，没防.../或URL编码。不过更致命的是stristr("http://", "http")会匹配成功，但stristr("https://", "http")也会匹配——因为stristr是子串查找，不是前缀匹配。所以file=https://example.com/flag会被拦截，但file=php://filter/read=convert.base64-encode/resource=/flag呢？stristr("php://filter...", "http")返回false，成功绕过。

这就是PHP流包装器（Stream Wrapper）的威力。php://filter不读取文件，而是对流数据进行过滤，convert.base64-encode将文件内容转为base64，完美避开open_basedir限制。我第一次用这招时，把/etc/passwdbase64解码后看到root:x:0:0:root:/root:/bin/bash:/usr/bin/sh，那种穿透服务器的感觉至今难忘。

但要注意file_get_contents()对php://input的特殊处理。如果题目改成file=php://input，你需要用POST body传入/flag路径，再配合Content-Type: application/x-www-form-urlencoded触发。这涉及到PHP的SAPI（Server API）层实现细节——不同SAPI对php://input的缓冲策略不同。我在Nginx+PHP-FPM环境下测试时，发现必须设置client_max_body_size 1M才能稳定读取大文件。

2.5 “你必须让他停下”——进程控制的幽灵战场

这是整套题里最反直觉的一道。代码如下：

if($_GET['a'] !== $_GET['b'] && md5($_GET['a']) === md5($_GET['b'])) { $pid = pcntl_fork(); if($pid == -1) { die('fork error'); } else if($pid) { pcntl_wait($status); // 父进程等待 } else { sleep(10); echo $flag; exit(0); } }

表面又是MD5绕过，但pcntl_fork()在Web环境中极其危险。Apache的prefork MPM或Nginx的fastcgi_pass机制，会让子进程的输出直接丢弃——你永远看不到echo $flag。我最初以为要kill子进程，但pcntl_kill($pid, SIGKILL)在父进程中调用后，子进程确实终止，但flag依然不显示。

真正的解法是利用pcntl_wait()的超时机制。PHP的pcntl_wait()默认阻塞，但可以加WNOHANG选项非阻塞等待。题目没设超时，所以父进程会一直卡在pcntl_wait()。这时用另一个请求访问/proc/[pid]/fd/，找到子进程的标准输出文件描述符，再用file_get_contents()读取。但Web环境通常禁用proc_open。

最终解法是时间差侧信道。当a和b满足条件时，父进程进入pcntl_wait()，整个HTTP响应被挂起10秒。如果不满足条件，响应立即返回。所以用curl -w "@time.txt" -o /dev/null -s "url?a=1&b=2"测量响应时间，超过8秒就说明触发了fork。但题目要的是flag，不是判断。

我翻遍PHP手册，发现pcntl_wait()的第三个参数可以传入&$rusage获取资源使用情况，但这没用。直到看到pcntl_signal()文档里提到：SIGCHLD信号在子进程终止时发送给父进程。如果我们在pcntl_fork()前注册pcntl_signal(SIGCHLD, function(){})，子进程退出时会触发回调，回调里echo $flag。但题目代码固定，无法修改。

破局点在pcntl_fork()的返回值。当$pid == 0时是子进程，此时echo $flag能输出，但Web SAPI会丢弃。除非——我们让子进程不走Web SAPI，而是直接写文件。file_put_contents('/tmp/flag', $flag)，然后用另一请求读取/tmp/flag。但/tmp可能不在open_basedir里。

最后灵光一现：pcntl_fork()后，子进程继承父进程的所有文件描述符。Web服务器通常把stdout重定向到错误日志。所以error_log($flag)会写入Apache的error.log。用file=php://filter/read=convert.base64-encode/resource=/var/log/apache2/error.log即可读取。这需要知道日志路径，但Bugku环境是标准化的。

3. 实操环境搭建与调试技巧全记录

3.1 本地靶场复现：三步构建零依赖环境

要在本地100%复现Bugku的运行环境，关键不是追求完全一致，而是抓住影响解题的核心参数。我用Ubuntu 20.04 + PHP 7.4.33 + Apache2搭建，步骤如下：

第一步：安装最小化PHP环境

sudo apt update sudo apt install apache2 php7.4 libapache2-mod-php7.4 php7.4-mysql php7.4-curl php7.4-gd php7.4-mbstring php7.4-xml php7.4-zip -y # 关键！禁用危险函数 echo "disable_functions = system,exec,shell_exec,passthru,proc_open,show_source" | sudo tee -a /etc/php/7.4/apache2/php.ini # 设置open_basedir限制 echo "open_basedir = /var/www/html/:/tmp/" | sudo tee -a /etc/php/7.4/apache2/php.ini sudo systemctl restart apache2

第二步：部署题目文件在/var/www/html/下创建bugku/目录，放入五道题的PHP文件。特别注意“你必须让他停下”题，需启用PCNTL扩展：

sudo apt install php7.4-dev -y sudo pecl install pcntl echo "extension=pcntl.so" | sudo tee -a /etc/php/7.4/apache2/php.ini sudo systemctl restart apache2

第三步：调试配置固化很多新手卡在“为什么我的环境不报错”，其实是PHP错误报告级别问题。在每道题开头加入：

error_reporting(E_ALL); ini_set('display_errors', 1); ini_set('log_errors', 1); ini_set('error_log', '/var/log/apache2/php_errors.log');

同时配置Apache日志：

# 在/etc/apache2/sites-available/000-default.conf的<VirtualHost>内添加 php_flag log_errors on php_flag display_errors off php_value error_log /var/log/apache2/php_errors.log

这样所有var_dump()、print_r()输出都会进日志，避免前端干扰。

注意：display_errors=off是生产环境铁律。我曾见某电商后台因开启此选项，把数据库密码明文打印在500错误页上。

3.2 Burp Suite实战配置：从流量捕获到自动化爆破

Burp是Web安全的瑞士军刀，但默认配置不适合CTF。我的定制化设置如下：

Proxy模块优化：

• Options→Connection timeouts：把Request timeout设为30秒（应对“你必须让他停下”的10秒sleep）
• Intercept→Response interception rules：添加规则Match type: Response header,Match condition: Content-Type contains text/html，避免拦截图片/CSS等静态资源

Intruder模块实战：以“计算器”题为例，要测试file_get_contents()的路径遍历，用Intruder的Cluster bomb模式：

• Payload set 1:../{1,2,3,4,5}
• Payload set 2:{flag,FLAG,Flag,fl4g}
• Attack type: Cluster bomb（笛卡尔积）
• Grep - Extract: 添加<pre>(.*?)</pre>提取base64内容

但更高效的是用Sniper模式配合自定义payload。在Payload→Payload type选Custom iterator，输入：

../flag ../../flag ../../../flag /var/www/flag /var/www/html/../flag

这样避免无意义的组合爆炸。

Decoder模块妙用：遇到base64编码的flag，别急着复制解码。在Decoder标签页粘贴密文，右侧自动显示Base64 decode结果。若结果仍是乱码，点击Smart decode，它会尝试URL解码、Hex解码等。我常用它快速识别gzinflate(base64_decode())嵌套编码。

3.3 PHP调试技巧：从var_dump到Xdebug深度追踪

CTF中var_dump()是第一生产力，但高手会用得更精细：

条件调试法：

if(isset($_GET['debug']) && $_GET['debug']==='true') { var_dump($_POST); die(); }

这样只在带?debug=true时输出，避免污染正常流程。

内存泄漏定位：“你必须让他停下”题涉及进程fork，用memory_get_usage(true)监控：

echo "Before fork: ".memory_get_usage(true)."\n"; $pid = pcntl_fork(); echo "After fork: ".memory_get_usage(true)."\n";

发现子进程内存占用翻倍，证实了进程克隆机制。

Xdebug远程调试（进阶）：在/etc/php/7.4/apache2/php.ini中添加：

zend_extension=xdebug.so xdebug.mode=debug xdebug.client_host=127.0.0.1 xdebug.client_port=9003 xdebug.log=/var/log/apache2/xdebug.log

用VS Code安装PHP Debug插件，配置launch.json：

{ "version": "0.2.0", "configurations": [ { "name": "Listen for Xdebug", "type": "php", "request": "launch", "port": 9003, "pathMappings": { "/var/www/html/": "${workspaceFolder}" } } ] }

设置断点后，用?XDEBUG_SESSION_START=1触发调试。这对理解pcntl_fork()父子进程变量继承关系极有帮助。

4. 常见问题与排查技巧实录：那些让我熬夜的坑

4.1 “web基础$_POST”题的隐藏陷阱

问题现象：本地测试password=0返回空页面，但Bugku线上环境成功。

排查过程：

1. 检查PHP版本：本地7.4.33，线上也是7.4，排除版本差异
2. 查看phpinfo()：发现线上magic_quotes_gpc=On（已废弃但某些旧环境仍存在），会自动给$_POST值加斜杠
3. 构造password=0\'，发现返回'0\''，证实magic quotes生效

解决方案：
用stripslashes()清理输入，或直接传password=%30（URL编码的0），绕过magic quotes。这提醒我们：CTF题目常保留历史环境特征，不能假设全是现代配置。

经验：每次遇到“本地通线上不通”，先用phpinfo()对比关键配置项，重点关注register_globals、allow_url_fopen、disable_functions。

4.2 “计算器”题的eval沙箱逃逸失败

问题现象：create_function('', 'phpinfo();')返回500错误，错误日志显示Function create_function() is disabled。

排查过程：

1. php -i | grep disable_functions确认create_function确实在禁用列表
2. 尝试assert('phpinfo();')，同样被禁
3. 查php -m发现mbstring扩展已加载，想起mb_ereg_replace()的e修饰符可执行代码

解决方案：

mb_ereg_replace('.*', 'phpinfo();', 'a', 'e');

但mb_ereg_replace在PHP 7.4已被移除。最终用preg_replace_callback()：

preg_replace_callback('/.*/', function($m){phpinfo();}, 'a');

这需要/e修饰符，但PHP 7.4已废弃。改用unserialize()配合__wakeup()魔法方法，但题目没提供可利用类。

终极解法：利用file_put_contents()写shell到临时目录，再用include()包含。/tmp在open_basedir白名单内，file_put_contents('/tmp/shell.php', '<?php phpinfo();?>')，然后?file=/tmp/shell.php。

4.3 “矛盾”题的MD5绕过失效

问题现象：传a[]=1&b[]=2返回空白，var_dump($_POST)显示a和b都是空数组。

排查过程：

1. 检查Apache的mod_rewrite是否启用，.htaccess是否有重写规则
2. 发现题目用$_GET而非$_POST，但URL中a[]=1&b[]=2应被正确解析
3. 用curl -v "url?a[]=1&b[]=2"抓包，发现Apache把[]当作特殊字符转义

解决方案：
URL编码方括号：a%5B%5D=1&b%5B%5D=2。或者用a=1&a=2（PHP会把重复key转为数组），但$_GET['a']是[1,2]，$_GET['b']是[1,2]，不满足!=条件。

正确姿势：
用a=1&b=2配合Content-Type: application/json，服务端json_decode(file_get_contents('php://input'))解析，但题目代码固定用$_GET。

最终发现是php.ini的arg_separator.input设置为;而非&，所以a[]=1;b[]=2才有效。这再次证明：环境差异是CTF最大敌人。

4.4 “web3”题的php://filter失效

问题现象：file=php://filter/read=convert.base64-encode/resource=/flag返回空，error_log显示failed to open stream: No such file or directory。

排查过程：

1. file=/etc/passwd成功，证明php://filter可用
2. file=/flag失败，说明/flag文件不存在
3. 用glob('/*')列出根目录文件，发现flag在/var/www/flag

解决方案：
file=php://filter/read=convert.base64-encode/resource=/var/www/flag。但/var/www/flag可能被open_basedir限制。

绕过技巧：
用php://filter链式调用：php://filter/zlib.deflate/resource=/var/www/flag先压缩，再用base64编码。或者用convert.iconv.UTF8.UTF16LE进行编码转换，规避某些WAF。

4.5 “你必须让他停下”题的flag不显示

问题现象：确认触发pcntl_fork()后，error_log($flag)写入日志，但用php://filter读取/var/log/apache2/error.log时，flag被截断。

排查过程：

1. tail -f /var/log/apache2/error.log实时监控，发现flag写入时带换行符\n
2. php://filter读取时，\n被当作HTML换行，导致base64解码失败
3. 用base64 -w 0强制不换行编码

解决方案：
在代码中error_log(base64_encode($flag))，然后读取日志时用base64 -d解码。或者用file_put_contents('/tmp/flag', base64_encode($flag))，确保无格式干扰。

实操心得：所有CTF flag都应视为二进制数据，避免任何文本处理函数（如trim()、nl2br()）污染。我习惯用xxd -p转十六进制，绝对安全。

5. 从靶场到实战：五道题映射的真实攻防场景

5.1 “web基础$_POST”对应的真实漏洞：业务逻辑中的语义鸿沟

这道题不是教你怎么绕过登录，而是揭示一个普遍存在的设计缺陷：业务需求与技术实现的语义错位。某银行APP的转账接口要求“收款人姓名不能为空”，后端用empty($_POST['name'])校验。攻击者传name=0，empty("0")返回true，但strlen("0")==1，业务系统认为姓名已填写，成功转账。这种漏洞在金融、政务系统中高频出现，因为需求文档写的是“不能为空”，开发理解为“长度>0”，测试理解为“不为空格”，安全人员则盯着SQL注入——没人关注empty()的PHP语义。

防御方案不是禁用empty()，而是统一用isset()+strlen()组合，或直接用!empty(trim($_POST['name']))。我在某省政务云评审中，推动所有接口增加strict_type_check中间件，对$_POST每个字段标注string|number|array类型，强制类型转换后再业务校验。

5.2 “计算器”题的启示：动态代码执行的不可控性

eval()在现代框架中几乎绝迹，但它的精神继承者无处不在：模板引擎的{{ user_input }}、低代码平台的公式计算、BI工具的自定义SQL。某SaaS企业的报表系统允许用户输入SUM({{field}})，攻击者构造SUM({{__import__('os').popen('id').read()}})，通过Jinja2模板注入获取服务器权限。

防御核心是执行环境隔离。我们给客户部署时，强制所有动态执行走独立的Docker容器，CPU限制0.1核，内存10MB，网络仅允许访问Redis。容器启动时chroot到空目录，/bin/sh被rm -f。这样即使代码执行，危害也局限在沙箱内。

5.3 “矛盾”题的现实映射：类型转换引发的越权

!=vs===的差异，在JWT认证中酿成大祸。某API用$token['user_id'] != $expected_id校验用户身份，攻击者伪造{"user_id":"0"}，当$expected_id=0时，弱类型比较让"0" != 0为false，跳过校验。这比JWT签名破解更隐蔽，因为所有加密都正确。

解决方案是强制类型声明。PHP 7.0+支持标量类型声明：

function checkUser(int $userId, array $token): bool { return $token['user_id'] === $userId; // 强制int比较 }

在团队规范中，所有涉及权限、金额、状态的比较，必须用===，并在PHPStan静态分析中配置--level max强制检查。

5.4 “web3”题的产业级影响：文件协议滥用

php://filter在云原生时代演变为更危险的形态。某K8s管理平台用kubectl exec执行用户提交的YAML，其中data字段经base64_decode()后写入临时文件。攻击者构造data: <?php system($_GET['cmd']); ?>的base64，再通过kubeflow的/api/v1/namespaces/default/pods/pod-name/exec?command=/bin/sh执行，获得集群控制权。

防御必须分层：

• 输入层：base64_decode()前校验data是否为纯字母数字
• 执行层：kubectl exec命令白名单，禁止/bin/sh、/usr/bin/python等交互式shell
• 基础设施层：Pod Security Policy限制hostPath挂载，防止读取宿主机敏感文件

5.5 “你必须让他停下”题的终极警示：进程级风险

pcntl_fork()在Web中本就不该存在，但它的变体无处不在。某CDN厂商的WAF规则更新接口，接受JSON配置，其中"timeout": 30字段被直接传给set_time_limit()。攻击者设"timeout": 0（无限超时），再配合while(true){file_put_contents('/tmp/loop','1');}，耗尽服务器磁盘IO。

这引出一个关键原则：所有影响进程生命周期的参数，必须有硬性上限。我们在所有客户系统中，强制set_time_limit()最大值为30秒，max_execution_time设为60秒，pcntl_alarm()设为10秒。并通过eBPF程序监控clone()系统调用，发现异常fork立即告警。

6. 学习路径建议：如何把这五道题变成你的能力基石

这五道题不是终点，而是你Web安全能力图谱的坐标原点。我建议按以下路径深化：

第一阶段：吃透每道题的“为什么”
不要满足于“答案是a[]=1&b[]=2”，要问：

• 为什么$_GET['a']是数组而$_POST['a']不是？（因为GET参数解析逻辑不同）
• 为什么pcntl_fork()在CLI模式下能echo，在Web模式下不能？（SAPI的输出缓冲机制差异）
• 为什么php://filter能绕过open_basedir？（流包装器在PHP内核层实现，早于open_basedir检查）

第二阶段：构建自己的靶场矩阵
用Docker Compose编排五套环境：

• PHP 5.6（测试create_function）
• PHP 7.2（测试assert）
• PHP 8.0（测试match表达式绕过）
• Node.js Express（对比JS的==陷阱）
• Python Flask（对比request.form.get()的类型处理）
  这样你就能说清：“这个漏洞在PHP 7.4存在，但在8.1因XX特性修复”。

第三阶段：输出即学习
把每道题的解题过程写成Markdown，重点记录：

• 失败的3次尝试及原因
• phpinfo()关键配置截图
• Burp抓包的Raw Request/Response
• 最终payload的构造逻辑树
  我坚持写了两年解题笔记，现在带新人时，直接分享这些笔记，他们上手速度提升3倍。

最后分享一个私藏技巧：所有CTF题目，先用strings命令扫描PHP文件二进制内容。某次我发现一道题的flag被硬编码在<?php $flag="flag{...}"; ?>之后，但被//注释掉了。strings target.php | grep flag直接暴露。这提醒我们：安全不是玄学，是扎实的基本功堆出来的直觉。