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.
Related
I am looking for a safe solution to inject SQL queries generated by knex package into the existing SQL code. I was considering using a knex.queryBuilder.toQuery() method as it prints out a string but I'm not sure how reliable this is in terms of SQL injection.
Maybe someone else has a better idea on how to approach this subject? Rewriting existing SQL is not an option.
Thanks.
I'm considering using a toQuery method.
Is there any disadvantage to execute native SQL query using either {dataSource.connector.execute(sql, params, cb) or dataSource.connector.query(sql, params, cb)} than using connected models?
I have recently tested the same scenario with sample data with both Native SQL and connected models. When I used Native SQL I noticed that MYSQL connection get lost when I increase the load. But The same operations performance with Loopback's connected models and filters, It can sustain almost 4 times the load compared to Native SQL Connector.
Loopback also don't recommend using Native SQL Connector:
This feature has not been fully tested and is not officially
supported: the API may change in future releases. In general, it is
always better to perform database actions through connected models.
Directly executing SQL may lead to unexpected results, corrupted data,
and other issues. - Loopback
So My exact question is Has anybody noticed any Disadvantage or performance panalty Using of Using Native SQL instead of Loopback's connected models?
Simply put running raw queries(Native sql) may be faster than having using ORMs(models) as they perform validations , build queries from parameters and filters you provide etc. where as running raw queries simply issue the query to the connected sql server over network without going through all those extra layers , but those difference maybe barely noticeable. Now industry standard is that you should use ORMs(models) to access you data as they protect you from a lot of threats like sql injection and simple human errors as it performs comprehensive validations based on the schema. So simply put ORMs are safer than Raw queries. But its a matter of choice what you want to do. I honestly fall somewhere in the middle where i use ORM provided models whenever possible but i have found some instances where running Raw queries brings far more simplicity like when you have to perform joins on more than 2 tables as well as manipulate the data using queries than use ORM. This last bit is just my way of doing things which in many peoples opinion may be wrong. I suggest use ORMs ie. in your case Strong Loop connectors as much as possible.
I'm currently involved in a app project, and I'm incharge of setting up the backend.
What i'm use to using is a MYSQL database + php for cleaning and managing the data sent to and fro the front end, which I have much more experience in. However, because of certain preferences of my bosses, on this project I've found myself looking at IBMs Bluemix and Cloudant software. Cloudant is a NoSQL database(like CouchDB) and my experience regarding noSQL is severely lacking. All I've mananged to do so far is to create a few JSON documents, and some basic views
What I need to figure out is how to perform the CRUD(create,read,update,delete) actions on a NoSQL database, or at least what it would look like.
In addition to this, I need to know if there are ways to implement security measures(implement security and anti-hacking functions) on a NoSQL database without an external source, or will I need to learn how to reroute the data through some sort of php function first, if i want it cleaned, before sending it to the Cloudant server where my database sits.
Let me know if my attempt to explain my problem is lacking in clarity. I'll try my best to state a different way, if need be.
Generally speaking, there is nothing equivalent to an ANSI to NoSQL databases. In other words, NoSQL databases are not as standardized as SQL databases. All standards are starting to appear. You can think of it as a technology still in the making.
What you have in general is an API with methods such as put_record or delete_record, or a REST interface that is logically equivalent. Also, in general you CRUD the whole record, not parts of the record.
Take a look at the reference: Cloudant - Reading and Writing
Having that said, in your case I would recommend abstracting away from the specific implementation of the NoSQL you want to use if you care about avoiding vendor lock-in. So I would suggest you to wrap CRUD functions using PHP functions that later can be replaced if you want to change the NoSQL database flavor.
This approach has the additional advantage to provide an abstraction for you to implement your own security. Some important NoSQL databases have no concept of multi-tenancy or just implemented that. Again, it is a technology in the making.
When your mindset is the relational one, you tend to think of the database as something that will help you guarantee data consistency as much as possible. But NoSQL databases are not like that. Think of them as a simple repository of documents (in a JSON or XML structure, for instance), without cross references.
Then the obvious question is perhaps: why would anyone want such a thing? One of the possible answers is because NoSQL databases may hold an aggregate of consolidated data. You can then retrieve aggregates to save time reprocessing or re-retrieving data unnecessarily.
As for security, most (if no all) NoSQL databases have some pretty good authentication mechanisms.
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.
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