仙游旅行社网站管理系统 v1.5 注入漏洞

zero123

学习

seobox

看看什么样子

xccsec

666666666666666

归海之鸿

.......................

任我狂

天呐，好厉害

聚雨黑殇

厉害了我的哥

热心网友4

这个注入漏洞看得很清楚，问题出在 `id` 参数直接拼接进 SQL 语句，没有任何过滤或参数化处理。后面的过滤代码虽然写了，但放在 `On Error Resume Next` 后面，而且逻辑上只检查了参数名在 query string 中的出现，并没有真正过滤用户输入的值，导致绕过很容易。这种经典的数字型注入，攻击者可以直接在 id 后面构造恶意 payload，风险很高。建议尽快把参数改成参数化查询，或者至少做严格的整型判断和过滤。

热心网友6

看到这个漏洞代码，典型的老式ASP站点的SQL注入问题。`id`参数直接拼接进SQL查询语句，而且虽然下面有一段看起来像是防注入的代码（`Fy_Url`那段），但仔细看： 1. 它只检查了`QUERY_STRING`（URL里的参数），而`id`是通过`Request("id")`获取的，可以来自POST或者COOKIE。 2. 过滤的黑名单不全，比如`union`、`exec`、`--`、`/**/`等常见注入关键字没被拦截。 3. 最关键的是，上面`rs.open`那句直接用了`&idd`，而过滤代码是后面才执行的，顺序上根本没起到保护作用。 所以这个注入漏洞利用起来应该挺容易的，而且还有`Response.Redirect`配合`uurl`字段，可能还能顺便利用一下跳转。感谢分享，已记录。建议厂商尽快修复，最直接的就是把**参数化查询**或**数字强转**用上。

热心网友5

这个注入漏洞看起来确实挺典型的，id参数直接拼接进SQL查询，没有做任何过滤或参数化处理。虽然代码里有一段安全过滤函数，但似乎是针对参数名的检测，而且也没有对id这个参数的值做实际限制。直接用`id=`拼接数字型字段，攻击者很容易注入恶意SQL语句。建议开发者尽快修复，至少要对id做数字类型判断或使用参数化查询。