Security of printing SqlException.Message to console

Question

While i've been debugging my code, I've been writing the output to the console so that I can monitor the errors and sql output. Naturally to protect against sql injection I have parameterised the queries where needed. After reading some articles online regarding the methods by which some injection attacking programs work, I now question whether the below practice is a good idea anymore.

Consider the following method.

public void MyQuery(int item_id)
{

        string sql = "SELECT * FROM table WHERE item_id = @id";


        SqlCommand sqlQuery = new SqlCommand(sql,conn);

        sqlQuery.Parameters.Add("@id", SqlDbType.Int).Value = item_id;

        try
        {
            conn.Open();
            sqlQuery.ExecuteNonQuery();
            conn.Close();
        }
        catch (SqlException ex)
        {
            Console.WriteLine(sql);
            Console.WriteLine(ex.Message);
        }
}

on my dev machine the console output is fine - no risk here. But if i were to leave the code as it is now when the application was live, would that potentially open up other avenues to exploit?

Im aware that if i were to have done MessageBox.Show(ex.Message); that would certainly be bad due to it being in your face.

Answer 1

You're deploying a WinForms application that connects to a SQL Server with credentials that apparently allow the application to write to that SQL Server.

Leaking SQL errors to the console is the least of your worries.

A malicious user can simply use the credentials used by your application to execute arbitrary SQL on that server.

Anything you deploy on a client machine must be considered insecure. Leaking queries is not the problem (the user could decompile your application or check its resources and inspect the SQL strings), the problem is that the client has a direct database connection.

If you want to prevent the client to know where the database is, what its credentials are and what queries your application executes, you must remove all this code from your application, and let the database stuff happen on a different machine altogether. You can then talk to this machine through a web service, for example.

Then the web service handles authentication, and refuses to execute any action for a user that isn't authenticated.