HTML表单漏洞怎么找？常见安全隐患排查步骤-html教程-PHP中文网

html表单未做输入校验、隐藏字段未二次验证、csrf token未绑定session、textarea/contenteditable未过滤，均构成高危漏洞；须从前端校验完整性、后端数据重验、token动态绑定及富文本净化四方面系统加固。

html表单漏洞怎么找？常见安全隐患排查步骤

HTML表单没做输入校验，`onsubmit` 里直接发请求就是高危信号

很多前端开发者以为“后端会拦”，于是把表单 onsubmit 逻辑写成纯 JS 提交、不校验、不转义、不防重放，结果攻击者用浏览器控制台改掉 action 或直接调用 fetch() 就能绕过所有前端限制。这种场景下，表单本质是“透明管道”，恶意数据直通后端。

实操建议：

Doc To HTML

使用 MinerU 文档处理引擎将 Word 文档（.doc、.docx）转换为保留结构和格式的干净 HTML。

下载

检查所有 <form></form> 是否有 novalidate 属性且未补充 JS 校验——这等于主动关闭浏览器原生校验
搜索项目中所有 document.querySelector('form').addEventListener('submit', ...)，看回调里是否含 event.preventDefault() 但缺失 input.value 检查逻辑
用浏览器 DevTools → Elements 面板临时删掉 type="email" 或 pattern 属性，再提交非法值（如 <script>alert(1)</script>），观察后端是否报错或渲染出脚本

`textarea` 和 `contenteditable` 是 XSS 温床，别信“用户只输文字”

开发者常忽略富文本类表单控件的危险性。textarea 虽默认不执行 HTML，但一旦后端拼接进页面（比如评论列表）、又没做 textContent 赋值或服务端转义，就直接触发反射型 XSS；而 contenteditable 更危险——它允许用户粘贴带 <img onerror="..."> 的 HTML 片段，且多数前端框架不会自动 sanitize。

实操建议：

对所有接收 textarea 内容的接口，用 Burp Suite 或 curl 手动发含 <svg onload="alert(1)"></svg> 的 POST 请求，看响应体是否原样返回该 payload
检查前端是否用 innerHTML = data 渲染表单输出，替换成 textContent = data 或通过 DOMPurify.sanitize() 处理
若用 contenteditable，确认是否引入了 Quill / TinyMCE 等编辑器——它们自带 sanitizer，但需显式开启，例如 quill.clipboard.dangerouslyPasteHTML = false

隐藏字段 `<input type="hidden">` 不是安全边界，后端必须重新校验

常见错误是把权限标识、价格、状态等关键参数塞进 type="hidden"，认为“用户看不到就不会改”。但审查元素两秒就能修改 value，再点提交，后端若直接信任该值，就等于把鉴权/计价逻辑交给了客户端。

实操建议：

全局搜索 <input type="hidden">，逐个确认对应字段是否在后端有二次校验（例如订单金额是否与数据库中商品单价 × 数量一致）
重点检查涉及金钱、权限、状态流转的 hidden 字段，如 name="role"、name="price"、name="status"
用浏览器插件（如 EditThisCookie 或 Requestly）拦截表单请求，手动篡改 hidden 字段值，观察后端是否拒绝或静默接受

CSRF token 没绑定 session 或没校验，`POST` 表单形同虚设

加了 <input name="csrf_token" value="xxx"> 不代表安全。如果 token 是静态字符串、或从 URL 参数读取、或校验时没比对当前 session ID，攻击者就能伪造请求。典型表现是：登录态下，用另一个网页的 <form action="https://yoursite.com/transfer" method="POST"></form> 也能成功转账。

实操建议：