Live data from Hacker News

Be Careful with Python's New-Style String Format

lucumr.pocoo.org

11–20 of 155 posts

Re: Be Careful with Python's New-Style String Format

#11
post #4

Err, why would you allow for the user to enter arbitrary format strings in the first place? Might as well write "be careful about eval of arbitrary user provided strings".

Internationalization, usually. Word order differs between languages, and this kind of format allows reordering the inserted values.

Re: Be Careful with Python's New-Style String Format

#12
post #4

Err, why would you allow for the user to enter arbitrary format strings in the first place? Might as well write "be careful about eval of arbitrary user provided strings".

Templates. Very useful in many places.

Although if you are using templates in Python, you are likely using jinja2. And they just "fixed" the bug. So you are good to go if your upgrade.

Re: Be Careful with Python's New-Style String Format

#13
post #5

I do love writing python, but it's pretty shocking when I find out you can write something like `event.__init__.__globals__[CONFIG][SECRET_KEY]`. That language just does not care about privacy or information hiding at all, I guess.

You can do the same thing in Java with reflection.

Don't let users run untrusted code. Full stop.

If you need templating use a sandbox like jinja2.

Re: Be Careful with Python's New-Style String Format

#15
post #11
post #4

Err, why would you allow for the user to enter arbitrary format strings in the first place? Might as well write "be careful about eval of arbitrary user provided strings".

Internationalization, usually. Word order differs between languages, and this kind of format allows reordering the inserted values.

Internationalization should never use arbitrary string or system level formatting.

Look at MessageFormat or L20n. Yeah, I know that it's more complex than what you think you need (I've hear the "let's just use JS template literals" so many times) but you actually do.

Re: Be Careful with Python's New-Style String Format

#16
post #11
post #4

Err, why would you allow for the user to enter arbitrary format strings in the first place? Might as well write "be careful about eval of arbitrary user provided strings".

Internationalization, usually. Word order differs between languages, and this kind of format allows reordering the inserted values.

Yes, but that's meant for trusted translators of the UI, nor arbitrary users, right?

Re: Be Careful with Python's New-Style String Format

#17
post #9

No, Rust does not have the ability to access any variable in the program via a format string. Rust has this: format!("{argument}", argument = "test"); // => "test" That's just named arguments to the format. Also, that's a macro; it's expanded at compile time. Python's approach is lame. It should have used something with a limited list of named arguments, or maybe a dict.

Neither does python.

The problem being discussed here is that the format string can access and attribute of the object passed in. From PEP3101 [0]:

" Unlike some other programming languages, you cannot embed arbitrary expressions in format strings. This is by design - the types of expressions that you can use is deliberately limited. Only two operators are supported: the '.' (getattr) operator, and the '[]' (getitem) operator. The reason for allowing these operators is that they don't normally have side effects in non-pathological code."

[0] https://www.python.org/dev/peps/pep-3101/

Re: Be Careful with Python's New-Style String Format

#18
post #4

Err, why would you allow for the user to enter arbitrary format strings in the first place? Might as well write "be careful about eval of arbitrary user provided strings".

"Customize the look of your blog by editing these templates."

Shouldn't that be based not on the built-in string capabilities, but on a template engine, that must also take care for much more narrow cases of abuse (e.g. SQL injection, or access to only of a restricted number of helper functions within the template)?

Re: Be Careful with Python's New-Style String Format

#19
Maybe a more fully worked example is needed. You're making a blog hosting service as a service service. Bloggers have different ideas about what page titles should be.

    Post Title
    Blog Name: Post Title
    Blog Name - Post Title
    Post Title - Blog Name
    Blog Name ----embdash---- Post Title
    ~~~ xXx Post Title xXx ~~~
It's a little overwhelming to put every possibility in a dropdown, so you allow the user to specify a format string.

    title = userformats.title.fmt(post)
This doesn't look so very dangerous. And then the user can say

    "{post.title} - {post.blog.title}"
    "{post.title}: Another fine post by "{post.author}"
    "~~~ xXx {post.blog.__init__.dbconnection.__keys__.password} xXx ~~~"
And then oops.

Re: Be Careful with Python's New-Style String Format

#20
post #9

No, Rust does not have the ability to access any variable in the program via a format string. Rust has this: format!("{argument}", argument = "test"); // => "test" That's just named arguments to the format. Also, that's a macro; it's expanded at compile time. Python's approach is lame. It should have used something with a limited list of named arguments, or maybe a dict.

Also, in C# the string interpolation works only on literal strings at compile time. So it's not possible to inject a malicious code this way from outside of the source code.
Post reply on HN