-
Notifications
You must be signed in to change notification settings - Fork 454
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ConstantExpressions do not get parameterized in SQL statements #4463
Comments
I don't think this should be done. This is a very impacting change that has potentially dramatic impact on execution plans, depending on exact queries, similar queries executed beforehand and RDBMS. The described benefit is: "I can create insecure SQL if I manually build an expression where a 'constant' is user-injected".
|
I have observed somewhat similar issue with
Is that expected behaviour? |
Summary:
I've noticed that ConstantExpressions do not get parameterized when an IQueryable is translated to SQL.
While this won't be problem under most circumstances it can be when manually creating expression trees.
Description:
Consider the following queries (where Client.Identifier is a nvarchar(50) column in a SQL Server 2022 database)
The first query is translated to
whereas the second yields in the not parameterized SQL
For usually this won't be a big deal in terms of SQL injection, since under most circumstances ConstantExpressions are created by Linq-Statements like the one above, that is they are written by the developer and not created from user input.
However, I am creating the predicate expression using the System.Linq.Expressions.Expression factory method, like so:
This again yields in an unparameterized SQL statement, which then is vulnerable to SQL injection (or would break SQL Server Always Encrypted),
Currently this is no problem for me personally as I am able to create a MemberExpression which leads to a parameterized SQL statement.
That notwithstanding I'd like to propose to always parameterize ConstantExpressions in case anyone creates expression trees like I did first and thereby accidentally gets insecure SQL statements.
Environment details
Linq To DB
version: 5.2.2Database (with version): SQL Server 2022
ADO.NET Provider System.Data.SqlClient 4.8.6
Operating system: Win 10
.NET Version: .net 6
The text was updated successfully, but these errors were encountered: