How do I prevent my SQL statements from SQL injection when using CLR/C++ with multiple variables?

a 夏天 提交于 2020-02-02 13:09:30


I am having a major problem where I do not know how to prevent SQL injection when writing SQL statements in CLR/C++ Below is the code

String^ sqlstr = "SELECT * FROM ";
sqlstr += tableName + " WHERE " + field + " = " + fieldEntity;

I need to be able to input correct SQL Injection preventions to this statement.

Background code

class database
    string fieldEntity;
    string tableName;
    string field;
OleDbDataReader^ openData(String^ fieldEntity, String^ field, String^ tableName)

        String^ sqlstr = "SELECT * FROM ";
        sqlstr += tableName + " WHERE " + field + " = " + fieldEntity;
OleDbDataReader^ reader2 = testData.openData(effectID, "effectID", "effectOnUser");
    while (reader2->Read())
        Object^ dHealthptr = reader2["effectOnHealth"];
        Object^ dTirednessptr = reader2["effectOnTiredness"];
        Object^ dHappinessptr = reader2["effectOnHappiness"];


There are two ways to prevent SQL Injection and the environment of SQLCLR does not change this:

  1. The preferred mechanism is by using parameterized queries. Different languages and libraries go about this in different ways, but at the very least you should be able to use prepared statements. Please note that this does not apply to scenarios that could not accept a variable, such as with tableName and field in your code.
    Please see:
    1. Issuing a Parameterized Query
    2. Using Stored Procedures
  2. Sanitize the inputs:

    1. Bare minimum, and by far the most common, requirement is to escape single quotes by doubling them (i.e. ' becomes '')
    2. Additionally (below is a quote from a related answer of mine on DBA.StackExchange):

      There is a lesser known type of attack in which the attacker tries to fill up the input field with apostrophes such that a string inside of the Stored Procedure that would be used to construct the Dynamic SQL but which is declared too small can't fit everything and pushes out the ending apostrophe and somehow ends up with the correct number of apostrophes so as to no longer be "escaped" within the string. This is called SQL Truncation and was talked about in an MSDN magazine article titled "New SQL Truncation Attacks And How To Avoid Them", by Bala Neerumalla, but the article is no longer online. The issue containing this article — the November, 2006 edition of MSDN Magazine — is only available as a Windows Help file (in .chm format). If you download it, it might not open due to default security settings. If this happens, then right-click on the MSDNMagazineNovember2006en-us.chm file and select "Properties". In one of those tabs there will be an option for "Trust this type of file" (or something like that) which needs to be checked / enabled. Click the "OK" button and then try opening the .chm file again.

      So, be sure to properly size the string input parameters. You don't need VARCHAR(500) for a column that is declared as VARCHAR(25). Please see my answer on DBA.StackExchange for more details and examples: Why does SQL Injection not happen on this query inside a stored procedure?


For tableName and field variables, those are being used as SQL identifiers in your query. You can't use either common method of query parameters or escaping. You just have to make sure to whitelist the values for those variables. In other words, check them against known identifiers of tables and columns in your database.

For the other variable fieldEntity, I suppose this should be used like a constant value in your SQL query. You can protect this from SQL injection by using a query parameter.

I don't know CLR, but there are lots of examples of using SQL query parameters in C++ or C#.