Where are ORM's vulnerable for SQL injection?

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/scr开发者_StackOverflowubbing 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.