|
Comments
|
|
Say if one of my product name Dropper, then that product will not be processed as it will raise error... so how do u think we can handle such situations?
|
|
|
I guess it's a very rare situation, altough we could serach for '%DROP %' instead of '%DROP%' that would reduce the odds. Right?
|
|
|
Extremely poor implementation of dynamic filtering. This exposes SQL syntax in the filters, as opposed to just the data/columns to be filtered on.
|
|
|
This is really not a good idea.
There are almost infinite syntaxes that cause
an SQL injection. The use of parameters should be used.
|
|
|
Is there a more generic approach that does not require a detail filtering against all possible dangerous T-sql commands?
|
|
|
Satish, as noted by Chapas you can add an extra space after DROP and make the filtering more precise: '%DROP %'. Note the space between DROP and %. A more advanced approach would be to query the system catalog views/tables and get the names of your objects/tables, then exclude those from the filter.
|
|
|
Claudio, if you allow end users to freely type text that you concatenate to a dynamic query and execute, then you are left with little options but to filter the user input. It can be done on the client side or server side, but it drills down to a form of filtering for keywords that they should not be using.
|
|
|
Rob, this is correct. However, the point here is not to illustrate best practices on how to handle dynamic queries, but to show how to protect the code when no parameterization is used.
|
|
|
Harvey, the best way is to avoid dynamic SQL! But it cannot always be the case as dynamic SQL has good uses for implementing dynamic search, some admin functions, dynamic pivoting, etc. The best approach is: use parameters instead of freely concatenating user entered text; use the system stored procedure sp_executesql instead of EXEC; add additional protection like the QUOTENAME function to concatenate identifiers, etc. If you parameterize your queries then there is no need for detail filtering at all.
|
|
|
This was a very useful recommendation...I intend to implement this recommendation asap.
|
|
|
Need more complete list of key words to prohibit.
|
|
|
Satyabodhi, the list can vary based on your requirements. Here is just an example of what it may be: "DROP, ALTER, CREATE, TRUNCATE, DELETE, UPDATE, INSERT, SELECT, EXEC".
|
|
|
Hi There I still believe that the best way is to alway parameterize the commands send to the sql server.
|
|
|
82796FB536, parameterization is the best way to solve SQL injection. This is just an additional method. What if your client API does not support parameterization?
|
|
|
Very nice. Will use this example in productin.
|
|
|
Very good exmaple. Liked it. Thanks
|
|
|
Excellent!!!
|
|
|
Very useful training tip.
|
|
|
I really like this Video, act I was searching this kind of Anti SQL injection materials.
Thnaks Good Job.... Al the best.
|
|
Cosmin Tornea on
6/27/2011
cool
|
|
Scott Taylor on
6/27/2011
This is a half-baked solution for a non-problem, especially if best practices are being used. Direct SQL should never be allowed from the presentation layer, particularly not in production. Parameterized SQL or the equivalent (created using your favorite technology) is the only way to avoid the chances for SQL injection attacks (and is also a lot more efficient).
|
|
|
I've seen this technique before,but it's hard to assure that all possible conditions for an SQL injection attack can be covered unless the if statement gets pretty complicated, and maybe not then.
|
|
|
Very good!
|
|
|
extremely simplistic
|
|
Faisal Lodhi on
6/27/2011
Thanks, Great topic!
|
|
|
was hoping that the intructor would cover parameterizing in sp_executesql
|
|
|
There are probably better ways of doing this, but I guess this would work.
|
|
|
Would have been better to show normal execution of procedure with valid parameter, then injection attempt, then demoing the prevention piece of the script.
|
|
|
It might be good to have these scripts written before and then just talk through the code that you have in place. It would probably save some time in the presentation.
Good job.
|
|
|
Poor programmings skills with dynamic queries, poor technics like 'concatanatings strings"....
|
|
|
not a great mechanism to detect SQL injection as very often some of your search criteria may contain SQL keywords.
|
|
|
I agree that this is not a good method of preventing SQL injection. The key is to escape any single quotes from the string, For example if you have a paramter where sku='@param' and your @param = xxx';Drop table products, you should escape the quote as xxx'';Drop table products so the final query looks like where sku='xxx'';Drop table products' This will prevent SQL Injection
|
|
|
Excellent video, but too short...
|
|
|
Excellent video.Thank you for sharing and keep the great work.
|
|
|
What if "drop" or "update" are legitimate words to have as part of the search criteria? It seems like there must be a better way to prevent sql injection than this.
|
|
|
Aaron, yes there is a better method. That is to use correct parameter queries. See more details here: http://pratchev.blogspot.com/2009/03/sql-injection.html. The method in this video is only supplemental in case parameterization cannot be used. There are some APIs that do not allow parameter queries.
|
|
|
goog one
|
|
|
Good topic
|
|
lojze kavsek on
10/4/2011
Very simple and clear sample!
|
|
Maurice Ivory on
11/16/2011
I liked this, I learned a few things
|
|
|
Good
|