Jump to content

Is this query safe against SQL injection?


sql-lover

Recommended Posts

Hi,

 

I am using parameterized queries on my code, here's the relevant part

 

$params=$_POST['ITGtable'];

$tsql2 = "SELECT COLUMN_NAME, DATA_TYPE, ORDINAL_POSITION, 
  COLUMN_DEFAULT, CHARACTER_MAXIMUM_LENGTH, IS_NULLABLE
  FROM INFORMATION_SCHEMA.COLUMNS
  WHERE TABLE_NAME=?";

/* Execute the statement with the specified parameter value.
Display the returned data if no errors occur. */
$stmt2 = sqlsrv_query( $conn, $tsql2, $params);
if( $stmt2 === false )
{
     echo "Statement 2 could not be executed.\n";
     die( print_r(sqlsrv_errors(), true));
}
else
{
     $qty = sqlsrv_fetch_array( $stmt2);
}

 

Do I really have to sanitize $_POST['ITGtable'] for apostrophe, semicolon, etc, to avoid SQL injection problems? Or just with above code I should be safer (I did not say safe) against SQL injection? And if the answer is "No", what could be the sanitize code of function? I am using sqlsrv and MS-SQL database engine; most of the functions we have for sanitize inputs on MySQL are not available for MS-SQL.

 

Thanks in advance,

Link to comment
Share on other sites

Prepared isn't the same as parameterized.

 

They are essentially the same.  Your just passing the parameters and sql together in a call vs doing it separately by preparing the query first then binding parameters later.

 

I guess that my question is still there :-)

 

Do I have to sanitize the input? And if answer is Yes, which function or function will help me now than I'm using the Microsoft connector or driver.

Link to comment
Share on other sites

The use of a prepared statement or parameterized query will protect you from SQL injection*. Of course, that doesn't mean that you definitely don't require any other form of input validation. You should still check that the query being executed contains expected values. For example, you would still need to check a value is positive, within some range etc, etc.

 

In other words, the use of parameters or prepared statements avoids the need for separate sanitation (e.g. with mysql_real_escape_string() ), but you shouldn't just forget about validation entirely.

 

*Assuming it has been implemented properly :)

Link to comment
Share on other sites

Prepared isn't the same as parameterized.

 

They are essentially the same.  Your just passing the parameters and sql together in a call vs doing it separately by preparing the query first then binding parameters later.

 

I guess that my question is still there :-)

 

Do I have to sanitize the input? And if answer is Yes, which function or function will help me now than I'm using the Microsoft connector or driver.

 

Not for SQL injection.

Link to comment
Share on other sites

The use of a prepared statement or parameterized query will protect you from SQL injection*. Of course, that doesn't mean that you definitely don't require any other form of input validation. You should still check that the query being executed contains expected values. For example, you would still need to check a value is positive, within some range etc, etc.

 

In other words, the use of parameters or prepared statements avoids the need for separate sanitation (e.g. with mysql_real_escape_string() ), but you shouldn't just forget about validation entirely.

 

*Assuming it has been implemented properly :)

 

Thanks.

 

Since I posted this question I read additional material. Your comment makes sense.

Link to comment
Share on other sites

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.