拼接后用于Prepared Statement的字符串是否会引发SQL注入？

这种拼接方式会引发SQL注入风险，不是只要最终用了PreparedStatement就一定能消除风险，核心取决于readRow函数处理传入的strWhere的方式。

具体分析 #

你的代码里存在两个关键风险点：

1. 直接拼接用户可控变量ID：如果ID是来自外部输入（比如用户提交的参数），直接拼进SQL字符串会让恶意输入被解析成SQL逻辑。比如ID传入1 OR 1=1，拼接后的strWhere会变成xxx AND (id=1 OR 1=1)，执行后会返回所有数据，完全绕过了原本的查询限制。
2. whereString的不可控性：如果whereString本身包含用户可控的内容，同样会把注入风险带入最终的SQL语句中。

PreparedStatement防注入的核心是参数化查询——它会把SQL结构和用户数据彻底分离，数据库会将参数当作纯数据处理，不会解析成SQL指令。但你的场景里，strWhere已经是拼接好的包含用户输入的完整SQL片段，readRow即便用了PreparedStatement，也只能把这个片段当作SQL语句的一部分直接执行，根本无法对里面的用户输入做参数化处理。

正确的做法 #

不要提前拼接包含用户输入的WHERE条件，而是用占位符?代替用户可控参数，将参数单独传递给readRow，让它在构建PreparedStatement时完成参数绑定：

String strWhere = whereString + " AND (" + Table1.ID + "=?)";
Rows = myTable.readRow(jdbcSource, strWhere, new Object[]{ID});

这里要求readRow函数支持接收参数数组，通过PreparedStatement.setXxx()方法将参数绑定到占位符上，这样才能真正避免SQL注入。

内容的提问来源于stack exchange，提问作者ethicalhacker