On: Everything you wanted to know about SQL injection ...

[jeltz]

You should whenever you can always parametrized queries over sanitizing the input. Manually escaping or sanitizing should be the last resort.

[twistedpair → jeltz]

You've got to do both chief. Sure, you won't get SQL Injected with your parameterized queries, but you'll persist content that is damaging to your users. XSS is the example case where malicious content is persisted to the database and returned to the UI as trusted content.

That being said, this is not necessarily an issue with the DB tier as it is with the data input tier.

[jroseattle → twistedpair]

Bingo. A quick summary of the article would be "if you allow external input to pass through as executable values, this can happen". Really, the article is exploring different manners of executing SQL statements against a database, and really just looking at many possible SQL scenarios. The primary culprit in every scenario is the input tier.

[andyroid → twistedpair]

That's what output sanitizing is for. What's filtered for output may easily be changed over time whereas data that's been filtered when input could be enormously difficult to change once the application requirements changes.

[PavlovsCat → jeltz]

Manually escaping or sanitizing should be the last resort.

Why, other than "because one might forget it"?

That is, what if bits of the query depend on various conditions and need to be constructed part by part? Keeping the placeholders and the actual values synced seems like a nightmare in those cases.. unless I am missing something.

[ygra → PavlovsCat]

One could imagine something like

    public static void AddParameterValue(this SqlCommand cmd, string paramName, object value)
    {
        if (cmd.CommandText.Contains("@" + paramName))
            cmd.Parameters.AddWithValue(paramName, value);
    }

to help set parameters only if they are referenced in the SQL statement.