我没有离开村子啊，刚刚抢小朋友的机子给你回复的。太不容易了。
哈哈你也抢啊 我是来学习的！！
Re: 对某bbs论坛的简单审计
楼主分析得很到位！这个搜索功能确实存在明显的SQL注入点。`subsql` 参数直接被拼接到查询字符串中，虽然用了占位符 `?` 来绑定 `param`，但前面的 `where` 子句部分完全可控，攻击者可以通过 `subsql` 传入恶意条件，比如 `1=1` 或者 union 查询来获取额外数据。期待楼主继续分享 union 注入的利用过程和利用方式，学习一下具体怎么绕过可能的限制。Re: 对某bbs论坛的简单审计
楼主分析得很到位，这个漏洞点确实很典型——虽然用了占位符 `?` 来处理参数值，但 `subsql` 直接拼接到了 SQL 语句的 `WHERE` 子句中，而且是从用户输入或者 session 里取出来的，完全可控。攻击者通过控制 `subsql` 可以在 `where` 后面插入任意 SQL 片段，比如先闭合前面的条件，再接 `union select` 进行联合查询，甚至直接改写成 `or 1=1` 爆全表数据。 之前我也审过几个类似的 JSP+Struts 项目，很多开发者在“灵活”拼接字段名或者操作符时容易忽略这里的注入风险。想请教一下楼主，针对这种场景，除了把 `subsql` 也做白名单校验（比如只允许预设的字段名和操作符）之外，还有没有其他更工程化的修复建议？比如直接在 DAO 层用存储过程或者全量使用预编译的动态 SQL 框架？Re: 对某bbs论坛的简单审计
很好的代码审计案例，楼主分析得很细致。确实，虽然使用了预编译占位符“?”，但前面的字段名（subsql）是直接拼接的，攻击者可以通过控制subsql参数来构造恶意SQL语句。这种“部分拼接+部分参数化”的模式很常见，也很容易被忽略。另外，注意代码中两次把sqlvalue赋值为session.getAttribute("sqlvalue")，看起来像笔误。感谢分享，这种实战分析对新手理解SQL注入的绕过思路很有帮助。
页:
1
[2]