OSDir


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Python-Dev] Arbitrary non-identifier string keys when using **kwargs


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:
> > On Tue, Oct 9, 2018, at 17:14, Barry Warsaw wrote:
> > > On Oct 9, 2018, at 16:21, Steven D'Aprano <steve at pearwood.info> wrote:
> > > >
> > > > On Tue, Oct 09, 2018 at 10:26:50AM -0700, Guido van Rossum wrote:
> > > >> My feeling is that limiting it to strings is fine, but checking
> those
> > > >> strings for resembling identifiers is pointless and wasteful.
> > > >
> > > > Sure. The question is, do we have to support uses where people
> > > > intentionally smuggle non-identifier strings as keys via **kwargs?
> > >
> > > I would not be in favor of that.  I think it doesn?t make sense to be
> > > able to smuggle those in via **kwargs when it?s not supported by
> > > Python?s grammar/syntax.
> >
> > 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? 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)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20181009/80527f7f/attachment.html>