参数真的足以阻止Sql注入吗？
我一直在向同事和SO讲这两种方法，以讲究在SQL查询（尤其是.NET应用程序）中使用参数的好处。我什至甚至承诺它们可以抵抗SQL注入攻击。
但是我开始怀疑这是否真的是真的。是否存在可以对参数化查询成功进行的已知SQL注入攻击？例如，您是否可以发送导致服务器上的缓冲区溢出的字符串？
当然，要确保Web应用程序是安全的，还需要考虑其他因素（例如清理用户输入和所有其他内容），但是现在我正在考虑SQL注入。我对MsSQL
2005和2008的攻击特别感兴趣，因为它们是我的主要数据库，但是所有数据库都很有趣。
编辑：澄清我的意思是参数和参数化的查询。通过使用参数，我的意思是使用“变量”而不是在字符串中构建sql查询。
因此，不要这样做：
SELECT * FROM Table WHERE Name = 'a name'
我们这样做：
SELECT * FROM Table WHERE Name = @Name
然后在查询/命令对象上设置@Name参数的值。
问题答案：
占位符
足以防止注入。您可能仍然对缓冲区溢出持开放态度，但这是与SQL注入完全不同的攻击方式（攻击向量不是SQL语法，而是二进制）。由于传递的所有参数都将被正确地转义，因此攻击者无法以任何方式传递将被视为“实时”
SQL的数据。
您不能在占位符内使用函数，也不能将占位符用作列名或表名，因为它们被转义并用字符串文字形式引用。
但是，如果您在动态查询中将 参数 用作 字符串连接的
一部分，则您仍然容易受到注入的影响，因为您的字符串不会被转义，而是文字形式的。使用其他类型的参数（例如整数）是安全的。
就是说，如果您使用use输入来设置诸如的值security_level，那么某人可以使自己成为系统中的管理员，并拥有免费的服务。但这只是基本的输入验证，与SQL注入无关。
-
问题内容： 可能重复： 绕过mysql_real_escape_string（）的SQL注入 我还没有看到任何评价或没有过时的信息。因此，存在一个问题：mysql_real_escape_string（）是否完全可以防止SQL注入？但是它已经非常过时了（它从‘09开始），所以从‘12的php 5.3和mysql 5.5开始，它是否可以完全保护？ 问题答案： mysql_real_escape_st
-
问题内容： 假设我有这样的代码： PDO文档说： 准备好的语句的参数不需要用引号引起来。司机为您处理。 那真的是我避免SQL注入所需要做的一切吗？ 真的那么容易吗？ 您可以假设MySQL会有所作为。另外，我真的只是对针对SQL注入使用准备好的语句感到好奇。在这种情况下，我不在乎XSS或其他可能的漏洞。 问题答案： 简短的回答是“ 否” ，PDO准备将不会为您防御所有可能的SQL注入攻击。对于某些晦
-
问题内容： 我目前正在使用Access女士构建一个系统。由于避免sql注入很重要，因此我也想将参数程序用作VB.NET，但我想知道是否可以。如果是这样，那么如果您至少向我展示了使用参数从控件向数据库中插入数据的sql语句，我将不胜感激；如果不能，那么有人会以其他方式向我展示吗？ 任何建议，我将不胜感激，谢谢.. 问题答案： 该INSERT语句在名为“ frmDatePicker”的打开表单上使用文
-
问题内容： 我知道PreparedStatements避免/防止SQL注入。它是如何做到的？使用PreparedStatements构造的最终表单查询是否为字符串？ 问题答案： SQL注入的问题在于，用户输入被用作SQL语句的一部分。通过使用准备好的语句，您可以强制将用户输入作为参数的内容（而不是SQL命令的一部分）进行处理。 但是，如果您不使用用户输入作为已准备好的语句的参数，而是通过将字符串连
-
问题内容： 我知道PreparedStatements可以避免/防止SQL注入。它是如何做到的？使用PreparedStatements构造的最终表单查询是否为字符串？ 问题答案： SQL注入的问题在于，用户输入被用作SQL语句的一部分。通过使用准备好的语句，您可以强制将用户输入作为参数的内容（而不是SQL命令的一部分）进行处理。 但是，如果您不使用用户输入作为已准备好的语句的参数，而是通过将字符
-
问题内容： 在PHP手册中，有一条注释： 注意：如果不使用此功能对数据进行转义，则该查询容易受到SQL注入攻击的攻击。 这足以进行反SQL注入吗？如果没有，您能举个例子和一个好的反SQL注入解决方案吗？ 问题答案： 通常足以避免SQL注入。不过，这确实取决于它是否没有错误，即它 存在 脆弱性的可能性很小（但是这还没有在现实世界中体现出来）。准备好的语句是在概念上完全排除SQL注入的更好的替代方法。