Re: [RFC] Multibyte char handling

Hi Nikita, On Thu, Jan 16, 2014 at 9:18 PM, Nikita Popov <nikita.ppv@gmail.com> wrote: > On Thu, Jan 16, 2014 at 12:50 AM, Yasuo Ohgaki <yohgaki@ohgaki.net> wrote: > >> Hi all, >> >> addslashes() could be vulnerable via char encoding based attacks. >> It is needed to decide what counter measure we adopt. >> This is RFC for this issue. >> >> https://wiki.php.net/multibyte_char_handling >> >> Please comment. >> Thank you. >> > > Please do *not* add encoding parameters to our existing string functions - > we have an mb extension and mb functionality should go there. Don't mix the > things, it will only lead to a lot of confusion. Right now it's obvious > which functions handle encoding how, no need to break that. > This discussion circulate discussion. At first, I proposed locale based solution using php_mblen(). This approach does not require additional encoding parameter since encoding is specified by locale. However, some people don't like the solution (in security ML) because it is locale based solution. It may have unwanted side effects. Locale is unreliable and most user just don't care about it. Therefore, I proposed this approach that introduce encoding parameter just like htmlspecialchars()/htmlentities(). Encoding parameter (or some way to specify encoding) for security related string function is mandatory. We should provide some way to specify encoding. Do you like locale based approach for now? Regards, -- Yasuo Ohgaki yohgaki@ohgaki.net