In situations where we cannot use bind variables, such as when our dynamic queries have to execute ddl statements, is the following list of defenses enough?
Never use anonymous blocks in dynamic queries so that only one statement can be executed by execute immediate. This stops code injection attacks.
Escape all single quotes using replace function. This stops statement modification attacks.
What characters other than single quote can be used for quoting and how can they be escaped?
How to prevent statement modification through AND, UNION etc attacks?
How to prevent function calling attacks so that user cannot call built-in functions? Every user has rights of calling those functions and calling of those functions can cause denial of service and buffer over flow attacks. How to save from that?
I prefer allowing gui to take single quote character means not check that in client side and server side validation in a web application. This is to allow names like O'Brian. At the database level, just before the execute immediate statement escape the single quotes. Do you know of any better approach?
Solution to any other vulnerabilities not listed above.
Note: I have already gone through about a dozen questions related to SQL injection on this site. I still posted this question because:
It's specific to oracle. Most questions I found on this site on the topic are related to MySQL, SQL server etc.
It's specific to situations where bind variables cannot be used. If one can use bind variables then that is enough and no other defense is needed.
It's better to list down all needed methods at one place.
Some advanced techniques of SQL injection like function calling are not discussed in detail and I cannot find any solution against that.
Edit:
Following may be a viable solution.
I think I have a solution. Its in addition of using usual defenses such as static statements, bind variables etc. Its particularly useful in situations where the usual defenses cannot be used. Note that the only situation where bind variables cannot be used is ddl statements. For such statements:
Verify existence of database object using static sql. This solves half of the problem.
The other half is related to the new value we want to put in the database object. For example when changing password of a user: the first half is username, the second half is password. One should encrypt the new value at front-end and save encrypted value in database. The encrypted value encrypted as sql code cannot do any damage to database (cannot call any functions for example).
Never change user input because of various reasons such as confusing user for example in passwords, the value may be valid in some situations such as it can be a valid html etc. It means let the ['], [\'], [#] pass through all validations unchanged. It's the static SQL or the encryption that is supposed to handle it.
Is there any situation where we cannot encrypt the new value?
Related
Can someone provide a better explanation of the xdmp:eval() and xdmp:value() functions?
I had tried to follow the Developer API. However, I am not really satisfied with the instances and it's a bit vague for me. I would really appreciate if someone could help me understand those functions and their differences with examples.
Both functions are for executing strings of code dynamically, but xdmp:value is evaluated against the current context, such that if you have variables defined in the current scope or modules declared, you can reference them without redeclaring them.
xdmp:eval necessitates the creation of an entirely new context that has no knowledge of the context calling xdmp:eval. One must define a new XQuery prolog, and variables from the main context are passed to the xdmp:eval call as parameters and declared as external variables in the eval script.
Generally, if you can use xdmp:value, it's probably the best choice; however, xdmp:eval has some capabilities that xdmp:value doesn't, namely everything defined in the <options> argument. Through these options, it's possible to control the user executing the query, the database it's executed against, transaction mode, etc.
There is another function for executing dynamic strings: xdmp:unpath, and it's similar to xdmp:value, but more limited in that it can only execute XPath.
I am looking arround for prepared statements in Jython with JDBC (zxJDBC) / SQLite.
All I find is examples like this (book, Jython documentation):
qry = "select continent from country where name = ?"
cursor.executemany(qry,['Austria'])
However I always understood prepared statements as a way to let the Database optimize a statement without knowing the values inserted for the placeholders. One then receives a handle to this statement wich has been passed through the optimizer and can execute this with different values, saving the query optimization effort, thus I would expect that the following approach is better:
qry = cursor.prepare("SELECT * FROM `table` WHERE `field`=? AND `field2`=?") #usually mor complex queries
qry.execute(cursor, ?, (val1, val2)??) #here is the problem
unfortunately I can't find examples of how to use the execute and the documentation is lacking.
PyStatement.execute(cursor, params, bindings)
Could you explain me what params is for and if my guess at how to use bindings is correct. My best guess for params would be, that they are the first parameter to the setInt-Method (or the like) from Javas JDBC, put that would be rather surprising. I expected to be Jython more short handed and for it to simply expect the parameters in the right(front to back) order.
Bonus: Is there a way to free a resultset? (Besides closing the cursor)
It looks like this extension uses the normal Python Database Specification v2
For execute it says:
A reference to the operation will be retained by the cursor. If the same operation object is passed in again, then the cursor can optimize its behavior. This is most effective for algorithms where the same operation is used, but different parameters are bound to it (many times).
And for executemany it says:
The same comments as for .execute() also apply accordingly to this method.
So if this drivers actually implements these suggested semantics, then just passing in the same string into execute or executemany should reuse the preparedstatement, however you might want to check the implementation (or ask the implementer) to be sure
Thanks for your help as I bootstrap my way into Ruby and Rails.
In the Rails API for ActiveRecord::Base, there's a section on Conditions that's meant to simply cover syntax for interactions with ActiveRecord. But the example they've used includes a very interesting (to me) primer on input-sanitization in Ruby/Rails:
class User < ActiveRecord::Base
def self.authenticate_unsafely(user_name, password)
where("user_name = '#{user_name}' AND password = '#{password}'").first
end
def self.authenticate_safely(user_name, password)
where("user_name = ? AND password = ?", user_name, password).first
end
def self.authenticate_safely_simply(user_name, password)
where(:user_name => user_name, :password => password).first
end
end
Following this example code, they explain that:
"The authenticate_safely and authenticate_safely_simply both will sanitize the user_name and password before inserting them in the query, which will ensure that an attacker can’t escape the query and fake the login (or worse)."
I totally get how this sanitization of inputs is a Good Thing in preventing injection attacks. What I do not understand is where and how this implicit sanitization is happening, given that there are no special methods being called to pre-process the input data. The various example methods appear to have nearly identical semantics and yet the variations in form have huge effects on safety because of the way that they're parsed. I'm assuming that these variations in form are similar in effect to the difference between using single-quotes and double-quotes around a string containing escape characters. But can anybody help me get smarter, faster, by understanding in general terms (or rather: at the logical level, rather than inside the interpreter) what's actually happening under the hood to make this so?
Also, to what extent are any of these differences dependent on Rails-specific constructs, rather than the underlying Ruby?
Thank you!
The input sanitization is a feature provided by Active Record known as prepared statements or parameterized statements.
Most database access libraries provide this natively, however, Active Record chooses to emulate this feature using string-mangling mechanisms. See build_where in active_record/relation/query_methods.rb and backtrack your way to sanitize_sql_for_conditions (via its sanitize_sql alias) in active_record/base.rb. (Many thanks to mu is too short for the research.)
Instead of the old-style practice of building query strings as strings in the application, you have a static template query with parameters. When you call the query, you supply the parameters and Active Record will construct a safe query for the SQL engine to execute.
You could do this task yourself -- myriad PHP programmers choose to eschew their similar PDO database access layer. However, many programmers cannot get this correct: there are roughly 1500 SQL Injection flaws discovered in the last three years and my local CVE database shows over 5000 instances of programs vulnerable to SQL injection attacks since MITRE started keeping track. Nearly all of these were due entirely to people who chose to write their own SQL code by hand and did not properly sanitize their input. (I didn't personally inspect each one but I can't recall seeing any flaws in the ORM or database access layers that allow SQL injection attacks through. But to be on the conservative side, I chose "Nearly all".)
Fellow stacker Jeff Atwood equates old-style SQL queries as the goto of database programming:
Non-parameterized SQL is the GoTo statement of database programming. Don't do it, and make sure your coworkers don't either.
I have some code that is responsible for converting data from an IDataReader into an IronPython.Runtime.List of PythonTuples. This same code is employed for several different kinds of database connections (including Access, Oracle and MySql).
Oracle's OracleDecimal datatype causes an overflow when calling dataReader.GetValues() when the cursor contains a value with a large precision. This issue has been well documented, and the solutions always involve using specific methods on the OracleDataAdapter. I only have an IDataReader interface.
Is there any way around this issue without binding my code specifically to ODP.NET? Surely there must be some way to get at this data in a provider-agnostic way?
The only provider agnostic method that I am aware of is to round the values in your select statement. I've found that rounding to 15 decimal places usually does the trick.
It may not be exactly what you're looking for, but the System.Data.Common.DbDataReader class has a GetProviderSpecificValues function that may do what you want
Which of these is more efficient in ColdFusion?
isDefined('url.myvar')
or
structKeyExists(url, 'myvar')
These days (CF8+) the difference in speed is not that great. However, structKeyExists is indeed a little faster. Here's why.
When you use isDefined, the string you pass in is searched for as a key name in several scopes. As of CF9, the list of scopes, in the order checked is: (source)
Local (function local, UDFs and CFCs only)
Arguments
Thread local (inside threads only)
Query (not a true scope, applies for variables within query loops)
Thread
Variables
CGI
CFFile
URL
Form
Cookie
Client
Even if you use the scope name with isDefined (like: if isDefined('variables.foo')) the list will still be checked in order; and if the variable local.variables.foo is defined, it will be found BEFORE variables.foo.
On the other hand, structKeyExists only searches the structure you pass it for the existence of the key name; so there are far fewer places it will have to look.
By using more explicit code (structKeyExists), not only are you gaining some performance, but your code is more readable and maintainable, in my opinion.
Use the one which is easier to read and best shows what you're doing.
The difference between the two is incredibly small, and very likely not worth worrying about at all.
Don't waste time optimising code unless you have a proven and repeatable test case which demonstrates the slowness.