For example if I had this predicate format string, would that have the same security benefits like prepared statements in SQL offer?
#"name == $LAST_NAME"
I am not sure if this is a plain stupid substitution which still allows bad "SQL" injection to core data, or if this is just as good as prepared statements known from modern db technologies?
You are not running on a server and any user is going to get complete access to the sqlite file anyway so there is no security there to subvert.
In addition, this is a predicate and it is not a stored sql statement. When your application runs the predicate, Core Data will do the translation to sql, it does not store that translation.
In short, nothing to fear here.
Related
I'm trying to prove something to a friend of mine re: escaping SQL strings. What are the recommendations for escaping user-input parts of a SQL Server query when parameterization cannot be used (like when someone saves a chunk of SQL text in the database and it will be used as part of a where clause later)? Basically, it's a way to save pre-canned queries in a single text column. And even if he parameterized the where clause, it could potentially have an arbitrary number of parameters (that would still have to be stored in the database as text). Is there a way to do this that doesn't open up a SQL injection risk?
In this case, you can't really parameterize up front because you don't have a clean way of making sure that parameter names don't clash and the like. Is there some library in System.Data.SqlClient that just escapes strings to make them SQL safe without requiring parameterization? My buddy seems to think this is a thing and I don't, and I'm trying to keep him from stepping on himself. Oh, and to make things more fun, the SQL gets jammed into the database by .NET, but is executed dynamically by SQL Server, so there's no good way to rig it with EF or something like that either. For his approach to work, he'll have to sanitize the SQL some way.
Could someone tell me if there are any times when it is more advantageous to use t-SQL over the Entity Framework? I'm aware of the N+1 issue, but is there any other gotchas I should be aware of? For instance, do Linq-to-EF queries cache as well as stored procedures? Are there instances where the SQL generated by EF is less than optimal?
Thanks!
Whenever you need to do the work "inside" the DB server and not go back and forth between your code and Server.
Also - when you use stored procedures, you can alter the code without recompiling/deploying, it might be easier on production environments.
IMHO it sometimes easier to code complex SQL statements in T-SQL rather than using LINQ....
when trying to make this question, i got this one it is using Java, and in the answer it gave a Ruby example, and it seems that the injection happens only when using Json? because i've an expose where i'll try to compare between NoSQL and SQL and i was trying to said: be happy, nosql has no sql injection since it's not sql ...
can you please explain me:
how sql injection happens when using Python driver (pymongo).
how to avoid it.
the comparison using the old way sql injection using the comment in the login form.
There are a couple of concerns with injection in MongoDB:
$where JS injection - Building JavaScript functions from user input can result in a query that can behave differently to what you expect. JavaScript functions in general are not a responsible method to program MongoDB queries and it is highly recommended to not use them unless absolutely needed.
Operator injection - If you allow users to build (from the front) a $or or something they could easily manipulate this ability to change your queries. This of course does not apply if you just take data from a set of text fields and manually build a $or from that data.
JSON injection - Quite a few people recently have been trying to convert a full JSON document sent (saw this first in JAVA, ironically) from some client side source into a document for insertion into MongoDB. I shouldn't need to even go into why this is bad. A JSON value for a field is fine since, of course, MongoDB is BSON.
As #Burhan stated injection comes from none sanitized input. Fortunately for MongoDB it has object orientated querying.
The problem with SQL injection comes from the word "SQL". SQL is a querying language built up of strings. On the other hand MongoDB actually uses a BSON document to specify a query (an Object). If you keep to the basic common sense rules I gave you above you should never have a problem with an attack vector like:
SELECT * FROM tbl_user WHERE ='';DROP TABLE;
Also MongoDB only supports one operation per command atm (without using eval, don't ever do that though) so that wouldn't work anyway...
I should add that this does not apply to data validation only injection.
SQL injection has nothing to do with the database. It is a type of vulnerability that allows for execution of arbitrary SQL commands because the target system does not sanitize the SQL that is given to the SQL server.
It doesn't matter if you are on NoSQL or not. If you have a system running on mongodb (or couchdb, or XYZ db), and you provide a front end where users can enter records - and you don't correctly escape and sanitize the input coming from the front end; you are open to SQL injection.
Using EF we can use LINQ to read data which is rather simple (especially using fluent calls), but we have less control unless we write eSQL on our own.
Is writing eSQL actually data store independent code?
So if we decide to change data store, can the same statements still be used?
Does writing eSQL strings in your code pose any serious security threats similar to writing TSQL statements as plain strings in C# code? That's why SPs are recommended. Could we still move eSQL scripts outside of code and use some other technique to make them a bit more secure?
ESQL is database independent in general, so it can be used like LINQ to Entities.
But please be aware that it has more serious limitations. It does not have DML, DDL, and DB-specific abilities.
The main ESQL disadvantage is that even simple query containing a couple of lines can be translated into monstrous SQL query for a particular DBMS, so one should check the generated SQL to be appropriate and analyze if it is optimal.
ESQL will not be executed directly on a database, it will be translated to SQL.
EF Security discussion is usually started from the connection string proptection, then model security is discussed, and only after that query protection is analyzed. It's up to the developer to decide if the peculiar query should be protected.
I'm doing an iPhone application, and I'm using SQLite.
The problem is that I had some issues with the query (I did bad binding) so, this is my question:
How can I log in my iPhone application the effective SQL query/statement with the bindings that SQLite receives?
Thanks.
Easiest way would be to create a wrapper to your call to sql functions and add log functionality to it.
I'm not sure the file written by the PRAGMA journal_mode is readable, but I couldnt use this pragma.
You can also have a look at an excellent existing wrapper from Gus Mueller: fmdb
I don't think this is possible.
As far as I know, prepared statements aren't built into "full SQL" strings before they get to the database engine. The parameter values aren't escaped, quoted, and inserted into the SQL string only to be parsed and decoded in the next step: the values bypass the query parsing entirely and go straight into the data engine.