表单隐藏域漏洞

去年某电商平台被曝出用户数据泄露，表单起因是隐藏域漏一个看似不起眼的表单隐藏域。攻击者通过修改前端HTML代码，表单把原本固定的隐藏域漏商品价格字段改成任意数值，下单时服务端居然照单全收。表单一毛钱买走一部手机，隐藏域漏这事听起来离谱，表单但漏洞就藏在那个看不见的隐藏域漏input标签里。

隐藏域（hidden input）在前端开发里太常见了。表单它的隐藏域漏本意是好的——传递一些用户不需要看到、但后端需要的表单数据，比如用户ID、隐藏域漏订单号、表单CSRF token。隐藏域漏问题在于，表单很多开发者把它当成了“安全字段”，以为用户看不见就改不了。这想法天真得可笑。浏览器的开发者工具按F12就能打开，改个value属性比打字还快。就算不做任何技术操作，用Burp Suite或者Postman拦截请求，想改什么改什么。

我见过一个更离谱的案例。某在线考试系统，试卷答案的正确答案选项直接写在隐藏域里，提交时前端拿这个值跟用户选的比对，然后把分数传给后端。学生只要打开控制台，所有答案一目了然。这已经不是漏洞了，是把答案贴在黑板上还指望没人抄。

隐藏域漏洞的本质是什么？是信任边界搞错了。前端的一切数据——不管是隐藏域、cookie还是localStorage——都经过用户浏览器，都不可信。服务端必须对每一个关键字段做校验。价格字段，后端得从数据库重新查；用户ID，得从session里取；权限标识，得在服务端鉴权。你不能因为前端传了个“isAdmin=true”就真把管理员权限给出去。

有人会说，那我加密隐藏域的值不就行了？加密确实能增加一点门槛，但密钥如果也在前端，那就是自欺欺人。混淆、Base64编码这些手段同理，只能防住完全不懂技术的人。真正的攻击者花几分钟就能逆向出来。

还有一种情况是批量赋值漏洞和隐藏域的组合。比如用户表有个role字段，前端表单里藏了一个<input type="hidden" name="role" value="user">，后端用ORM的批量赋值直接把请求参数映射到模型上。攻击者把value改成admin，提交后角色就变了。这类漏洞在Ruby on Rails早期版本里特别多，后来框架加了strong parameters才好转。

怎么防？思路很直接。第一，凡是涉及金额、权限、身份的关键数据，一律不放在前端。需要的话，用服务端session存。第二，如果非要用隐藏域传值，后端收到后必须重新验证。比如订单提交时带了product_id，后端要查这个商品是否存在、价格是多少、库存够不够，而不是信前端传过来的price。第三，CSRF token这类必须放前端的，要保证它是一次性的、有时效的、和用户session绑定的。第四，别用批量赋值，显式地逐个字段读取和校验。

我自己的习惯是，每次看到表单里有hidden字段，条件反射地想一下：这个值如果被改了，会出什么事？如果答案是“能改价格”或者“能提权”，那这个设计就是有问题的。隐藏域不是安全机制，它只是个数据载体。把安全寄托在“用户看不到”上面，跟把钥匙藏在门口地毯下面没什么区别。

说到底，前端是用户的领地，后端才是你的地盘。任何从用户领地过来的东西，都得当成可疑包裹拆开检查。隐藏域只是其中一个包裹而已。