C# 来自WCF服务的SQL查询避免了查询视图时的SQL注入

我有来自其他项目的类，这些项目有用于SQL查询的字符串

看我的例子

public class OtherClass
{
    myQuery = "SELECT * FROM v_My_View WHERE code = '@code'";
    // I am targeting a view, not a stored procedure
}

我的问题是，如果我在我的

commandText

中使用这个参数，并用一个值替换

@code

，那么这个参数是否对SQL注入有效

如果SQL注入易受攻击，那么还有哪些其他选项

我试着使用

CMD.Parameters.AddWithValue("@code", _obj.code) 

但它毁了我的查询

我在访问存储过程时使用参数，但在访问视图时不使用参数

这是我的主要观点：

public class Main
{
    public DataTable myMethod()
    {
        try
        {
            DataTable myTable = new DataTable("MyDataTable");

            using (SqlCommand CMD = new SqlCommand())
            {
                CMD.Connection = RBOSUtil.DBConnection();
                CMD.CommandType = CommandType.Text;

                // this is the part I used the string from other class
                CMD.CommandText = OtherClas.myQuery.Replace("@code", _obj.code);

                using (SqlDataAdapter DA = new SqlDataAdapter(CMD))
                {
                    DA.Fill(myTable);
                }
            }
        }
        catch
        {
            throw;
        }
        finally
        {
            //close connection
        }

        return myTable;
    }
}

用这个

 public class Main
    {
        public DataTable myMethod()
        {
            DataTable myTable = new DataTable("MyDataTable");

            try
            {
                using (SqlCommand CMD = new SqlCommand())
                {
                    CMD.Connection = RBOSUtil.DBConnection();
                    CMD.CommandType = CommandType.Text;
                    //this is the part I used the string from other class
                    CMD.CommandText = OtherClas.myQuery;
                    CMD.Parameters.Add("@code", SqlDbType.NVarChar).value = _obj.code;
                    using (SqlDataAdapter DA = new SqlDataAdapter(CMD))
                    {
                        DA.Fill(myTable);
                    }
                }
            }
            catch
            {
                throw;
            }
            finally
            {
                //close connection
            }
            return myTable;
        }
    }

在尝试之前声明datatable使用此

 public class Main
    {
        public DataTable myMethod()
        {
            DataTable myTable = new DataTable("MyDataTable");

            try
            {
                using (SqlCommand CMD = new SqlCommand())
                {
                    CMD.Connection = RBOSUtil.DBConnection();
                    CMD.CommandType = CommandType.Text;
                    //this is the part I used the string from other class
                    CMD.CommandText = OtherClas.myQuery;
                    CMD.Parameters.Add("@code", SqlDbType.NVarChar).value = _obj.code;
                    using (SqlDataAdapter DA = new SqlDataAdapter(CMD))
                    {
                        DA.Fill(myTable);
                    }
                }
            }
            catch
            {
                throw;
            }
            finally
            {
                //close connection
            }
            return myTable;
        }
    }

---

在重试之前声明datatable

SQL语句中的参数名称周围不需要引号：

myQuery=“从v_My_视图中选择*，其中code=@code”。否则我觉得你做的很好。它应该会起作用

编辑：我把原来的问题和拉维的答案搞混了。不知怎的，我错过了问题和第一个答案之间的分界。无论如何，要回答最初的问题，是的，使用String.Replace将@code替换为值会受到SQL注入漏洞的影响

您应该使用SQL参数，就像Ravi答案中的代码一样，但是您还需要修改查询以删除参数名称周围的引号。
在SQL语句中，您不需要在参数名称周围加引号：
myQuery=“从v_My_视图中选择*，其中code=@code”。否则我觉得你做的很好。它应该会起作用

编辑：我把原来的问题和拉维的答案搞混了。不知怎的，我错过了问题和第一个答案之间的分界。无论如何，要回答最初的问题，是的，使用String.Replace将@code替换为值会受到SQL注入漏洞的影响

您应该使用SQL参数，如Ravi答案中的代码，但您还需要修改查询以删除参数名称周围的引号。
如果您不知道
code
是字符串还是数字，您怎么能说呢？即使code是字符串，也不会在参数名称周围加引号。原始查询所做的是将名为code的列与静态字符串
@code
进行比较，而不是使用名为
@code
的参数，因此如果我的变量是字符串，它将不带引号地工作：）好的，谢谢你的信息，这不是一个参数。它是一个字符串占位符，可以使用
.Replace
替换。您也可以将其称为
myparameter
@Nick.McDermaid。OP不应该使用
。替换
，如果不这样做，这个答案就可以了。OP已尝试使用参数。我同意一些更详细的说明会有所帮助。如果你不知道
code
是字符串还是数字，你怎么能说呢？即使code是字符串，你也不会在参数名周围加引号。原始查询所做的是将名为code的列与静态字符串
@code
进行比较，而不是使用名为
@code
的参数，因此如果我的变量是字符串，它将不带引号地工作：）好的，谢谢你的信息，这不是一个参数。它是一个字符串占位符，可以使用
.Replace
替换。您也可以将其称为
myparameter
@Nick.McDermaid。OP不应该使用
。替换
，如果不这样做，这个答案就可以了。OP已尝试使用参数。我同意更多的精化会有所帮助。一般来说，任何使用字符串替换而不是参数的代码都容易受到SQL注入的攻击。使用参数而不是字符串替换。我不知道
uOBJ.code
来自何处，但如果未进行消毒，则完全开放给SQL注入。您使用的是
CMD.Parameters.AddWithValue（@code“，\u obj.code）
”，还是使用
CMD.CommandText=OtherClas.myQuery.Replace（“@code”，\u obj.code）还是两者都使用？不清楚。如果您使用的是
myQuery.Replace
，那么这只是字符串替换。在allOnce中，您没有使用参数，您只使用参数，可以安全地免受任何Sql注入攻击，只有一个例外：当这些参数用于创建动态Sql时。这里不是这样，所以你应该没事。但是，不要使用
AddWithValue
，也不要用撇号包装参数。不清楚他们是使用
AddWithValue
还是
Replace
来指定值。在看到
AddWithValue
之前，我看到了
Replace
，所以我假设OP只是使用字符串替换。正如我在上面所说的。我尝试使用CMD.CommandText=OtherClas.myQuery.Replace（“@code”，_obj.code”）使用参数化值；在访问我的视图时，但它给了我一个错误输出。我不知道为什么，但我仍然需要一段时间来研究它。一般来说，任何使用字符串替换而不是参数的代码都容易受到SQL注入的攻击。使用参数而不是字符串替换。我不知道
\u obj.code
是从哪里来的，但是如果它没有经过消毒，那么它就完全可以接受SQL注入。您是使用
CMD.Parameters.AddWithValue（“@code”，\u obj.code）
还是使用
CMD.CommandText=OtherClas.myQuery.Replace（“@code”，\u obj.code”）还是两者都使用？不清楚。如果您使用的是
myQuery.Replace
，那么这只是字符串替换。在allOnce中，您没有使用参数，您只使用参数，可以安全地免受任何Sql注入攻击，只有一个例外：当这些参数用于创建动态Sql时。这里不是这样，所以你应该没事。但是，不要使用
AddWithValue
，也不要用撇号包装参数。不清楚他们是使用
AddWithValue
还是
Replace
来指定值。我看见了那条鳕鱼