November 5, 2009 at 3:46 am
Hi,
how to prevent injection with trigger ? it's possible ?
many thanks,
November 5, 2009 at 5:02 am
Not quite sure what you're asking. Do you mean you want to create a trigger that looks at the input before anything happens so you can verify there's no SQL in it? Or do you mean something else?
SQL 2005 has some built in "injection prevention" already and there are ways to validate input on the front end before the input gets to the server. Is there a reason why you can't use input validation?
EDIT: Before I get jumped on by others, I should clarify the above statement. SQL 2005 does *not prevent* SQL Injection attacks if you leave room for them. However, there are tools in 2k5 that assist in preventing them if you use the tools correctly. Look up "SQL Injection" in BOL for more details. And if I can find the specific reference from my training book on 2k5 (the "Updating your DB skills" course offered by New Horizons), I'll post it.
November 5, 2009 at 5:16 am
I already have a script anti injection in ASP, ASPX I would like to trigger an anti Injection
November 5, 2009 at 5:22 am
I'm sorry, but I'm still not clear on what you want to accomplish. Could you be more detailed?
November 6, 2009 at 10:43 am
Triggers react to DML and DDL events. If some code is suceptible to SQL injection attacks, you would have to predict the form of every possible attact to write triggers for them.
You prevent SQL injection by using methods that don't permit user-entered text to be executed as commands. Triggers are reactive, they won't run until the attack has already succeeded.
November 6, 2009 at 11:06 am
Very generic question...
First and best way to prevent any SQL injection:
* Don't allow clients to create dynamic SQL. Secure the complete database with a stored procedures interface
* Do not use any dynamic SQL within those procedures.
For new-school client technologies:
Today O/R-Mapper frameworks become more and more common. Use well known frameworks like (N)Hibernate or Entity Framework. The large frameworks always ensure a correct and not injectable SQL. Don't use rebel frameworks. Don't use the custom SQL features (if any) of these frameworks.
More optimistic prevention (which still can work):
If you don't use a O/R-Mapper and your client apps generate dynamic SQL statements. Tell the developers never to add values as strings. Always use the data provider interfaces like SqlCommand objects in .NET
Greets
Flo
November 6, 2009 at 11:12 am
Triggers are not the right tool to use to prevent SQL injection. By the time the code has fired off a trigger, it's WAY too late to be preventing injection.
Injection attacks are more likely to be about selecting data (to steal it) than to be about updating data. Triggers can't fire on selects.
- Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
Property of The Thread
"Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon
November 7, 2009 at 4:48 am
Many thanks...:-)
Viewing 8 posts - 1 through 7 (of 7 total)
You must be logged in to reply to this topic. Login to reply