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)).
Related
It seems the options to create a graph within Arangodb are:
The Web Interface
Arangosh using the general-graph module
The provided drivers using the object based API
The HTTP API
Is it possible to create the necessary components to build a graph using AQL???
For background, I am trying to assess options for bootstrapping graphs in different environments and potentially performing migrations in production environments.
No, at the moment AQL is only a DML (data manipulation language), but no DDL (data definition language).
To create a graph, please use one of the other methods you listed.
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.
Hey everyone I am working on nodeJS app. I searched some modules to manage my database (orientdb).
My question is: Why we use any ORM or ODM (or why is it recommenced), because there is a module which can provide many functions to manage DB.
I am still confused what should I use orientorm (https://github.com/mav-im/orientorm) or oriento (https://github.com/codemix/oriento)
Thank in advance..
Depending on the goal and depending on the ORM, ORMs have the advantage of adding support for:
schemas / models / collections: this makes it easier to create all classes/properties and, in some cases, migrations;
validations: make it easier to verify what gets saved in the DB.
All OrientDB ORM's I've seen for node.js expose Oriento, so that makes it easy to access the underlying oriento methods for doing more complex stuff.
Having said all this I recommend you try the waterline ORM with waterline-orientdb adapter. Waterline is an adapter based ORM with support for multiple databases (including support for associations between databases). Waterline-orientdb is the adapter for OrientDB which is based on Oriento. If at any point you need to use Oriento you can call .getDB() to access Oriento's instance.
Oriento is much more mature and supported. I suggest you to go with it.
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