sql参数保护您什么?

参数化查询通常会在参数是幕后字符串时引用该参数,以便正常的SQL运算符不会被解释为这样。这意味着,即使用户输入了潜在的恶意数据,也只会将其视为字符串输入,而不会解释为SQL运算符/命令。

你需要小心你的定义。”“参数”可能意味着很多事情;例如,存储过程的参数本身并不能保护您。以Java为例:

sql = "exec proc_SearchForUser '" + userNameToSearch + "'";

不比生肉好也不比生肉差

sql = "SELECT * FROM Users WHERE userName = '" + userNameToSearch + "'";

';DROP TABLE users;--

另一方面,参数化查询是安全的。它们可能看起来像

PreparedStatement statement = con.prepareStatement("SELECT * FROM Users WHERE userName = ?");

或者确实

PreparedStatement statement = con.prepareStatement("exec proc_SearchForUser ?");

这是安全的,因为当您填写值时。。。用,比方说,,

statement.setString(1, userName);

然后,该字符串——即使是像“';DROP TABLE users;——”这样的字符串——也会被DB引擎正确转义并呈现为无害的。

仍然可以将它拧紧——例如,如果你的存储过程只是在内部构建SQL字符串并执行它,信任输入——但是用参数准备的语句意味着没有未逃脱的数据将永远到达DB服务器,完全切断该攻击向量。

不会。SQL注入攻击可以从任何SQL DB中的任何语言发生。您所指的攻击类型是当程序员在其源代码中使用动态SQL(如“USER_NAME=sName”)时,用户可以为用户名输入无限文本,以便添加注释,然后键入任何新的SQL语句,如“DROP”、“TRUNCATE”等。

通过bindWhather()调用作为参数输入的任何内容都不能作为SQL执行。

当然,当数据库将忠实地存储并可能在其他人的浏览器上执行时,有人仍然可以向您传递一些JavaScript!

因此,您仍然需要删除输入(或至少转义)任何({[]})\type字符;

不是作为一个参数。SQL注入依赖于将恶意代码连接到SQL字符串中,然后从该字符串执行SQL语句。准备好的语句接受参数,而不考虑内容。对于准备好的语句,SQL语句本身的实际文本永远不会更改。

唯一的风险是,如果您执行 exec 在参数化字符串上。