SQL Injection attack with stored procedures [duplicate] - sql

Question

This question already has answers here:
How to cleanse (prevent SQL injection) dynamic SQL in SQL Server?
(8 answers)
Closed 3 years ago.
I have a stored procedure as below:
CREATE PROCEDURE sp_GetName(#Name NVARCHAR(50))
AS
BEGIN
DECLARE #sqlcmd NVARCHAR(MAX);
DECLARE #params NVARCHAR(MAX);
SET #sqlcmd = N'SELECT * FROM [dbo].[Employee] WHERE Name like ''%' + #Name + '%''';
PRINT #sqlcmd;
SET #params = N'#Name NVARCHAR(50)';
EXECUTE sp_executesql #sqlcmd, #params, #Name;
END
EXEC sp_GetName '';WAITFOR DELAY '00:00:10'
Whenever I execute above statement, it always delays the response.
How can I write my procedure so that it will handle this SQL Injection attack.

Answer 1

Don't use dynamic SQL if you want to avoid SQL injection attacks. It doesn't matter whether you wrap the string concatenation code in a stored procedure or not.
In this case there's no reason to use dynamic SQL. You can simply write :
SELECT * FROM [dbo].[Employee] WHERE Name like '%' + #Name + '%'
to search for employees with a specific string in their name.
This query is immune to SQL injection whether you execute it as a parameterized query from a client or as a stored procedure. Clients would call both of them the same way.
The stored procedure should be just :
CREATE PROCEDURE getName(#Name nvarchar(50)
AS
SELECT * FROM [dbo].[Employee] WHERE Name like '%' + #Name + '%'
I removed the sp_ prefix because it's used for system stored procedures.
The problem with this code is that %something% will have to search the entire table. It can't use any index on Name. Only prefix searches can use indexes, ie #Name + '%' :
SELECT * FROM [dbo].[Employee] WHERE Name like #Name + '%'

Answer 2

You just need to parametrize the dynamic code.
CREATE PROCEDURE sp_GetName(#Name NVARCHAR(50))
AS
BEGIN
DECLARE #sqlcmd NVARCHAR(MAX);
DECLARE #params NVARCHAR(MAX);
SET #sqlcmd = N'SELECT * FROM [dbo].[Employee] WHERE Name like ''%'' + #Name + ''%''';
print #sqlcmd;
SET #params = N'#Name NVARCHAR(50)';
EXECUTE sp_executesql #sqlcmd, #params, #Name;
End
exec sp_GetName '';
However, the code has nothing that would justify the need of making it dynamic. It could be simply rewritten as this.
CREATE PROCEDURE sp_GetName(#Name NVARCHAR(50))
AS
SELECT * FROM [dbo].[Employee] WHERE Name like '%' + #Name + '%';
Why are you making your application slow by design?

Answer 3

You can just embed the SQL in you're stored procedure without using sp_executesql
CREATE PROCEDURE sp_GetName(#Name NVARCHAR(50))
AS
BEGIN
SELECT * FROM [dbo].[Employee] WHERE Name like '%' + #Name + '%'
End
Your example doesn't actually demonstrate a SQL injection attack; you've just got 2 sql statements seperated by a semi-colon, the second of which is a "wait"
-- Also demonstrates wait behaviour
exec sp_who;WAITFOR DELAY '00:00:10'