I agree about this, but a more simpler interface would be a multiuse interface that suits most usages of user-supplied data. And that is to give a very simple "filter" interface that will filter out all invalid characters and also untaint the data.
Like: ${filter{$data_to_be_filtered}{<permitted_characters>}} <permitted_characters> is NOT expanded, meaning only character that needs to be escaped in that circumstance is { and }. Example: ${filter{$phonenumber}{0123456789}} Would simply strip all characters except 0-9 from $phonenumber and return in untainted form, so if $phonenumber contains "hey0do56" then ${filter{$phonenumber}{0123456789}} will return 056 Of course, the function ${filter must then be built in such a way its 100% safe to use, basically theres nothing a untrusted user could do to cause ${filter to return any character outside of the administrator-configured filter list. Of course you could supply a "unsafe" list of characters, but thats the system administrator's responsibility. So instead of separate functions check_file_path or check_sql_data etc, its better to have one function, that can be administrator-configured to allow arbitary filtering, which also could be used in other situations where you want to filter user-supplied data from unwanted characters, even for functions that do allow tainted data. And the best with such ${filter function is that it will never throw any exceptions or fail, it will just filter out whatever danger is supplied. Of course, if admin wants it to throw exception in case of unpermitted characters, its easy for system administrator to do a string compare before and after the filter function, and err out if they don't match (meaning, something got filtered out). And in the rare cases you want to filter out certain character sequences, its easy to, before the filter function, do a sg{} and replace all unwanted sequences with a character outside the permitted space, and then run the filter function. -----Ursprungligt meddelande----- Från: Evgeniy Berdnikov via Exim-users <exim-users@exim.org> Skickat: den 26 juni 2020 23:12 Till: exim-users@exim.org Ämne: Re: [exim] de-tainting Hello. On Thu, Jun 25, 2020 at 09:16:59PM +0100, Jeremy Harris via Exim-users wrote: > On 25/06/2020 20:50, Evgeniy Berdnikov via Exim-users wrote: > > at least in statement "In all other situations, this variable > > expands to nothing", because it may be filled if no lookup is done. > > Yes, that is no longer true. See the sections starting > > http://exim.org/exim-html-current/doc/html/spec_html/ch-domain_host_ad > dress_and_local_part_lists.html#SECTlistresults Referenced text have broken record about 'domains' match, I expect some words about $domain_data variable. Hope you'll supply them. And I have question about user interface, which becomes very obscure and inconvenient. All these innovations with tainting bring problems. In some cases they may be "resolved" by lookups. Obviously, the idea is to restrict file name patterns to some predefined set of strings, stored somewhere in database, in hope that this set would be less risky then data from the wild. Well, it seems good on first glance. But many users want to use file system as native database with data-driven records, i.e. with file names constructed from $local_part, $domain, $sender_host and other variables that can't be predicted. They can't be expressed as a set of predefined strings. Is there any effective solution for this case? I can propose awful "untainting" algorithm: 1. construct a tainted string, 2. put it into database, 3. make lookup to get back "untainted" data. Any protection against "../" inside, or against SQL injection will be dropped, but it allows construction of arbitrary untainted strings with minimum efforts. And I'm sure that samples of such "untainting functions" became available in internet if Exim's interface continue to evolve in direction of obscurity and inconveniece. In my opinion, in order to give an effective tool for data protection, one should supply simple and copletely "intuitive" interface. For files it may be a function, say, ${check_file_path:...}, which checks its argument for dangerous patterns (such as "../") and specials, then returns untainted copy of string if everything is OK, or throws an exception. For SQL such function may be ${check_sql_data:...}. Moreover, it seems better to add such functionality to existing quoting functions: ${qoute_ldap:...}, ${quote_mysql:...}, etc. Jeremy, I kindly propose to think about movement in this direction. You have done a really great work, but for the present its result is too complex and too restrictive for use. If you don't supply simple and convenient interface, Exim would lose its main advantage, power of built-in scripting language, and inavitably lose its users. IMHO. -- Eugene Berdnikov -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
smime.p7s
Description: S/MIME Cryptographic Signature
-- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/