Leyendo Evitando ataques de inyección de SQL en procedimientos almacenados comencé este debate entre mi pareja y yo --- y buscar el enfoque correcto no es tan sencillo.
No soy un experto en seguridad, pero ¿qué hace una persona cuando observa las primeras líneas de este procedimiento almacenado ... y ve esto?
No hemos tenido ningún problema de seguridad importante, pero no asumo que este enfoque está funcionando ... Si es así, déjelo solo o hágalo mejor.
ASP:
Dim conStr = ConfigurationSettings.AppSettings("WebUser")
Dim command = ("Execute dbo.web_Insert_usr_Comments @Location," & _
"@userexp, @full_name, @emailAddr, @comments")
Using con As New SqlConnection(conStr)
Using cmd As New SqlCommand(command, con)
cmd.Parameters.AddWithValue("@Location", Request.QueryString("Location"))
cmd.Parameters.AddWithValue("@userexp", Request.QueryString("usrexp"))
cmd.Parameters.AddWithValue("@comments", Request.QueryString("comments"))
cmd.Parameters.AddWithValue("@full_name", Request.QueryString("full_name"))
cmd.Parameters.AddWithValue("@emailAddr", Request.QueryString("emailAddr"))
con.Open()
cmd.ExecuteNonQuery()
End Using
End Using
TSQL:
ALTER PROCEDURE [dbo].[web_Insert_usr_Comments]
@Location varchar(255),
@usrexp int = NULL,
@full_name varchar(255) = NULL,
@emailAddr varchar(320) = NULL,
@comments varchar(125) = NULL
AS
BEGIN
DECLARE @securityChk varchar(255), @haveContact INT
SET @securityChk = (SELECT @location + CAST(@usrexp AS VARCHAR(2)) + @full_name + @emailAddr + @usr_comments )
IF @securityChk LIKE '%SELECT%' RETURN;
IF @securityChk LIKE '%DROP%' RETURN;
IF @securityChk LIKE '%INSERT%' RETURN;
IF @securityChk LIKE '%DELETE%' RETURN;
IF @securityChk LIKE '%EXE%' RETURN;
SET @haveContact = ( SELECT (count(*))
FROM dbo.contacts
WHERE ( @emailAddr = E_mail_address AND @location = company))
--> Check and see if we have this person contact info
IF ( @haveContact = 0 )
BEGIN
INSERT INTO dbo.contacts(e_mail_address, company, nick_name)
VALUES (@emailAddr, @location, @full_name)
END
ELSE
BEGIN
INSERT INTO web_comments_dtl(timeGMT, form_id, contact_id, comment, user_exp_ranking, IP_Addr)
SELECT GETDATE()
, 1 --> TODO: Need better logic for form_id
, ( SELECT MAX(id)
FROM dbo.contacts
WHERE ( @emailAddr = E_mail_address AND @location = company)
OR ( @emailAddr = E_mail_address AND @full_name = nick_name )
OR ( @location = company))
, @RFXcomments
, @usrexp
, dbo.fnBinaryIPv4(@ip_Addr)
END
END
Lo que me gustaría hacer, pero no estoy seguro de qué opción es la más eficiente.
- Debería pasar una semana o dos e investigar los problemas de seguridad (si hay uno) y el formulario de entrada del usuario que llama a este SP
- Reescriba todo, incluido el SP, el código que está detrás, y reconfigure IIS
- Agregue más cláusulas a la declaración anterior.
No creo que haya un problema de seguridad ... pero si el tipo anterior decide poner esto en su código, ¿qué debe hacer un joven DBA?