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.
Related
I tried to find a method for using sqlalchemy's engine.execute level solutions for sql injections, but I came across this is possible via ORM style.
How can we achieve it using engine-level api?
You can use bind parameters with sqlalchemy.sql.expression.text to avoid SQL injection. Also using the sql/core layer to build queries should also work of course, ie. session.execute(select(my_table).where(id=some_id)).
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 started working on a Java project where the chosen database was the Azure Cosmos DB SQL API, so reading the SQL API Cosmos DB introduction I understood that that SQL, in this case, is only for query and not for data manipulation(insert, delete).
The question is: Does it make sense to use a schema migration tool like Flyway/Liquibase for this kind of database?
CosmosDb does not have any support for schemas at the database level. It's schema free with an indexing mechanism that allows for efficient querying of arbitrary JSON data. As such, a SQL schema migration tool doesn't make sense in this context and wouldn't work anyways. It's up to your application code to ensure that data is normalized and migrated to new formats if necessary.
Little late to the party but I think this might help: https://github.com/liquibase/liquibase-cosmosdb. It's an extension for Liquibase for Cosmos DB. So, pretty much what you were looking for!
I'm developing an ASP.NET MVC 3 app and need a way around SQL injections, something simple would be useful. I have followed Microsoft's article on the matter but it doesn't seem to match up with my code and structure.
Any help is greatly appreciated
To prevent sql injection:
Do not form any dynamic sql.
Use stored procedures (and do not include any dynamic sql in a stored proc - if you do make sure you use sp_executesql and not exec, as sp_executesql can take a parameterized query
use parameterized queries
use an ORM (ex. entity framework) which uses parameterized queries behind the scenes anyways.
try not to use any dynamic sql - if you must for some reason then make sure you use parameterized queries.
Don't just simply use dynamic sql and remove quotes from them - its a bit dangerous to assume that would be the only attack vector as some do.
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