We have been using nhibernate for almost a year now.
I wuld like to know that are there any vulnerabilities that could be injected(like SQL injection etc.) using web application.
I just want to secure any nhibernate injection through web application if there are.
I think that one of the requirements of a proper OR/M manager, is to make sure that all queries that can be executed using the OR/M manager, are properly secured against SQL injection.
NHibernate generates parametrized queries for SQL Server, so that is secure.
Offcourse, I don't know how other providers (for other DBMS'es) generate ...
As Frederik said, the queries are parametrized so you have roughly the same risk of a sql injection attack as you do with a stored procedure in SQL Server. This means you are safe from direct SQL injection, but neither protect you from latent sql injection. For more info on latent SQL injection, check out the comments of Jeff Atwood's blog post here: Give me parameterized SQL, or give me death
The biggest security concern with NHibernate is that you have to expose a SQL account to your application that can select/insert/update/and delete (if not doing soft deletes) on your database tables. With stored procedures you can expose an account that only has rights to execute stored procedures. This is not a problem for many places, but some places may have strict policies against direct table access.
Related
I'm using Sequelize with PostgreSQL for the first time. It's also my first time using an SQL database in a long time.
I have been researching how to improve the performance and security of some SQL Queries. I came across the sequelize.query() method and started using it for this purpose.
Is this way of making raw queries in Sequelize vulnerable to SQL Injection?
Although you can avoid them, you can also issue queries vulnerable to SQL Injection.
If you use exclusively queries that use Replacements or Bind Parameters for all the user entered values, you should be safe.
Is this vulnerable to SQL injection: The simple answer is "yes".
You are using a raw query. If that raw query ever gets input from user input, however indirectly, you open up the possibility of SQL injection. Whether the risk is real or not depends on the rest of your code.
Performance is different. A raw query may be slightly more performant than using the sequalize methods but is MUCH more dependent on database structure and the nature of the query itself. This is a broad topic that can't be answered from the information given.
I am working on a project where we are using DbContext but not EF for CRUD functionalities. We are using service layer for our business logic where stored procedures are written to fetch/send data to the database. I got to know about Dapper ORM which allows you to ease the interactions with the database. I was wondering if someone could give a brief up on the pros of using Dapper with MVC5 application instead of traditional Stored Procedures?
Are you comparing Stored Procedures with Dapper? If so, I do not see this as valid comparison. Both have their own benefits and drawbacks. Both are helpful in their own field of implementation.
Instead, if you are looking for calling Stored Procedure through Dapper, I suggest refer following posts; you can search for even more.
Link 1
Link 2
My personal opinion:
I avoid to use Stored Procedures. I prefer to implement my Database code using ADO.NET or ORM depending on needs. This helps me centralize all my Database logic at one place. This also improves debugging and logging capabilities.
Note: That does not mean, I never use Stored Procedures or those should never be used. Those may be useful based on needs.
For implementing Data Access Layer using Dapper, please refer my answer.
We have Oracle 11 as database for our third party server application. The interactions for db is only allowed through the interops DLLs provided by vendor. No direct access to database is allowed. We need to connect to the database using those DLLs for creating or deleting objects inside the database. I am wondering if I can use Nhibernate by writing some wrappers about those DLLs. No SQL queries are also allowed. Can this be done?
Who is vendor? Not Oracle I guess, but your "third party" providing the "application server" software.
In such case this looks like they want to forbid direct SQL access to their application DB. So there is no point trying to use an ORM such as NHibernate, it would be from their point of view almost like directly querying the DB.
Your "best" option is to ask them if they can provide their own NHibernate database driver, but their answer will very probably be "No".
At the company that I work with, we often have to integrate with client’s infrastructure.
Recently, after hearing that we use Hibernate, one client manifested following concern: Since user under which Hibernate connects to database has a direct access to tables and Hibernate generates SQL dynamically, then such user can do pretty mach anything in the database.
Had the user only permission to execute stored procedures, then SPs can limit the data but more importantly type of queries he can issue to database: basically no dynamic and injected SQL. So, if there is a stored procedure that eliminates a row, malicious person who got hold of user credentials will be able to eliminate single row in one go, but will not be able to issue the DELETE *. I know Hibernate can also map views, but again this limits the data and not the operations user can perform. Hibernate can also execute SPs, but that in a great extent beats the purpose of using Hibernate and would imply a complete rewrite of application.
While I don’t see this as a major concern, since application servers also provide security, I had a problem of convincing the client. What’s your take on this? Is Hibernate really less secure than application using stored procedures? What are additional security measures that can be put in place when working with Hibernate?
NHibernate can map to sprocs instead of tables
You can map read operations onto tables / views and insert / update / delete operations onto sprocs if you like
NHibernate does generates parameterised SQL, i.e. there is no chance of SQL injection
User permissions can always be restricted to certain operations on certain tables, if you decide to map onto tables and / or views
Most projects using sprocs start off by generating CRUD procedures for every table and assigning execute permissions on them all - this is not really much more secure than allowing table access
I would assume Hibernate uses paramaterized queries. That should alleviate much of the concern for SQL Injection. You can also prevent the user account from being able to do everything in the database. It doesn't need to be the SA account after all.
If I am not mistaken NHibernate use parametrized sql queries. This will stop injection.
Hibernate of course is just a ORM layer over sql.
Add the show_sql=true property on, show them what sql is being generated, and they'll see exactly what it does (parametrized queries as was mentioned).
Hibernate can be less secure than using stored procedures, since in theory, DBAs can limit user access to only calling stored procedures, rather than direct access to the underlying data structures.
In practice and in my experience, it's extremely rare for this style of security to be implemented in a meaningful way. If a stored procedure is written for each CRUD operation, and a user is granted access to all of the stored procedures, there is no real difference between that and just granting rights to the underlying structures themselves.
If the company is audited for SOX or security compliance, they might get dinged for not using stored procedures.
It is possible to use Hibernate over stored procedures, but it seems like a pain in the ass.
Traditionalist argue that stored procedures provide better security than if you use a Object Relational Mapping (ORM) framework such as NHibernate.
To counter that argument what are some approaches that can be used with NHibernate to ensure that proper security is in place (for example, preventing sql injection, etc.)?
(Please provide only one approach per answer)
Protect your connection strings.
As of .NET 2.0 and NHibernate 1.2, it is easy to use encrypted connection strings (and other application settings) in your config files. Store your connection string in the <connectionStrings> block, then use the NHibernate connection.connection_string_name property instead of connection.connection_string. If you're running a web site and not a Windows app, you can use the aspnet_regiis command line tool to encrypt the <connectionStrings> block, while leaving the rest of your NHibernate settings in plaintext for easy editing.
Another strategy is to use Integrated Authentication for your database connection, if your database platform supports it. That way, you're (hopefully) not storing credentials in plaintext in your config file.
Actually, NHibernate can be vulnerable to SQL injection if you use SQL or HQL to construct your queries. Make sure that you use parameterized queries if you need to do this, otherwise you're setting yourself up for a world of pain.
Use a dedicated, locked-down SQL account
One of the arguments I've heard in favor of sprocs over ORM is that they don't want people to do whatever they want in the database. They disallow select/insert/update/delete on the tables themselves. Every action is controlled through a procedure which is reviewed by a DBA. I can understand where this thinking comes from... especially when you have a bunch of amateurs all with their hands in your database.
But times have changed and NHibernate is different. It's incredibly mature. In most cases it will write better SQL than your DBA :).
You still have to protect yourself from doing something stupid. As spiderman says "with great power comes great responsibility"
I think it's much more appropriate to give NHibernate the proper access to the database and control actions through other means, such as audit logging and regular backups. If someone were to do something stupid, you can always recover.
http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx
Most ORM's handle SQL injection by creating parameterized queries. In NHibernate, if you are using LINQ to NHibernate or the Criteria/Query over methods of writing queries, the queries are automatically parameterized, if you are dynamically creating HQL/SQL queries yourself you are more vunerable and would have to keep in mind that your queries would have to be parameterized.
OWASP mentions one form of SQL injection vulnerability in the context of ORM tools (and gives HQL injection as an example): http://www.owasp.org/index.php/Interpreter_Injection#ORM_Injection