#28680: Document that Func.__init__()'s **extra and as_sql()'s **extra_context
aren't escaped
--------------------------------------+------------------------------------
Reporter: Hynek Cernoch | Owner: nobody
Type: Cleanup/optimization | Status: new
Component: Documentation | Version: 1.11
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
--------------------------------------+------------------------------------
Comment (by Hynek Cernoch):
It is sufficient to be committed anything at first glance it was very
nice, but probably not to close the issue.
Another place where it should be added is `docs/topics/security.txt` to be
easier memorable.
I think that the word "escaping" is vague and it should be used
[https://www.owasp.org/index.php/SQL_Injection_Prevention_Cheat_Sheet#Defense_Option_4
:_Escaping_All_User-Supplied_Input "as the last resort" (OWASP)] and an
ORM is considered more secure than escaping. Escaping means usually to
protect only some special characters. A simple string `"0) OR (TRUE"` can
be also dangerous if parsed into `WHERE some_function(field_a,
%(number)s)`. Extra and extra_context can seem as if safe for simple
values like "ASC"/"DESC" or pseudo numeric values that are not actually
converted to number by mistake, but they are not. It is still more risky
than RawSQL due to frequent underestimation and misunderstanding what is a
trusted user input. The string can not be passed insecure in RawSQL by
"params" because all modern database backends substitute it to SQL by
after parsing SQL syntax. It is better than to escape by apostrophes at
the beginning and at the end and to protect apostrophes etc. inside.
The user could still expect an analogy that `template` and `extra` are
similar to `RawSQL` and `params` and that the warning is also very
similar, that is:
"RawSQL()... You should be very careful to escape any parameters that the
user can control by using `params` in order to protect against *SQL
injection*..."
It should be emphasized that this works differently.
"as these values aren't escaped when they're inserted into the SQL string"
+ "(unlike RawSQL params)"
What can be a future improvement: (maybe I will write something)
* `arg_joiner` can help to not need `extra` params. Maybe a short example
of `arg_joiner` will be useful, otherwise the user thinks that he
understands `extra` params better.
* There is nothing that helps to protect correctly with "extra". The
escaping depends on the backend, different for MySQL and for other db.
--
Ticket URL: <https://code.djangoproject.com/ticket/28680#comment:3>
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 post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/django-updates/066.e8139d5d994065c876a42d2491189c5c%40djangoproject.com.
For more options, visit https://groups.google.com/d/optout.
