Extend admonition to avoid constructing query expressions from unsanitized user input
The Security Team occasionally receives reports where a proof of concept pipes unsanitized user input directly to a query expression argument traditionally regarded as statically configured and thus developer-controlled.
We haven't accepted these as vulnerabilities, because each case we've confronted has a clear domain to validate (e.g. positive integers) that a garden-variety form or serializer would handle, as opposed to anything that would require the db adapter to escape.
We have this clearly documented in the Func API where positional arguments can be user-driven but keyword arguments get interpolated directly into SQL (beware!), but this is potentially muddled by the inconsistency where some subclasses allow positional arguments for convenience but then pass that on to Func() via keyword (beware!)
Working on a way to clarify this in the Func docs and cross-link from the security reporting guidelines.
Change History
(8)
| Keywords: |
extra rawsql added
|
| Triage Stage: |
Unreviewed → Accepted
|
| Version: |
→ dev
|
| Patch needs improvement: |
set
|
| Patch needs improvement: |
unset
|
| Triage Stage: |
Accepted → Ready for checkin
|
| Resolution: |
→ fixed
|
| Status: |
assigned → closed
|
Thank you!