5 ms·
The proposed idea of relying on undocumented internals and blacklisting attribute names to securely sandbox formatting strings is _really_ _dangerous_. Never d
by anderskaseorg 10y ago
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.
- tedunangst 10y agoThe first bell added is likely to be field access.
- cyphar 10y agoWhich 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.
- sirclueless 10y agoThe 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.
- anderskaseorg 10y agoRead 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.
- wfunction 10y ago+1 I freaked out when I saw it. Blacklists are just asking to get hacked.