Hacker News new | past | comments | ask | show | jobs | submit login

The proposed idea of relying on undocumented internals and blacklisting attribute names to securely sandbox formatting strings is _really_ _dangerous_. Never do that in production code! Language expansions could render your sandbox unsafe at any time.

You can write your own safe formatting engine in much less code.

    def safe_format(fmt, **args):
        return re.sub(r'\{([^{}]*)\}', lambda m: args.get(m.group(1)), fmt)
    safe_format('{foo} {bar}', foo='Hello', bar='world')  # Hello world
Add bells and whistles as desired.

+1 I freaked out when I saw it. Blacklists are just asking to get hacked.

The first bell added is likely to be field access.

Which immediately becomes a security risk because classes can overload __getattr__ and __getitem__. So now you're executing random code.

Of course, %s does the same thing (__str__) but at least %s doesn't take any arguments.

The assumption behind string.format and friends is that people who override __getattr__ and __getitem__ know what they're doing. Which is probably a reasonably safe tradeoff in order to allow attribute access.

I'm not worried about executing arbitrary code, because it's not user-supplied and it's normal for a templating library to access attributes of objects you pass to it (if it was unsafe you shouldn't have done that). This is more of a snafu with the number of sensitive and powerful attributes available by default on Python objects.

Read the article. The danger is not __getattr__ and __getitem__ but rather things like event.__init__.__globals__[CONFIG][SECRET_KEY]. There is no such thing as an object where arbitrary attribute access is safe, because every object has a constructor function and every function references the globals dict.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact