Hacker News Reader

Comment by coldtea | Hacker News Reader

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)?

Many templates allow accessing fields. There's no risk of SQL injection, you're only echoing the output back to the user.

Didn't you just point out that some of those fields could be sensitive, like password info?

The author discovered this exploit in the template engine he wrote (Jinja2).

I'll consider switching to a different engine.

Perhaps one that hasn't had this exploit fixed yet?

Why would a template engine allow for free access to the native platforms string capabilities in the first place?

Native vs. non-native is irrelevant. A non-native formatting system could have the features of the python formatter that are dangerous. Or, if Python's native formatter lacked these dangerous features, there'd be no reason not to use it.

>Native vs. non-native is irrelevant. A non-native formatting system could have the features of the python formatter that are dangerous.

Hardly irrelevant. The idea is that a non-native formatting system is build specifically for the templating engine, and so the developers controls what it can do and gives it non-dangerous features.

>Or, if Python's native formatter lacked these dangerous features, there'd be no reason not to use it

Even if it did lack them, it's not under the control of the template platform author, so they should not rely on it for such a crucial part of the template engine as string formatting.

(Which is exactly the case here: Python lacked those features before, but got them, and bit the template engine in the back).

> it's not under the control of the template platform author

This doesn't really matter. If it does what you want, it's not like they're going to change the formatter's behavior from under your feet if it's part of the language's default runtime.

While the vuln is there, it's a rather obscure way of using the engine in the first place, so in "good" templates it shouldn't be exploitable. See the example in the release: https://www.palletsprojects.com/blog/jinja-281-released/

Sure, but like tedunangst pointed out, there are valid reasons to allow users to edit those templates, in which case you can't assume they'll be "good".

What does the template engine have to do with SQL? Not really following you there.

A template engine has multiple use cases its author can not foresee, not just creating pages.

Here they talk of using it for translation, with arbitrary user provided strings for example. Another could use it to create an SQL helper (accounting themselves for injection) etc.

In any case, it should not contain dangerous helper methods of capabilities not fit for strictly templating, just because the native string class allows them.

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.

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

In some applications, users can change the their own translations, which are stored in the DB, to allow for easier customization.

Still, no reason to save them in the platforms native string format and with full reign over native strings.

In practice, translators are often externally contracted; the amount of work required to translate any given language is not large enough to make these full-time positions. So only trusted so far.

A lot of folks do use lang format strings for i18n, but they really shouldn't. They won't be able to handle pluralization and other oddities.

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.

Although this only applies to format-string evaluation in Jinja2, which would look something like

    {{ "Hello {user.name}".format(user) }}

which is really kinda obscure, especially since Jinja already has an explicit |format using the very safe / limited (but generally sufficient) alternative %(key)s syntax (also suitable for i18n, to some extend).

Yeah, that was my first thought, too, and it's not very fair to blame Python's new style string format.

Treating user input as a format string has always been a bad idea in every language and library that use them.

Not necessarily true. Type systems can ensure safety without too much effort. For example in Haskell, you might have some sort of format function with the type signature

    -- Given appropriate Error and Context types 
    format :: Context -> Text -> Either Error Text

Which would be guaranteed to be safe (there is no way this function can execute arbitrary code or read from your file system, short of egregious abuses of unsafePerformIO in its implementation). Note that the signature I wrote above takes an explicit context (presumably some sort of mapping of available variables), which removes the need for supporting arbitrary attribute access in the first place, and is more explicit to boot.

There is no reason other languages or libraries could not implement a function with the same degree of safety, although their type systems might not be able to guarantee its safety. In fact I would wager that such pitfalls are only likely to be found in dynamic languages, which support runtime eval (which is, after all, the root of the described problem).

Reply on news.ycombinator.com