The Forum has been Updated
The code has been upgraded to the latest .NET core version. Please check instructions in the Community Announcements about migrating your account.
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. <
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. <
Postet den
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.<
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
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.<
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.<
Podge.
The Hunger Site - Click to donate free food | My Blog | Snitz 3.4.05 AutoInstall (Beta!)
My Mods: CAPTCHA Mod | GateKeeper Mod Tutorial: Enable subscriptions on your board
Warning: The post above or below may contain nuts.
My Mods: CAPTCHA Mod | GateKeeper Mod Tutorial: Enable subscriptions on your board
Warning: The post above or below may contain nuts.
Postet den
Actually would love extra stored procs for Snitz to improve speed at least...<
Postet den
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.<
Podge.
The Hunger Site - Click to donate free food | My Blog | Snitz 3.4.05 AutoInstall (Beta!)
My Mods: CAPTCHA Mod | GateKeeper Mod Tutorial: Enable subscriptions on your board
Warning: The post above or below may contain nuts.
My Mods: CAPTCHA Mod | GateKeeper Mod Tutorial: Enable subscriptions on your board
Warning: The post above or below may contain nuts.
Postet den
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...<
Sist redigert av
Postet den
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.
All things being equal I've found it to be more of a PITA than a benefit... But that's just me.
<
All things being equal I've found it to be more of a PITA than a benefit... But that's just me.
Postet den
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
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
Doug G
======
Computer history and help at www.dougscode.com
Postet den
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.<
Podge.
The Hunger Site - Click to donate free food | My Blog | Snitz 3.4.05 AutoInstall (Beta!)
My Mods: CAPTCHA Mod | GateKeeper Mod Tutorial: Enable subscriptions on your board
Warning: The post above or below may contain nuts.
My Mods: CAPTCHA Mod | GateKeeper Mod Tutorial: Enable subscriptions on your board
Warning: The post above or below may contain nuts.
Postet den
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?<
Email Member
Message Member
Post Moderation
Filopplasting
If you're having problems uploading, try choosing a smaller image.
Forhåndsvis post
Send Topic
Loading...