-
Posted to
Security
by
DavidReabow
on
05-18-2008, 6:38 PM
Hi Lilly,
I would still suggest using parameter objects. There are two main reasons for this;
1. You can set the data type of the parameter object and achieve the same "error checking" as you would with CInt.
2. SQL Server treats parameters slightly different to executing a single "string" statement. When a string is ...
-
Posted to
Security
by
DavidReabow
on
05-16-2008, 1:08 PM
Hi all,
Here are some "DENY" permission scripts I have used. I'd advice you to check that they don't break your applications/websites before using them.
-------------------------------------------------------------------------------------- Master ...
-
Posted to
Security
by
DavidReabow
on
05-15-2008, 7:28 AM
Hi everyone,
I'm going to suggest an alternative to the "find bad words and redirect" solution. This may not work for everyone but will hopefully break any attempts to inject SQL.
You should still search for the "bad" words but when you find them, instead of redirecting to another page, you should replace ...
-
Posted to
Security
by
DavidReabow
on
05-13-2008, 11:50 AM
I've been looking for a good tutorial on using parameters to pass on to some developers and found this:
http://weblogs.sqlteam.com/jeffs/archive/2006/07/21/10728.aspx
Everyone should use parameter objects whether you use stored procedures or not. It is probably one of the most important things to do when protecting yourself from SQL ...
-
Posted to
Security
by
DavidReabow
on
05-13-2008, 9:53 AM
The person(s) behind this appears to realise that he/she/they need to adapt as measures are taken to prevent these attacks. I wouldn't rely on any one single method to stop this and I wouldn't be surprised if it's back again soon in a different guise.
Check all input from your websites (URL parameters, Form data, cookie data ...
-
Posted to
Security
by
DavidReabow
on
05-13-2008, 9:20 AM
Yes, thats an error [my_admin_sql_login] should actually be the name of the database.
-
Posted to
Security
by
DavidReabow
on
05-13-2008, 9:13 AM
Replace [my_asp_sql_login] with the login that your website uses to connect to the database (not the admin account you are using)
-
Posted to
Security
by
DavidReabow
on
05-13-2008, 8:27 AM
Hi Flackie,
Use an account with sysadmin or DBO access rights to change them, it should work.
The following should do the job:use [YourDBName]
GO
DENY SELECT ON [sys].[tables] TO [YourUserName]
GO
DENY SELECT ON [sys].[columns] TO [YourUserName]
GO
A further note to those using this method to stop this particular attack, I have had a SQL ...
-
Posted to
Security
by
DavidReabow
on
05-12-2008, 12:32 PM
Hi Neil,
I'm not sure if I am reading your last post correctly. Are you saying that you are using Parameter Objects and it is still getting through?
If you are just appending your parameters to the string as in my example it doesn't matter what the SP parameter is declared as.
In my example: 'EXEC usp_GetProductDetail 1 ...
-
Posted to
Security
by
DavidReabow
on
05-12-2008, 9:15 AM
Hi Neil
Stored procedures can help but in this case you have to worry about how the stored procedure and parameters are "passed" to SQL server.
Lets say you had the following URL on your site:
HTTP://www.yoursite.com/ShowProduct.ASP?ProductID=1
You may not check the ProductID for "corrupt" data ...