Hi folks,

I've been playing with sequel now for a few months, and overall, I
think it's great.  I've seen a couple of minor issues that I've worked
around (might post those separately), but my biggest concern relates
to the way the parameter substitution is handled in the dataset class.

I've looked at this in the code, and I must say I'm nervous about what
sequel is doing when it is creating the queries to send to the
database.  Normally, the best defense for SQL injection is to use
prepared statements, but one of the areas I've found the most "messy"
is the sequel support for prepared statements.

My application is such that I'm not really interested in the Model
capabilities, so I'm using the dataset directly.  However, because of
my database schema, there are a number of multi-table queries that
I've written using standard SQL92 syntax.  It seems that it is
impossible to use these as prepared statements in sequel.  Is this
really true?

I'm using both SQLite3 and PostgreSQL for the database back-ends, and
I believe that I'm using the ruby-pg implementation.

I generally really like the syntax provided by the library, but the
only way that I can directly execute my multi-table queries is to use
the "raw SQL" mode of the dataset (which, thankfully, uses SQL92
standard prepared statement placeholders).  However, since the library
does string substitutions on the parameter values, I have the concern
that my application is not nearly as robust & secure as it would be if
I were using the "real" prepared statement support of the underlying
database engine.

Fundamentally, I guess my question boils down to:  how extensively has
the library been tested against all known SQL injection techniques?

Currently, I've about 1,325 lines of a ~15K LOC application which
depend on sequel.  Because I like the majority of the syntax, I'm
hesitant to change to a different database library, but my security
concerns currently outweigh my affinity for the library.

Before this application gets much further, I'm going to need to
finalize on the database back-end API.  Currently, I'd prefer to use
sequel vs. going back to DBI, but DBI has a much more "natural" API
for working with prepared statements, so I'm tempted to revert back to
it in the near future.

Apologies for the slightly stream-of-consciousness post, but I'd
appreciate any comments or thoughts on the above to help me decide how
to proceed with the application.

Thanks in advance,

ast

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"sequel-talk" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/sequel-talk?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to