SQL Injection for Slick-Generated SQL

[Randall Schulz]

Hi,

My security team asked what Slick does to guard against SQL injection attacks. I could not find anything related to this and while I'd be awfully surprised if there were a real vulnerability, I thought I'd seek some details.

Is Slick 100% intrinsically impervious to SQL injection tasks? If so, by virtue of what practices and techniques?


Randall Schulz

[Christopher Vogt]

If you use the lifted embedding you are 100% secure regarding SQL
injections unless there is a bug in Slick.

If you write plain SQL you have to be more careful (as in any SQL
library). If you hand plain Strings to Slick and tell it that it is
valid SQL, then it is your job as a user to make sure they are safe.
There is nothing Slick can do about it. However there are two tools to
support you. Prepared statements with the ? placeholder syntax protect
these spots from SQL injections. Slick's SQL interpolations, i.e.
sql"..." or sqlu"..." automatically escape inserted variables like
$varname. You just have to be careful not to accidentally use s"...",
which may go unnoticed.

[Randall Schulz]

Naturally I'm aware that if one's code composes SQL itself, the onus is on that code to guard against injection attacks.

So I am expressly asking about the SQL that Slick generates internally. We do use the lifted embedding (at least now while we're using Slick 1.0.x) and I've gone to semi-heroic measures (made possible by the query munging code you supplied!) to avoid using "raw" SQL.

I am curious if the same guarantees of imperviousness to SQL injection attacks are provided when using the direct embedding in Slick 2.0?


Randall Schulz

[Christopher Vogt]

> So I am expressly asking about the SQL that Slick generates internally.
>

> I am curious if the same guarantees of imperviousness to SQL injection
> attacks are provided when using the direct embedding in Slick 2.0?

Should 100% safe from SQL injection to our knowledge (and otherwise it's
a bug). Slick understands the query code and its types. Slick knows what
are values and what are operators. (Potentially malicious) SQL code
contained in values never leaks out of them into the code, because Slick
escapes values appropriately.

> We do use the lifted embedding (at least now while we're using Slick
> 1.0.x) and I've gone to semi-heroic measures (made possible by the
> query munging code you supplied!) to avoid using "raw" SQL.

You are probably aware of this, but for completeness: if you replace the
SQL string the lifted embedding uses in that way, you of course have to
make sure that that string is safe.

[Randall Schulz]

Thanks. That's pretty much what I expected.