伪静态注入

伪静态注入这事儿，伪静真没多少人当回事。态注多数人觉得，伪静不就是态注把动态链接rewrite成静态模样，能有什么风险？伪静我见过太多开发者在.htaccess或nginx配置里，把id=123变成/news/123.html，态注然后觉得万事大吉——结果SQL注入照样能打穿。伪静

问题出在哪？态注伪静态只是“看起来像静态”，本质还是伪静动态请求。你过滤了URL里的态注参数，但伪静态规则往往把参数嵌在路径里。伪静比如/news/123.html，态注服务器要解析出123这个值。伪静如果规则写得不严谨，态注比如/news/(.*).html，伪静那攻击者就能塞进去/news/1.html%20and%201=1之类的payload。你写过滤函数时，通常只检查$_GET['id']，可伪静态后参数是从PATH_INFO里取出来的——过滤逻辑根本没覆盖到那儿。

前阵子帮朋友排查一个站点，后台登录接口被人撞库，日志里全是尝试记录。查了半天，漏洞就在伪静态规则上。规则把/user/(\d+)\.html映射到user.php?uid=$1，但没限制必须是纯数字。攻击者直接请求/user/1%20union%20select%20...html，服务器解析后，数据库查询语句就变了。朋友说他们做了转义，可转义函数只处理了$_GET，没处理从URL里拆出来的那段。这算不算低级失误？算。但现实中这么干的人太多了。

更隐蔽的是编码绕过。伪静态规则经常用正则匹配，但正则没处理URL编码。攻击者把payload写成%27%20or%201%3D1，服务器解码后，正则已经匹配完了——规则匹配的是编码后的字符串，可后面查询用的是解码后的。两层逻辑不一致，中间全是操作空间。

要说怎么防，其实也简单。伪静态参数必须强校验类型，数字就只允许数字，字母就限定字符集。别指望拦截关键字，那玩意儿总有漏网之鱼。参数从哪个来源取，过滤就得覆盖哪个来源——PHP里别光查$_GET，$_SERVER['PATH_INFO']也得查。框架里如果用了路由，参数绑定后照样得走预编译或参数化查询，伪静态只是换了层皮，底层SQL执行逻辑没变。

有个真实案例挺典型。某电商站做SEO，把商品详情页全改成伪静态，像/product/iphone-15-256g.html。规则里商品名用(.*?)匹配，然后直接拼进数据库查询里查SKU。结果被人用/product/iphone-15-256g%27%20and%20sleep(5)--.html打时间盲注，页面卡了五秒才返回。运维一开始还以为是数据库负载高，后来抓包才发现是注入。这站用的还是国内知名框架，框架自带ORM，可开发图省事，在控制器里写了原生查询——框架的路由解析了伪静态URL，但参数没走ORM的绑定机制。

伪静态注入说白了，就是开发人员把“美观”和“安全”割裂了。URL好看是给用户看的，安全防护是给代码写的，可两者经常在中间地带脱节。你改了URL形态，却没同步调整所有输入处理逻辑。这跟直接改个参数名没什么本质区别，可很多人就栽在这层“伪装”上。我见过有些团队做安全测试，专门挑伪静态规则下手，因为知道这地方防守最薄弱。

别把伪静态当成安全措施——它就是个路由美化工具，跟安全半毛钱关系没有。如果你非要用，那就把规则写死，别用通配符匹配整段路径。参数能拆多少个就拆多少个，每个都单独校验。还有，日志里多记一下原始请求URL，别只记解析后的参数。排查问题的时候，原始URL能告诉你很多规则层的信息，参数只告诉你业务层发生了什么。这两层之间的差异，往往就是漏洞藏身的地方。

很赞哦!（4）