Stored Procedures - Postet den (8751 Views)
Starting Member
afifm
Innlegg: 1
1
My web site was attacked with a nasty SQL injection. I took the site off-line for sanitizing in the mean time my research points toward using SQL stored procedures and Paramatization as best practice.
I wrote the following SP:



set ANSI_NULLS ON
set QUOTED_IDENTIFIER ON
go

ALTER PROCEDURE [dbo].[sp_add_user] @Param1 int, @Param2 varchar(25), @Param3 varchar(100), @Param4 ntext

AS

Begin

INSERT INTO MyTable (column1, column2, column3, column4)

VALUES (@param1, @param2, @param3, @param4)

End


And my ASP looks like the following:


Dim objConn
Set objConn = Server.CreateObject("ADODB.Connection")
objConn.Open strPegaDBConnString
Set objCmd = Server.CreateObject("ADODB.Command")

'Set the database connection to use
Set objCmd.ActiveConnection = objConn

'Set the name of the procedure and that it is a store procedure
objCmd.CommandText = usp_add_applicant 'strProcedureName
objCmd.CommandType = adCmdStoredProc

parm1 = (Request.Form.Item("Field1"))
parm2 = (Request.Form.Item("Field2"))
parm3 = (Request.Form.Item("Field3"))
parm4 = (Request.Form.Item("Field4"))

Execute usp_add_user (parm1, parm2, parm3, parm4)


When I submit the form, I get the following error:



Microsoft VBScript runtime error '800a000d'

Type mismatch: 'usp_add_user'

ThankYou.asp, line 59



Here is line 59:



Execute usp_add_user (parm1, parm2, parm3, parm4)


Where did I go wrong? Any help is appreciated. <
   
 Sidestørrelse 
Postet den
Forum Moderator
AnonJr
Innlegg: 5768
5768
Not sure, but Stored Procedures are no more or less inherently safe than anything else if you don't keep up to date and properly sanitize your inputs. Feed a malformed variable to a SP and it will still result in something like what happened.

I know that Snitz doesn't use them to allow for more DB options (i.e. you can use Oracle or something else with a small number of changes). Personally I've found them harder to troubleshoot.
If you're still determined to use sprocs, I would write out the parameters and make sure that they are what they are supposed to be. A type mismatch error usually results from trying to insert a string in a numeric field or something along those lines. I would highly advise writing some sort of validation routine as it will help in the troubleshooting and it will help prevent future attacks.<
Postet den
Support Moderator
Podge
Innlegg: 3776
3776
That reminds me of this story - http://thedailywtf.com/Articles/SQL_Injection_Prevention_101.aspx

As AnonJr has stated, you would be a lot better off sanitizing the user input. Just because you use a sproc doesn't mean sql cannot be injected.<
Postet den
Average Member
SiSL
Innlegg: 671
671
Postet den
Support Moderator
Podge
Innlegg: 3776
3776
I tested that theory in the past and came to the conclusion that sproc's don't offer any increase in speed over dynamic sql.<
Postet den
Average Member
SiSL
Innlegg: 671
671
Originally posted by Podge
I tested that theory in the past and came to the conclusion that sproc's don't offer any increase in speed over dynamic sql.

Opposite observations here. I felt quite dramatic increase on my all-time used procs cache response was faster than normal. On the other hand Dynamic SQL that is specifically written for certain database such as SQL Server, would improve speed rather than something that has to sacrifice speed over compability for multi-databases...<
Postet den
Forum Moderator
AnonJr
Innlegg: 5768
5768
Outside of anecdotal evidence, which I am not necessarily dismissing, I've not seen a good enough speed boost in most cases for a blanket "use sprocs, they're faster" recommendation. I guess its another one of those situational things. smile
All things being equal I've found it to be more of a PITA than a benefit... But that's just me. wink<
Postet den
Snitz Forums Admin
ruirib
Innlegg: 26364
26364
In theory, caching of the execution plan could bring an advantage to stored procs over dynamic code. Not sure about the actual practical impact in a real situation, though it may vary noticeably.<
Postet den
Support Moderator
Doug G
Innlegg: 6493
6493
Using stored procedures is dbms-specific. Stored procedures for ms sql server don't run well on mysql or access :)
<
======
Doug G
======
Computer history and help at www.dougscode.com
Postet den
Support Moderator
Podge
Innlegg: 3776
3776
I don't think the difference will be all the great unless the is a HUGE amount of data involved. It certainly wouldn't be worth the time and effort to change a Snitz forums to use sprocs in order to gain a very small speed advantage. IMHO anyway (and I love speed). In this day and age is easier to buy (or rent) a more powerful server.<
Postet den
Starting Member
NicoMS
Innlegg: 1
1
I hear making sure your stored procedures don't include concatenating string while making an SQL statement helps but I'm sure this is on a case by case basis. Have you tried taking a gander at the www.microsoft.com/hellosecureworld7 website?<
Du må legge inn en melding