April 17, 2015 at 10:06 am
Forgive if this is a foolish question, I've seen the various articles that suggest using stored procedures, parms, etc, but then they will sometimes list the further need to scan the parameter values for escape characters, etc...
However, in the example below it SEEMS like it is "safe" provided the stored procedure is called and this parameter used.
Is this code below ALSO vulnerable to SQL Injection?
procedure:
CREATE PROCEDURE [dbo].[SQLInjecTest]
@MyParm AS CHAR(50)
AS
SELECT *
FROM ( VALUES(1, 'Row1'),
(2, 'Row2')
) AS tvc (PKID, Name)
WHERE tvc.Name = @MyParm
So note it is just doing where column = @MyParm
then calling the procedure:
EXEC[dbo].[SQLInjecTest]@MyParm = 'Row1'
I've tried various common injection scenarios with the above call, I can't seem to trigger anything, have I missed something obvious, is that code "safe"?
My understanding is that because it is a parameter the WHERE statement treats it all like text and looks for a row where it matches that exact text. So even if I load it up with ; -- and ' it won't make a difference and still treats it like an exact match in that where statement?
April 17, 2015 at 10:08 am
You're ok, no sql injection possible here.
-- Gianluca Sartori
April 17, 2015 at 10:23 am
spaghettidba (4/17/2015)
You're ok, no sql injection possible here.
Does that still hold true, even without the stored procedure?
The part "protecting it" is due to the parameterization?
DECLARE @MyParm AS CHAR(50)
SET @MyParm = 'Row1'
SELECT *
FROM ( VALUES(1, 'Row1'),
(2, 'Row2')
) AS tvc (PKID, Name)
WHERE tvc.Name = @MyParm
As above, also safe?
(Seemed to be in my testing, but again wanted to make sure I wasn't missing something obvious)
April 17, 2015 at 10:26 am
Confirmed. It's the parameterization that protects you. You run into issues with improper dynamic sql.
-- Gianluca Sartori
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply