如何用PUT请求绕过表单限制

在渗透测试或安全审计中，常见的防御措施会把表单提交方式限制在 POST，并在服务器端对 Content‑Type、字段长度以及 CSRF token 进行严格校验。实际上，HTTP 协议本身并未禁止使用 PUT 进行数据写入，只要后端路由对方法没有显式排除，PUT 请求就能携带同样的表单负载，从而绕过前端的表单约束。

PUT 请求的技术原理

PUT 属于幂等的写操作，语义上表示“用请求体的内容完整替换目标资源”。在 RFC 7231 中明确指出，服务器应当接受任意合法的请求体，只要 Content‑Type 与资源匹配。因此，只要后端实现遵循 RESTful 风格且未对方法做白名单过滤，PUT 完全可以承载 application/x-www-form-urlencoded 或 multipart/form-data 等表单格式。

表单约束的常见实现

大多数 Web 框架在处理 POST 时会自动触发以下检查：
① 请求头必须包含合法的 Content‑Type；② 参数长度受到服务器端配置或业务规则限制；③ CSRF token 必须与会话匹配；④ 某些字段会被强制为只读或只接受特定枚举值。这些检查往往在路由层面仅针对 POST 编写，导致 PUT 请求直接跳过了这些防线。

利用 PUT 绕过限制的实战步骤

• 使用代理工具（如 Burp Suite）捕获目标页面的原始 POST 请求。
• 在抓包窗口中将 HTTP 方法改为 PUT，保持原始请求体不变。
• 如果服务器检查 Content‑Type，手动将头部改为 application/x-www-form-urlencoded 或相应的 multipart 编码。
• 发送修改后的请求，观察响应是否返回预期的业务数据或包含隐藏的 token。
• 对返回的 base64 编码或加密字符串进行解码/解密，获取可能的 flag 或敏感信息。

curl -X PUT "https://example.com/api/submit" 
     -H "Content-Type: application/x-www-form-urlencoded" 
     -d "username=admin&password=SuperSecret&token=abc123"

从防御角度来看，最直接的修复思路是让后端在路由层统一检查 HTTP 方法，而不是仅在 POST 处理函数中做安全校验；同时在全局中对所有写操作统一执行 CSRF 验证和请求体大小限制。否则，即使前端表单隐藏了某些字段，攻击者仍能通过 PUT 把任意负载写入后端。