-
-
Notifications
You must be signed in to change notification settings - Fork 3k
SQL queries constructed with string concatenation [security] #15040
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
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## 5.2 #15040 +/- ##
============================================
+ Coverage 63.45% 63.68% +0.23%
- Complexity 34635 34676 +41
============================================
Files 2273 2274 +1
Lines 103603 103754 +151
============================================
+ Hits 65739 66079 +340
+ Misses 37864 37675 -189
🚀 New features to boost your workflow:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't see any issues in the code 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I've tested the PR and found no issues.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Checked the code, seems good. There are a few ->expr()->literal
calls that were added that should be further transformed into full parameters but it's already better than it was before
Description
Some SQL query strings are built using potentially unsafe string concatenation rather than parameter binding.
In \Mautic\CampaignBundle\Entity\LeadEventLogRepository::getChartQuery(), several query conditions are built using direct string concatenation and manual quoting, both of which are potentially unsafe. For example:
$query->andwhere("e.channel = '".$options['channel']."'");
This has the potential for problems if the value in $options['channel'] contains single quotes or other metacharacters. It is difficult to work backwards reliably from such a condition string to form a query constraint; It's much safer to give Doctrine the parameter separately, allowing it to escape, quote, and bind the value safely, so this would become:
$query->andWhere('e.channel = :channel')
->setParameter('channel', $options['channel']) |
This pattern appears in several other places.
We did not investigate whether it's possible to exploit this, and these specific cases may be sanitised or made safe somewhere upstream of this method call, but this string concatenation approach is something that should be avoided in general.
Impact
Some submitted values could open the way to SQL injection or unexpected errors.