On Tue, Oct 9, 2018 at 8:55 PM Guido van Rossum <gu...@python.org> wrote:
> On Tue, Oct 9, 2018 at 7:49 PM Chris Jerdonek <chris.jerdo...@gmail.com> 
> wrote:
>> On Tue, Oct 9, 2018 at 7:13 PM Benjamin Peterson <benja...@python.org> wrote:
>> > Can anyone think of a situation where it would be advantageous for an 
>> > implementation to reject non-identifier string kwargs? I can't.
>>
>> One possibility is that it could foreclose certain security bugs from
>> happening. For example, if someone has an API that accepts **kwargs,
>> they might have the mistaken assumption that the keys are identifiers
>> without special characters like ";" etc, and so they could make the
>> mistake of thinking they don't need to escape / sanitize them.
>
>
> Hm, that's not an entirely unreasonable concern. How would an attacker get 
> such keys *into* the dict?

I was just thinking json. It could be a config-file type situation, or
a web API that accepts json.

For example, there are JSON-RPC implementations in Python:
https://pypi.org/project/json-rpc/
that translate json dicts directly into **kwargs:
https://github.com/pavlov99/json-rpc/blob/f1b4e5e96661efd4026cb6143dc3acd75c6c4682/jsonrpc/manager.py#L112

On the server side, the application could be doing something like
assuming that the kwargs are e.g. column names paired with values to
construct a string in SQL or in some other language or format.

--Chris



> One possible scenario would be something that parses a traditional web query 
> string into a dict, passes it down through **kwds, and then turns it back 
> into another query string without proper quoting. But the most common (and 
> easiest) way to turn a dict into a query string is calling urlencode(), which 
> quotes unsafe characters.
>
> I think we needn't rush this (and when in doubt, status quo wins, esp. when 
> there's no BDFL :-).
>
> --
> --Guido van Rossum (python.org/~guido)
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to