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.
