I have become a big fan of the datasets in Visual Studio 2005. I usually create the SQL for each method in the table adapter; however, I am wondering if there is any 'built-in' functions in the C files for sql injection prevention? I have read that using stored procedures is a good method for prevention. Should I be using SP rather than SQL within my methods in the data table?
Hey,
Welcome to the forum. The key is, do you have any dataset queries that take user input and passes it to a SQL query directly? Then you may want to beware if that is true. I like the use of SPs because SQL Server will cache them for increased performance.
In addition, you should be able to use @.Parameters within a SQL query, and pass in the values as parameters, which is safer than embedding the response directly into the SQL query.
|||
wendycarpenter@.polk-county.net:
I am wondering if there is any 'built-in' functions in the C files for sql injection prevention?
Use parameterized queries!
http://aspnet.4guysfromrolla.com/articles/030106-1.aspx
|||I am using parameterized queries - I've included a sample below. SQL Injection prevention has been "in the air" a lot lately and I guess I want to make sure that I am doing what I need to do to keep my customers' data safe.
INSERT INTO [Case] ([cseYear], [cseNumber], [cseStatus], [csePartI], [csePartII], [cseDestruction])
VALUES (@.cseYear, @.cseNumber, @.cseStatus, @.csePartI, @.csePartII, @.cseDestruction);
select SCOPE_IDENTITY()
|||
I appreciate the link. Maybe I wasn't specific enough. I am using the built in dataset (.xsd), so I am not creating any sql statement within my code - I strictly call the method within the datatable of the table adapter within the dataset. Most of the work is done within the auto generated code within Visual Studio 2005.
|||Hey,
OK, which used the parameter approach I believe. That should be OK; I've seen several projects where Adapters were used even with secure info. Note that table adapters can also use stored procedures in case you want to be sure.
sql