Hey Jeremy!
This is a good change. I always found methods accepting plain strings in
ORMs sloppy, limited and potentially dangerous. Personally I'm gradually
moving towards APIs that are stricter wrt arguments they accept, and try to
avoid implicit coercions as much as possible. It's a bit painful in the
beginning since folks are used to convenience behaviors like with `limit`
that will happily work with either a string or an integer, whereas it
really should only accept integers. Once libraries like Sequel (or rom-rb)
become stricter, people will also have to learn how to handle input
properly (ie http params) with explicit type specs and coercions. I'm
pretty sure a lot will complain about this in the beginning, but it's
really worth the effort as our libraries will become simpler and more
secure, and applications will deal with coercions in a more explicit and
correct way (FWIW we're building tools that will greatly help with this,
like dry-validation and dry-types).
Cheers,
solnic
On Tuesday, April 4, 2017 at 5:33:03 PM UTC+2, Jeremy Evans wrote:
>
> Since the very first code commit, Sequel has supported treating plain
> strings passed to the filtering methods as literal strings (with possible
> placeholders):
>
> DB[:table].where("name > 'A'")
> DB[:table].where("name > ?", "A")
>
> Usually, this is just fine. However, the most common cause of SQL
> injection in applications using Sequel is when a developer interpolates
> user input directly into the string. This can be fairly obvious, like:
>
> DB[:table].where("name > '#{params[:foo]}'")
>
> Or it can be much more subtle:
>
> DB[:table].first(params[:limit])
>
> If you expect params[:limit] to be an integer, you would expect this to
> return no more than that number of rows. However, if the user can submit a
> string (fairly simple if you are taking the params from uploaded JSON
> without checking the type), this would use the user-provided string
> directly in the SQL query (SQL injection).
>
> In Sequel 4.32.0, I added the no_auto_literal_strings extension, which
> addresses this issue. It changes Sequel so that using a plain string as a
> filter condition raises an error. If you want to use a literal string in a
> filter condition, you need to convert the plain string to a literal string
> using Sequel.lit. This makes security auditing of applications for SQL
> injections much easier, and greatly reduces the risk of SQL injection.
>
> I am considering making the no_auto_literal_strings extension the default
> behavior in Sequel 5, with an auto_literal_strings extension to get the
> historical behavior. I would like to get some feedback from the community
> before making the final decision.
>
> Thanks,
> Jeremy
>
>
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sequel-talk.
For more options, visit https://groups.google.com/d/optout.
