My idea is to create some generic classes for Insert/Update/Select via a C# (3.5) Winforms app talking with a MySQL database via MySQL .NET Connector 6.2.2.
For exam
YES you need to create parameterized queries, anything else is going to introduce a risk of SQL injection
It's impossible to detect SQL injection after the fact (in other words, once you've constructed a dynamic query string, it's impossible to differentiate what the "real" SQL is versus any injected SQL).
If your intent is to allow users to execute arbitrary SQL, then it would seem like you wouldn't be too worried about SQL injection (since that is the aim of SQL injection).
You should definitely be using parameterized queries to keep yourself safe.
You don't have to hand create parameterized queries each time though. You could modify the generic method you provided to accept a collection of MySqlParameters
:
public void Insert(string strSQL, List<MySqlParameter> params)
{
if(this.OpenConnection() == true)
{
MySqlCommand cmd = new MySqlCommand(strSQL, connection)
foreach(MySqlParameter param in params)
cmd.Parameters.Add(param);
cmd.ExecuteNonQuery();
this.CloseConnection();
}
}
I should also mention that you should be VERY careful about cleaning up your connections after you're finished using them (typically handled in a using
block, but I don't see that level of detail in your code example).
Parametrization is very easy to do. Much easier than scrubbing SQL queries, and less messy or error prone than manual escaping.
Slightly edited copy/paste from this tutorial page because I'm feeling lazy:
// User input here
Console.WriteLine("Enter a continent e.g. 'North America', 'Europe': ");
string userInput = Console.ReadLine();
string sql = "SELECT Name, HeadOfState FROM Country WHERE Continent=@Continent";
MySqlCommand cmd = new MySqlCommand(sql, conn);
cmd.Parameters.AddWithValue("@Continent", userInput);
using (MySqlDataReader dr = cmd.ExecuteReader())
{
// etc.
}
That wasn't so hard, was it? :)
You can't really do this - you'd need to write a SQL parser which to say the least is non-trivial and error prone.
Bite the bullet and parametrize your queries.
I would expect that it would be pretty hard to scrub raw text that will be used for SQL. If at all possible I would try to use parameterized operations.
One exception would be if you didn't expose the function publicly, and you never passed in a string that was constructed from raw user input.