CTF靶场实战：绕过前端JS过滤的手工SQL注入全解析

在CTF竞赛和Web安全测试中，前端JavaScript过滤机制常常是新手遇到的第一个"拦路虎"。许多选手发现输入单引号或特殊字符后毫无反应就束手无策，其实这背后往往隐藏着前端验证的"障眼法"。本文将带你完整还原一次真实的渗透测试过程，从发现JS过滤到最终获取flag，重点解析那些容易被忽略的思维转折点。

1. 初识前端过滤：从异常现象到问题定位

当你在靶场输入admin'却没有任何错误回显时，第一反应不应该是放弃，而是打开开发者工具（Chrome按F12）。在Sources标签页中，查找与当前页面关联的JS文件，通常命名为validation.js、filter.js或直接嵌入在HTML的<script>标签内。

javascript复制// 典型的前端过滤代码示例
function sanitizeInput(input) {
    return input.replace(/['"\\;]/g, '');
}

这种过滤模式会静默删除特殊字符，导致你的注入尝试看似无效。此时需要验证两个关键点：

• 过滤是否仅在前端生效（禁用JS后测试）
• 被过滤的具体字符列表（通过逐个字符测试）

提示：现代浏览器通常提供"Disable JavaScript"选项，在Chrome DevTools的Settings > Debugger中可快速切换

2. 突破前端防线：三种禁用JS的实战方法

2.1 浏览器开发者工具法

1. 右键点击输入框选择"检查"
2. 在Elements面板找到对应表单元素
3. 右键选择"Break on" > "Attribute modifications"

2.2 使用扩展程序拦截

• Chrome插件如"JavaScript Switch Off"
• Firefox的"Disable JavaScript"上下文菜单项

2.3 命令行启动浏览器

bash复制# Chrome无JS模式
google-chrome --disable-javascript

方法对比表：

3. 手工注入实战：从基础探测到信息提取

当JS被禁用后，真正的注入才开始。以典型的新闻搜索系统为例，按照以下步骤层层推进：

3.1 基础注入点确认

sql复制' AND 1=1 -- 
' AND 1=2 -- 

观察页面返回差异，确认存在数字型还是字符型注入

3.2 字段数探测

sql复制' ORDER BY 5 -- 

逐步增加数字直到页面报错，确定查询返回的列数

3.3 联合查询构造

假设已知字段数为3：

sql复制' UNION SELECT 1,2,3 -- 

通过页面显示位置确定哪些列会被输出

3.4 数据库信息提取

sql复制' UNION SELECT 1,table_schema,table_name FROM INFORMATION_SCHEMA.TABLES -- 

获取所有可访问的数据库和表名

4. 高阶技巧：绕过过滤的替代方案

即使无法完全禁用JS，仍有多种绕过方案：

4.1 字符编码变形

sql复制' → %27
" → %22
# → %23

4.2 字符串拼接技巧

sql复制CONCAT('adm','in') 替代 'admin'

4.3 注释符变体

sql复制--   → # 
/*!MySQL特有注释*/

5. 信息收集与flag定位

通过INFORMATION_SCHEMA获取元数据后，典型的数据定位流程：

1. 识别可疑数据库（非系统库）
2. 检查表结构（特别是admin/user等表）
3. 查找flag/secret/password等列
4. 最终payload示例：

sql复制' UNION SELECT 1,flag,3 FROM secret.flag_table -- 

6. 防御视角：从攻击中学习安全编码

理解攻击手段才能更好防御，开发者应该：

• 始终在后端进行输入验证
• 使用参数化查询（Prepared Statements）
• 最小化数据库账户权限
• 禁用错误详情回显

在Burp Suite中测试时，可以观察到原始请求的构造方式。对比手工注入和sqlmap自动化的差异，后者虽然高效但会留下明显日志痕迹。真正的安全测试需要根据场景灵活选择方法，手工注入的价值在于精准控制每一步操作。

遇到实际CTF题目时，建议先完整走通手工流程，再考虑自动化工具。这就像学习编程要先理解底层原理一样，只有掌握基础才能在复杂场景中随机应变。