0

I have a tool which points out all the sql injection issues and I found one as follows :

"SELECT GB.BTN,GUP.CUST_USERNAME,GUP.EMAIL from GBS_BTN GB,GBS_USER_BTN GUB,GBS_USER_PROFILE GUP WHERE GB.BTN=GUB.BTN AND GUB.CUST_UID=GUP.CUST_UID AND GB.ET_ID='" + strAccountID + "' ORDER BY CREATE_DATE DESC",oCin"

can some please tell me how to construct the above query to avoid sql injection?

4

3 回答 3

9

Option 1: Use parameterized queries instead of contencating strings.

More info can be found here: http://msdn.microsoft.com/en-us/library/ff648339.aspx

Option 2: Use parameterized Stored Procedures

Option 3 would be to escape the strings by using Replace() but this should be a last resort. It's weak, and there are ways around it.

string sql = "Select * From someTable where SomeStringField = '" + myVariable.REplace("'", "''") + "'";
于 2013-05-08T17:30:15.690 回答
2 
SELECT foo, bar, etc FROM Bobby WHERE this = that
AND GB.ET_ID = @accountID ORDER BY mySort

然后，在命令变量中，添加参数。像这样：

myCommand.Parameters.AddWithValue("@accountID", strAccountID);

您必须了解漏洞在于如果 strAccountID 来自用户可编辑的控件，它可能包含以下内容：

' drop table GBS_BTN --

这将导致您的程序运行部分查询，然后删除表。

编辑：并使用示例中的参数会导致用户键入的任何内容都被转义，因此您可以避免这种利用。正如其他人所建议的，您也可以使用存储过程。然后，您将被迫使用示例中的参数。存储过程具有其他可能对您有帮助的特性，但这是另一个讨论。

于 2013-05-08T17:33:03.723 回答
0

如果用户设法使用特制内容填充strAccountID ，强制忽略语句然后运行任意代码，则可能发生 SQL 注入。

这篇文章可能会为您提供一些相关信息。AviD 的回答非常准确，所以让我引用重要的部分：

  • 白名单验证：类型、长度、格式或接受的值
  • 如果您想加入黑名单，请继续。引用转义很好，但在其他缓解措施的范围内。
  • 使用命令和参数对象，预解析和验证
  • 仅调用参数化查询。
  • 更好的是，只使用存储过程。
  • 避免使用动态 SQL，并且不要使用字符串连接来构建查询。
  • 如果使用 SP，您还可以将数据库中的权限限制为仅执行所需的 SP，而不是直接访问表。
  • 您还可以轻松验证整个代码库仅通过 SP 访问数据库

虽然我没有他对存储过程的喜爱（它不能防止错误/错误的代码，并且 SP 中错误处理单引号的 EXEC 语句将无法防止 SQL 注入），但读起来很有趣.

于 2013-05-08T17:47:54.043 回答