在 C# 中转义内插字符串

Question

I find it unnecessarily cumbersome to create prepared statements in C# generally what you do is something like this:

    public T GetData<T>(string userInput)
    {
        string selectSomething = "SELECT * FROM someTable where someCol = @userInput";

        using (IDbCommand command = new SqlCommand(selectSomething))
        {
            IDbDataParameter parameter = new SqlParameter("@userInput", SqlDbType.NVarChar);
            parameter.Value = userInput;
            command.Parameters.Add(parameter);


            IDataReader reader = command.ExecuteReader();
            reader.Read();
        }

        ...
    }

But now as there are interpolated strings it could be as easy like this:

    public T GetData<T>(string userInput)
    {
        string selectSomething = $"SELECT * FROM someTable where someCol = {userInput}";
        
        using (IDbCommand command = new SqlCommand(selectSomething))
        {
            IDataReader reader = command.ExecuteReader();
            reader.Read();
        }
    }

There's still some other boilerplate code but still an improvement. Is there maybe a way to get the comfort of interpolated strings but still keep the safety of prepared statements with something like this:

string selectSomething = $"SELECT * FROM someTable where someCol = {userInput.PreventSQLInjections()}";

Answer 1

If you don't want to use EF which has FromSqlInterpolated method or any other ORM which will help you to handle your data access you can leverage fact that compiler uses FormattableString type to handle string interpolation to write helper method looking something like this (not fully working, but you should get the idea) to remove the boilerplate code:

public static class SqlCommandEx
{
    // maps CLR type to SqlDbType
    private static Dictionary<Type, SqlDbType> typeMap;

    static SqlCommandEx()
    {
        typeMap = new Dictionary<Type, SqlDbType>();

        typeMap[typeof(string)] = SqlDbType.NVarChar;
            //... all other type maps
    }
    public static SqlCommand FromInterpolatedString(FormattableString sql)
    {
        var cmdText = sql.Format;

        int count = 0;
        var @params = new IDbDataParameter[sql.ArgumentCount];
        foreach (var argument in sql.GetArguments())
        {
            var paramName = $"@param_{count}";
            cmdText = cmdText.Replace($"{{{count}}}", paramName);
            IDbDataParameter parameter = new SqlParameter(paramName, typeMap[argument.GetType()]);
            parameter.Value = argument;
            @params[count] = parameter;
            count++;
        }

        var sqlCommand = new SqlCommand(cmdText);
        sqlCommand.Parameters.AddRange(@params);
        return sqlCommand;
    }
}

And usage:

using (IDbCommand command = SqlCommandEx.FromInterpolatedString($"Select * from table where id = {val}"))
{
   ...
}

But this comes close to writing your own ORM which you usually should not do.

Answer 2

Prepared statements/parameterized queries go further than just sanitizing or escaping the inputs. When you use parameterized queries, the parameter data are sent as separate values from the SQL statement. The parameter data is never substituted directly into the SQL, and therefore injection is perfectly protected in a way that escaping/sanitizing the input never will.

In other words, DON'T COUNT ON STRING INTERPOLATION FOR "FIXING" SQL PARAMETERS!

Moreover, it's really not that much extra work. What the question shows is the hard way for adding parameters. You can simplify that code like this:

public T GetData<T>(string userInput)
{
    string selectSomething = "SELECT * FROM someTable where someCol = @userInput";

    using (IDbCommand command = new SqlCommand(selectSomething))
    {
        command.Parameters.Add("@userInput", SqlDbType.NVarChar).Value = userInput;

        IDataReader reader = command.ExecuteReader();
        reader.Read();
    }

    ...
}

This gets the extra work for parameters down to one line of code per parameter.

If you have high-confidence in the mapping between C# types and SQL types, you can simplify even further like this:

command.Parameters.AddWithValue("@userInput", userInput);

Just be careful with that shortcut: if ADO.Net guesses the SQL data type wrong, it can break indexing and force per-row type conversions, which can really kill performance.