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.
Related
is it necessary to use LINQ for sql purposes in MVC ? can't we use traditional queries like:
Select name from tbl where id = 2;
instead of LINQ ? and why linq in any case ?
ASP.NET MVC in no way restricts your choice of data access technology. In fact, model binding works with objects, and MVC has no idea whether your objects represent some database or not.
Besides, if you were to use LINQ at all, you would do best to use Entity Framework (a.k.a. LINQ to Entities) and not LINQ to SQL, which is much more limited.
Linq to SQL, EntityFramework, nHibernate - are ORM (Object-relational mapping) tools. ORM represent database objects as standard .NET classes.
Raw SQL can be used, when you are inserting a lot of data, and you need a good performance. In all other cases you should to use ORM.
And if you decide to use ORM, I advise you to use EntityFramework; it's more powerful than LINQ to SQL.
You don't need to use linq at all. I usually use dapper.net for my data layer, mapping SQL queries to objects. It's personal preference.
You are not obliged to use Entities Framework, as you are not obliged to use anything in particular.
Microsoft strongly suggests using the Entities Framework because it is an ORM integrating very easily with the whole Microsoft ecosystem, using the LINQ query language which is integrated in the .NET languages specification. This integration happens through the Linq to Entities query language and the respective tools provided in Visual Studio.
As you will see, Entities Framework (as every other ORM) has the overhead of the learning but in my opinion, it totally pays you back as using an ORM leads to faster development and more maintainable source code. I would strongly suggest using an ORM (it has many advantages) and I suppose since you are already familiar with Microsoft ecosystem, Entities Framework would be the best choice.
Hope I helped!
Well, if you want to use this style of queries you can use stored procedures this is to close to the normal query, just and a Linq-to-SQL file into your project and drag and drop you stored procedures then you can use them like methods and this is a link http://msdn.microsoft.com/en-us/library/bb386946.aspx
Note that Linq-to-SQL is integrated only with SQL Server
No, you do not have to use LINQ at all, or any other ORM frameworks, you an work directly against a database.
In .Net this is typically done using ADO.Net, for example using the System.Data.SQL namespace.
See code examples and official documentation here
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.
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.
I have been a long time user of Subsonic due to its ease of use and LINQ integration.
I now have to use something else because I need to be able to use Oracle.
I have 2 databases with the same schema therefore I want to have 1 set of POCO's and then change a connection string to switch between SQL & Oracle depending on the requirements.
Is this possible firstly, is LINQ fully functioning and stable in NHibernate and do Castle ActiveRecord and Fluent Hibernate allow the LINQ querying?
It is stable.
It is not fully functioning, and it is not planned to be fully functioning. I don't think there exists linq providers supporting 100% everything. The question should be: "Is it fully function for the queries you need to execute?" (The answer to that question would be yes in 99% of the cases)
You can find reported bugs/missing features in Jira
Fluent NHhibernate doesn't do any querying, just mapping. Castle active record doesn't query either. The linq namespace does not have a reference to active record or fluent and vise versa.
I wouldn't classify the NHibernate LINQ implementation as stable yet. The LINQ provider is still fairly young, so chance of hitting an unsupported query scneario still may be considerable in my opinion. However, other NHibernate query options are plentiful to workaround any issues the LINQ provider might throw up.
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.