Hi Nikita,
On Thu, Jan 16, 2014 at 9:18 PM, Nikita Popov <[email protected]> wrote:
> On Thu, Jan 16, 2014 at 12:50 AM, Yasuo Ohgaki <[email protected]> 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
[email protected]