On Tue, Oct 9, 2018 at 8:55 PM Guido van Rossum <guido at python.org> wrote: > On Tue, Oct 9, 2018 at 7:49 PM Chris Jerdonek <chris.jerdonek at gmail.com> wrote: >> On Tue, Oct 9, 2018 at 7:13 PM Benjamin Peterson <benjamin at 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)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4