I am using asp.net mvc 3 with WCF with EF 4.1 With Sql Azure. I am building the search engine for my application. and using the dynamic Linq to build queries. I want to avoid the sql injetion in this scenario. what is the best practice for the same ? what are the precaoution i should take in this scenario ?
As long as your are building your queries through LINQ, then you are not vulnerable to SQL injection. While this doesn't mean that your code is invulnerable to ALL sorts of attacks (brute forcing passwords, etc.), you won't be vulnerable to SQL injection.
Dynamic LINQ automatically protects against a SQL injection attack, even if you build up your arguments using Request.QueryString etc.
You can add your own layer of very basic checking by making sure that no input strings contain the ";" character, which is typically used in SQL injection to allow entering custom SQL queries.
See also http://www.codeproject.com/KB/database/SqlInjectionAttacks.aspx.
Related
So I know that Rails helps protect against sql injections when used like this:
Object.find(:first, :conditions=>["name=?",name])
However, I can't seem to find if the autogenerated find_by and find_all_by methods protect agains sql injection.
i.e:
Object.find_by_name(name)
So these two calls have the exact same result. My question is even though the second one is more convenient, should I continue to use the first because it provides protection against sql injection, or does the second do that as well?
Yes, dynamic attribute-based finders (find_by_* family) do protect your app from sql injections.
I did web searches but I could not find solid answers. Is LINQ to NHibernate susceptible to SQL injection and other raw SQL attacks? If yes, what are same codes illustrating how to avoid such database attacks?
No.
SQL injection usually works by taking advantage of string formatting. The arguments used in LINQ expressions are safe. The provider will handle the generation of the SQL in such a way that nefarious SQL in the arguments will not be executed, and arguments will be constrained to existing as they are defined.
Furthermore under the hood it uses paramaterized SQL Queries which are immune to injection attacks.
When using ORM's (Entity Framework, LINQ to SQL, NHibernate ...), are SQL injection attacks mitigated by design?
If not, where should I be doing some extra validation/scrubbing to prevent a vulnerability?
Most, if not all, mainstream ORMs use parametrized SQL, which will protect you from a direct SQL injection attack. However parametrized SQL at the application layer will not protect you from latent SQL injection attacks. These occur when something down the line, other than the ORM, directly concatenates user input in a SQL statement (such as a batch run stored procedure that concatenates user input to create a non-parametrized dynamic query). Note that this isn't an ORM issue at all, but I thought I'd bring it up to point out that parametrized SQL only protects you from injections if it is used everywhere, not just in the ORM.
They are in NHibernate by using parameterized queries.
ORMs are designed to be secure, in the basic concepts. Most of the time you'll not have to worry about it, but if you think you might be exposed to real cracking you should do some custom tunning.
For simple apps, simple SQL injection you'll be cover. No body (seriously, no body ever) will give you a silver bullet in matters of security and SQL Injection. That's my advice.
ORMs typically use a lot of dynamic SQL, which is insecure because it gives users of the application and/or service accounts the ability to execute ad-hoc SQL queries. The correct solution is for only Programmers and DB Admins to have DataReader/DataWriter and all programs that touch the database to use nothing except parameterized Stored Procedures always with no DataReader/DataWriter access associated with the program. They can only access the SPs I say they can. Only the DB Admins and Programmers should be able execute ad-hoc SQL queries.
Plain-vanilla NHibernate setup, eg, no fluent NHibernate, no HQL, nothing except domain objects and NHibernate mapping files. I load objects via:
_lightSabers = session.CreateCriteria(typeof(LightSaber)).List<LightSaber>();
I apply raw user input directly to one property on the "LightSaber" class:
myLightSaber.NameTag = "Raw malicious text from user";
I then save the LightSaber:
session.SaveOrUpdate(myLightSaber);
Everything I've seen says that yes, under this situation you are immune to SQL injection, because of the way NHibernate parameterizes and escapes the queries under the hood. However, I'm also a relative NHibernate beginner so I wanted to double-check.
Thanks!
Yes, you're almost immune to SQL injection when using NHibernate. It uses parameterized queries for all generated SQL statements on all platforms that support these.
You can, however, circumvent this by using custom SQL for insertions/updates, or by executing SQL with a variation of execute_sql of some sort, or SQL Queries without parameters.
You're safe as long as you don't plug user input directly into HQL or SQL: nothing else (of the functionality hibernate provides) will allow users to inject malicious code.
Just to echo others, if you let NHibernate generate your SQL you're safe, at least in theory.
However, you still need to be careful with stored procedures, triggers, and functions in the database particularly with dynamic SQL. Even though the client uses parametrized queries everywhere, injection may still possible.
Just wanted to know if there is a big chance to inject SQL While using nhibernate?
If you're using the criteria generators then no. nHibernate is aware of the .Net types and is consequently able to handle all escaping for you when generating queries.
Unparameterized HQL is vulnerable however.