POST注入比GET注入更隐蔽，注t注也更危险。入p入很多人以为登录框、注t注搜索框只是入p入普通功能，实际上它们经常是注t注数据库的裸奔入口。

拿一个真实案例说事。入p入某后台管理系统，注t注登录表单长这样：用户名输入框，入p入密码输入框，注t注一个登录按钮。入p入看起来人畜无害。注t注但后端代码写的入p入是：

SELECT * FROM users WHERE username='$user' AND password='$pass'

变量直接拼进SQL语句，没做任何过滤。注t注攻击者在用户名框输入：admin' -- ，入p入密码随便填。注t注拼接后的SQL变成：

SELECT * FROM users WHERE username='admin' -- ' AND password='whatever'

两个连字符把后面的密码判断注释掉了。绕过登录，直接以admin身份进入后台。整个过程就是一次正常的POST请求，日志里看起来只是有人登录失败了一次，实际上已经拿下管理员权限。

POST注入和GET注入的本质完全一样——都是用户输入被当成了SQL代码执行。区别只在传输方式。GET参数挂在URL上，容易被日志记录、被浏览器历史保存、被Referer泄露。POST参数在请求体里，默认不被记录，也不出现在地址栏。这就让POST注入的隐蔽性高了一个档次。

实际渗透测试中，POST注入最常见的场景是登录框、搜索框、反馈表单、JSON API接口。尤其现在前后端分离，大量数据通过POST的JSON格式提交。有些开发者会对GET参数做防护，却忽略了POST体里的字段。我见过一个订单查询接口，GET请求查商品没问题，但POST提交订单ID时直接把参数拼进了SQL，结果订单数据全被拖走。

检测POST注入有个笨办法但很有效。在表单里输入一个单引号'，看返回结果。如果页面报错、白屏、或者返回500，说明单引号影响了SQL结构。再输入' OR '1'='1，如果返回了全部数据，那基本实锤了。注意看响应时间，有些注入点存在延迟，可以用AND SLEEP(5)来判断布尔盲注。

POST注入的利用方式比GET更多样。除了直接绕过认证，还能用UNION查询提取数据。比如一个搜索框，正常输入“手机”返回相关商品。注入' UNION SELECT username,password FROM users -- ，如果字段数对齐，用户名密码就全出来了。更狠的是堆叠注入，直接在输入里分号结束当前语句再执行新语句，比如'; DROP TABLE orders; -- ，如果数据库允许多语句执行，整个表就没了。

防护手段其实不复杂。参数化查询是首选，用预处理语句把数据和SQL分离，让用户输入永远只是数据，不可能变成代码。其次是输入验证，对类型、长度、字符集做白名单限制。但别迷信过滤函数，黑名单式的过滤总有漏网之鱼。比如把select过滤了，攻击者写SeLeCt就能绕过，因为MySQL默认不区分大小写。还有用注释符/*!50000SELECT*/这种MySQL特性写法，也能绕过简单过滤。

说句实在话，POST注入之所以泛滥，根本原因是很多开发人员没把用户输入当敌人。总觉得后台系统没人知道，或者认为POST比GET安全。这种心态才是最大的漏洞。攻击者扫描工具扫一遍全网，POST端点照样被翻个底朝天。安全从来不是靠隐蔽实现的，而是靠代码层面的严格约束。

最后留个检查点：翻翻你的项目代码，凡是拼接SQL的地方，不管是GET还是POST，全部改成参数化查询。改完再测一遍登录、搜索、数据提交这几个功能，确保没有遗漏。别等到被拖库了才后悔——那时候数据库里的数据早就挂在暗网上了。