参数用于保护您免受恶意用户输入。
但是如果参数需要一个字符串,是否可以编写将被解释为sql的输入,因此恶意用户可以使用“DROP”,“TRUNCATE”等内容......?
asp,asp.net,java和其他参数之间的保护是否存在差异?
另请参阅:Are parameters really enough to prevent SQL injections?
答案 0 :(得分:12)
参数化查询通常引用参数,如果它是场景后面的字符串,那么普通的SQL运算符不会被解释为这样。这意味着即使用户输入潜在的恶意数据,也只会将其视为字符串输入,而不是解释为SQL运算符/命令。
在各种框架中如何实现它可能存在技术差异,但基本思想(和结果)是相同的。
答案 1 :(得分:9)
您需要小心定义。 '参数'可能意味着许多事情;例如,存储过程的参数根本不会保护您自己。以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用户; - ” - 将被数据库引擎正确转义并呈现无害。
仍然可以搞砸它 - 例如,如果你的存储过程只是在内部构建一个SQL字符串并执行它,信任输入 - 但是带参数的预处理语句意味着没有未转义的数据永远不会到达数据库服务器,完全切断了攻击媒介。
答案 2 :(得分:3)
没有。 SQL注入攻击可以在任何SQL DB中的任何语言中发生。您所指的攻击类型是程序员在其源代码中使用动态SQL,如“USER_NAME = sName”,用户可以为用户名输入无限制文本,以便他们可以附加注释然后键入任何新的SQL语句,例如' DROP','TRUNCATE'等。
答案 3 :(得分:3)
通过BindWhatever()调用作为参数输入的任何内容都不能作为SQL执行。
在绑定ht evariable数据之前,SQL已经被解析和评估,因此它几乎无法将这些数据误认为是SQL。
当数据库忠实存储并且可能在某些浏览器上执行时,有人仍然可以通过一些JavaScript!
所以你仍然需要摆脱任何({[]})\ type字符的输入(或至少转义);
答案 4 :(得分:1)
不作为参数。 SQL注入依赖于将恶意代码连接成SQL字符串,然后从该字符串执行SQL语句。无论内容如何,预准备语句都会获取参数。使用预准备语句,SQL语句本身的实际文本永远不会更改。
答案 5 :(得分:1)
唯一的风险是如果对参数化字符串执行exec
。
在所有其他情况下,参数化查询是安全的。