The following SQL I am trying to run is returning sql_string of "SELECT id FROM people WHERE id IN ("16")":
#ids = ["1", "6"]
sql_string = <<-SQL
SELECT id
FROM people
WHERE id IN ("#{#ids}")
SQL
Can someone please help modify the above query so it will create the sql_string of "SELECT id FROM people WHERE id IN (1, 6)"
Just throwing #ids in the query will concatenate the array and give you "16". You'll want to run #ids.join(',') to comma separate them. Plus you need to wrap the expression part of the string in #{}. Otherwise it will treat it as literal.
#ids = ["1", "6"]
sql_string = <<-SQL
SELECT id
FROM people
WHERE id IN (#{#ids.join(',')})
SQL
P.S. There are very few valid reasons for manually writing a whole SQL query in Rails. You should look into using ActiveRecord to do something like People.find_all_by_id(#ids) instead.
With the code fragment in one of the answers above, "#ids" is not sanitised. This is fine if your code 'knows' that "#ids" contains only valid integer IDs, but very dangerous if any ID came in from user input or a URL. See:
http://api.rubyonrails.org/classes/ActiveRecord/Base.html#M001831
...for a possible solution. This is a protected method so we have to call via 'send' to demonstrate its use at the console:
>> ActiveRecord::Base.send(:sanitize_sql_for_conditions, { :id => [1,6] }, :people)
=> "people.\"id\" IN (1,6)"
...i.e. insert the above result after the SQL WHERE keyword. As the previous answer says, unless you have a really complex case which can't be built up using standard Rails calls (which is indeed the case for Coderama but may not be for future readers), you should always try to avoid writing SQL by hand.
Bearing this in mind, an alternative way to build up complex queries is the "ez_where" plugin which is worth a look if anyone reading is thinking of resorting to SQL:
http://github.com/ezmobius/ez-where
Related
I have a task to check and prove if there is a way to prevent SQL Injection without access to the database first - So no parameterized statements.
This basically means:
Is there a way to parse SQL statement as a string using any kind of tool or framework that would prove that SQL has been injected into it.
Any techniques available.
At first I had an idea to check if SQL matches a certain pattern like this:
Let somewhere be any kind of string that user can type in.
This is my SQL:
SELECT Id FROM somewhere
This statement has a pattern that looks like this:
SELECT SOME_VALUE FROM SOME_TABLE
Then let's say user wrote someTable WHERE 1=1; into the somewhere variable - (I know its not the smartest of SQL Injections)
But the point is now I have a statement that looks like this:
SELECT Id FROM someTable WHERE 1=1;
Which effectively gives us a statement that has a pattern like this:
SELECT SOME_VALUE FROM SOME_TABLE WHERE SOME_CONDITION
Which does not match the initial pattern:
SELECT SOME_VALUE FROM SOME_TABLE
Is that a correct way to check if SQL has been injected? I haven't found any tools that actually use this technique, or any other technique than just parameters (which require connection to the database). Don't worry - I know that parameters are the way to go, this task is about having no connection to the database.
It would be an idea if you block certain keywords and symbols like 'WHERE', 'AND', 'OR', ';', and '='.
But this is just a naive approach and for production, you should use parameterized statements.
From https://en.wikipedia.org/wiki/Code_injection#Preventing_problems
To prevent code injection problems, utilize secure input and output handling, such as:
Using APIs that, if used properly, are secure against all input characters. Parameterized queries (also known as "Compiled queries", "prepared statements", "bound variables") allows for moving user data out of string to be interpreted. Additionally Criteria API[7] and similar APIs move away from the concept of command strings to be created and interpreted.
I was wondering how and why "parameterized queries (also known as "Compiled queries", "prepared statements", "bound variables") allows for moving user data out of string to be interpreted" and prevent or mitigate code injection problems?
Can you also provide some examples in explanation?
Thanks.
Compiled queries use special syntax that the database understands. They usually add placeholders for parameters such as in:
select * from applicant where name = ?
select * from applicant where name = :name
The exact syntax depends on the specific technology: JDBC, ODBC, etc.
Now, once those queries are sent to the database (without the specific parameter values), the database "saves" them. Later on (usually in the same database session), you can run them many times, by just providing the parameter values each time.
SQL Injection Safety
They are also safe against SQL injection. For example, if in the previous query instead of a simple value such as Mary you used the value x'; delete from applicant; -- the database will work safely. It would run something like:
select * from applicant where name = 'x; delete from applicant; --'
This query won't probably find anything and will be safe.
If instead you didn't use compiled query, but just decided to concatenate the SQL as a string you would do something like:
String sql = "select * from applicant where name = '" + param1 + "'";
And would end up with the UNSAFE query:
select * from applicant where name = 'x'; delete from applicant; --
This one would run two queries. The second one will delete all the information from your table. Probably not what you want.
I'm not particularly familiar with Ruby on Rails, but I'm troubleshooting an issue we're experiencing with a rake job that is supposed to be cleaning database tables. The tables grow very large very quickly, and the query generated by ActiveRecord doesn't seem to be efficient enough to handle it.
The Ruby calls looks like this:
Source.where("id not IN (#{Log.select('DISTINCT source_id').to_sql})").delete_all
and this:
Log.joins(:report).where(:report_id => Report.where(cond)).delete_all
I'm trying to get at the SQL, so we can have our DBA's attempt to optimize it better. I've noticed if I drop the ".delete_all" I can add a ".to_sql" which gives me the SELECT statement of the query, prior to the call to ".delete_all". I'd like to see what SQL is being generated by that delete_all method though.
Is there a way to do that?
Another option is to use raw Arel syntax, similar to a simplified version of what ActiveRecord::Relation#delete_all does.
relation = Model.where(...)
arel = relation.arel
stmt = Arel::DeleteManager.new
stmt.from(arel.join_sources.empty? ? Model.arel_table : arel.source)
stmt.wheres = arel.constraints
sql = Model.connection.to_sql(stmt, relation.bound_attributes)
print sql
This will give you the generated delete sql. Here's an example using postgres as the sql adapter
relation = User.where('email ilike ?', '%#gmail.com')
arel = relation.arel
stmt = Arel::DeleteManager.new
stmt.from(arel.join_sources.empty? ? User.arel_table : arel.source)
stmt.wheres = arel.constraints
sql = User.connection.to_sql(stmt, relation.bound_attributes)
=> DELETE FROM "users" WHERE (email ilike '%#gmail.com')
From the fine manual:
delete_all(conditions = nil)
Deletes the records matching conditions without instantiating the records first, and hence not calling the destroy method nor invoking callbacks. This is a single SQL DELETE statement that goes straight to the database, much more efficient than destroy_all.
So a Model.delete_all(conditions) ends up as
delete from models where conditions
When you say Model.where(...).delete_all, the conditions for the delete_all come from the where calls so these are the same:
Model.delete_all(conditions)
Model.where(conditions).delete_all
Applying that to your case:
Source.where("id not IN (#{Log.select('DISTINCT source_id').to_sql})").delete_all
you should see that you're running:
delete from sources
where id not in (
select distinct source_id
from logs
)
If you run your code in a development console you should see the SQL in the console or the Rails logs but it will be as above.
As far as optimization goes, my first step would be to drop the DISTINCT. DISTINCT usually isn't cheap and IN doesn't care about duplicates anyway so not in (select distinct ...) is probably pointless busy work. Then maybe an index on source_id would help, the query optimizer might be able to slurp the source_id list straight out of the index without having to do a table scan to find them. Of course, query optimization is a bit of a dark art so these simple steps may or may not work.
ActiveRecord::Base.logger = Logger.new(STDOUT) should show you all the SQL generated by rails on your console.
In order to prevent SQL Injection for my site, i have used prepared statements.
Now let's say i use somewhere in my code, a simple SQL query like this :
SELECT DATA FROM DATABLE;
Is this code prone to injection ? Well it seems to me that's not possible to be, as there is no user input.But i just want to be sure.
If your statement is fixed (has no outside parameters), then it is immune to injection.
So if your code looks something like this:
result = RunQuery("SELECT * FROM Table")
then you are safe, since the query will always be the same everytime and cannot be influenced by users.
Inject is only possible if you use a variable in your query.
If you use prepaired statements with params it is not possible.
select * from user where id = ?
You cannot change this query, only the value, in that case you will just get no results
If you use
select * from user where id = '$id'
now depending on the value of $id we can have a sql inject.
If $id would be "0' or id > 0 " you will allways login ;)
I have to perform lexical analysis on the oracle query and separate the query to various parts (based on the clauses)in perl. For example,Consider :
Select deleteddate,deletedby from temptable where id = 10;
I need to print
select : deleteddate , deletedby
from : temptable
where : id = 10
I used this code snippet :
my $parser= SQL::Statement->new();
$parser->{PrinteError}=1;
my $query = SQL::Statement->new("select deleteddate,deletedby from temptable where id =10",$parser);
my #columns = $query->columns();
print $columns[0]->name();
Though this prints deleteddate, this fails when i give a subquery inside the select clause:
Select deleteddate,deletedby,(select 1+1 from dual) from temptable where id = 10;
Can you please point me in the correct direction.
Thanks.
It looks to be a limitation of that package; it seems to be a general purpose parser and not something that can understand advanced features like subqueries or Oracle-specific constructs like "from dual".
What are the constraints of your system? If python is an option it looks like this is a more fully-featured library:
http://code.google.com/p/python-sqlparse/
The other option would be to use the actual Oracle database, if that's an option. You would:
use the DBI and DBD::Oracle modules to create a connection to Oracle & get a database handle,
create a statement handle by calling prepare() on the database handle using your query,
execute the query (there may be an option in Oracle to execute in "test only" or "parse only" mode),
examine the statement handle (such as the NAMES_hash property) to get the column names.
Otherwise it seems the SQL::Statement module unfortunately just isn't up to the task...