#37016: Avoid propagating invalid arguments from When() to Q() on dictionary
expansion
-------------------------------------+-------------------------------------
Reporter: Jacob Walls | Owner: (none)
Type: | Status: new
Cleanup/optimization |
Component: Database layer | Version: 6.0
(models, ORM) |
Severity: Normal | Resolution:
Keywords: not-security, | Triage Stage:
_connector, _negated | Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Jacob Walls:
Old description:
> The Security Team just closed a report extrapolating from
> 279f8b9557f0fef9790822b0c38164fc9dfcab2a arguing that `When()` is missing
> the same protection we gave to `filter()` and friends, whereby we swallow
> `_connector` and `_negated` arguments instead of passing them down to
> `Q()`, like this:
>
> {{{#!py
> def _filter_or_exclude_inplace(self, negate, args, kwargs):
> if invalid_kwargs :=
> PROHIBITED_FILTER_KWARGS.intersection(kwargs):
> invalid_kwargs_str = ", ".join(f"'{k}'" for k in
> sorted(invalid_kwargs))
> raise TypeError(f"The following kwargs are invalid:
> {invalid_kwargs_str}")
> }}}
>
> We don't consider this a vulnerability, as we didn't even consider
> 279f8b9557f0fef9790822b0c38164fc9dfcab2a a vulnerability, just an
> incidental finding we shipped with the security releases (notice the
> commit message says "Refs ..." not "Fixed ...") and thought prudent to
> backport. (The crux of the CVE was the arbitrary SQL injection, not a
> query logic bug downstream of a user's failure to validate user inputs.)
>
> Still, we would welcome a PR to django's main branch that extends the
> protection quoted above to `When()`.
>
> Thanks m0_ld for the report.
New description:
The Security Team just closed a report extrapolating from
279f8b9557f0fef9790822b0c38164fc9dfcab2a arguing that `When()` is missing
the same protection we gave to `filter()` and friends, whereby we raise
errors for the `_connector` and `_negated` arguments instead of passing
them down to `Q()`, like this:
{{{#!py
def _filter_or_exclude_inplace(self, negate, args, kwargs):
if invalid_kwargs :=
PROHIBITED_FILTER_KWARGS.intersection(kwargs):
invalid_kwargs_str = ", ".join(f"'{k}'" for k in
sorted(invalid_kwargs))
raise TypeError(f"The following kwargs are invalid:
{invalid_kwargs_str}")
}}}
We don't consider this a vulnerability, as we didn't even consider
279f8b9557f0fef9790822b0c38164fc9dfcab2a a vulnerability, just an
incidental finding we shipped with the security releases (notice the
commit message says "Refs ..." not "Fixed ...") and thought prudent to
backport. (The crux of the CVE was the arbitrary SQL injection, not a
query logic bug downstream of a user's failure to validate user inputs.)
Still, we would welcome a PR to django's main branch that extends the
protection quoted above to `When()`.
Thanks m0_ld for the report.
--
--
Ticket URL: <https://code.djangoproject.com/ticket/37016#comment:1>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion visit
https://groups.google.com/d/msgid/django-updates/0107019d44cd94fa-a37e758e-d782-47d4-9158-3ca5118bb961-000000%40eu-central-1.amazonses.com.
