views:

85

answers:

4

Does passing SQL Parameters to a stored procedure alone ensure that SQL injection won't happen or the type checks also need to be performed?

As an example -
ADO.NET Code:

    Database DBObject = DataAccess.DAL.GetDataBase();
    DbCommand command = DBObject.GetStoredProcCommand("usp_UpdateDatabase");
    List<DbParameter> parameters = new List<DbParameter>();
    parameters.Add(new SqlParameter("@DbName", txtName.Text));
    parameters.Add(new SqlParameter("@DbDesc", txtDesc.Text));
    command.Parameters.AddRange(parameters.ToArray());
    rowsAffected = DBObject.ExecuteNonQuery(command);

SP:

ALTER PROCEDURE [dbo].[usp_GetSearchResults] 
 -- Add the parameters for the stored procedure here
  @DbName NVARCHAR(50)  = ''
 ,@DbDesc NVARCHAR(50)  = ''

AS
BEGIN
  SET NOCOUNT ON; 
  SELECT     [RegionName]
            ,[AppName]
  FROM  [ApplicationComponent]
  WHERE [DBName]  LIKE ('%' + @DbName+ '%')
  OR    [DBDesc]  LIKE ('%' + @DbDesc+ '%')
END

In the above code, I havent mentioned any parameter types or validation logic. Would it still preevnt SQL injection?

Thanks for the guidance!

+2  A: 

Yes, that should still protect you from SQL Injection.

You're not dynamically building the SQL String in your .NET code and you're not using sp_execute to dynamically build and execute a SQL statement in your stored procedure.

Justin Niessner
+1 for making the distinction that you can still do dynamic SQL within SPs, and thus they are not implicitly safe from SQL injection.
RedFilter
+7  A: 

No, that should be fine. The value in the LIKE clause is still built up as a string value, rather than being interpreted as part of the SQL statement. It's still being treated as data rather than code, and that's the crucial part of avoiding SQL injection attacks.

Jon Skeet
@Jon => I know I cannot question with you but isn't a case like the following (mentioned at -http://msdn.microsoft.com/en-us/library/ff648339.aspx ) vulnerable to attacks - Consider what happens when a user types the following string in the SSN text box, which is expecting a Social Security number of the form nnn-nn-nnnn.' ; DROP DATABASE pubs --So in the like clause give ' Drop Datatabase ' ?
Prashant
@Jon.. so does that mean, upon using SQL parameters, double quotes get around the entered value thus making it a string literal, and otherwise in a dynamic sql it would be treated with quotes and as part of the SQL statement?
Dienekes
@Dienekes: No, it means that the SQL engine receives the data entirely separately from the SQL, and *keeps* it separate.
Jon Skeet
@Prashant: I wouldn't expect that to be a problem, because the DROP DATABASE text isn't part of the SQL, and wouldn't be treated as part of the SQL - the engine would never consider executing it. It's not like it's doing a find and replace on the SQL, then executing the result.
Jon Skeet
@Jon.. Thanks a lot for explaining that.. :)
Dienekes
A: 

Default DbType for an SQLParameter is NVarChar (as per the docs), so this is the type your parameters will have.

Anyway, even if the parameters were of the wrong type, the worst thing you would have would be the type cast exception, not SQL injection.

Quassnoi
A: 

I would still suggest using typed parameters. While the implementation catches any injection attempts AS FOR NOW, there is no real guarantee that this will be the case down the line - and hopefully your application will lead a long and prosperous lifetime... =)

With regard to SQL Server, the MSDN article on the subject can be found here: http://msdn.microsoft.com/en-us/library/ff648339.aspx

Streamcap