HTML表单本身不触发SQL注入，真正风险在于后端是否将未过滤的表单数据拼入SQL语句；必须用参数化查询防御，前端校验无效且可被绕过。
HTML表单本身不会触发SQL注入，但它是最常被用来传递恶意SQL载荷的入口——排查重点不是“表单有没有漏洞”，而是“后端是否把表单数据拼进SQL语句且未做参数化处理”。
怎么看表单提交的数据是否被拼接到SQL里
前端无法直接看到SQL执行过程，但可通过请求和响应行为反推风险：
- 用浏览器开发者工具（F12）→ Network 标签页，提交表单，观察请求方法（
GET或POST）、URL参数（如?id=1、?username=test）和请求体内容 - 修改一个参数值为
' OR '1'='1，提交后看响应：若页面返回异常多数据、报错信息含MySQL/Microsoft SQL Server等字样，或登录绕过成功，说明后端很可能在拼SQL - 检查响应头中是否有
X-Powered-By、Server字段，结合FOFA语法搜索同类技术栈已知漏洞（如body="phpMyAdmin" && title="Login"）
哪些表单字段最危险，必须优先测
并非所有字段都等价。以下字段因常用于数据库查询，应作为第一轮测试目标：
-
id、uid、user_id：数字型ID，尝试1 and 1=1/1 and 1=2观察响应差异 -
username、email、search：字符串型，必须加引号闭合，测试载荷如admin' --、test' OR '1'='1 -
order、sort、limit：常用于ORDER BY或LIMIT子句，易被用于基于时间的盲注（如sleep(5)） - 隐藏字段（
<input type="hidden">）：常被忽略，但可能包含关键查询条件，用开发者工具直接改值再提交
为什么禁用JavaScript或删掉required属性后还能提交成功？
这不表示“表单有漏洞”，而是在验证后端是否做了真正校验：
立即学习“前端免费学习笔记（深入）”；
- 删掉
required、改type="email"为type="text"、清空pattern正则——这些操作只绕过了前端约束 - 如果此时提交空值、超长字符串、含单引号的字符串（如
O'Reilly），后端仍正常接收并返回结果，说明它没做服务端过滤或参数化，风险极高 - 特别注意：某些后端会静默截断或转义单引号，但未统一处理所有上下文（比如在
WHERE和ORDER BY中转义逻辑不同），导致绕过
Burp Suite拦截改包时该关注什么
手工验证最可靠的方式是抓包篡改，关键不是“怎么改”，而是“改完看什么”：
- 发包前先确认原始请求是否带
Content-Type: application/x-www-form-urlencoded或application/json，不同格式解析逻辑不同 - 对每个参数单独测试，避免多个参数同时改造成干扰；例如只动
id=1→id=1' AND SLEEP(3)，其他字段保持原样 - 对比响应时间（不只是内容）：延迟明显增加（如从200ms到3200ms），大概率存在基于时间的盲注
- 留意HTTP状态码变化：从
200变成500是错误注入的典型信号；但有些系统会统一返回200+ 自定义错误页，需人工判断页面内容是否异常
真正的难点从来不在“怎么输payload”，而在于识别后端用了哪种数据库、是否启用错误回显、是否对空格/注释符做过滤、以及同一参数在不同SQL上下文（SELECT vs INSERT vs ORDER BY）中的行为是否一致——这些细节决定你写的那条 1' UNION SELECT 1,2,3-- 到底是报错、静默失败，还是真能吐出数据。
