Re: utf-8 filenames in phar files.
| From: | Yasuo Ohgaki | Date: | Tue, 22 Apr 2014 02:13:14 +0000 |
| Subject: | Re: utf-8 filenames in phar files. | ||
| References: | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-73759@lists.php.net to get a copy of this message | ||
Hi Stas,
On Tue, Apr 22, 2014 at 8:06 AM, Stas Malyshev <smalyshev@sugarcrm.com>wrote:
> > I have created a quick PR: h¦å4Ùc
> > ÖEÔjw’™Ÿhttps://github.com/php/php-src/pull/649 that
> > is fixing the ill-formed UTF-8 paths.
>
> Thanks for the patch. One thing I'd like to understand is what is the
> added value of being so strict in checking UTF-8. I.e. what would happen
> if we allow some path with weird chars in?
Although invalid encoding would not be security issues by itselves, invalid
encoding
creates various uncertainties. There are/were many ways to use it to
exploit.
e.g. Old browsers had _many_ security issues with ill-formed strings.
One valid example I can think of right now is filter evasion.
http://capec.mitre.org/data/definitions/80.html
Another is DoS. Browsers may refuse to render page at all when there is
ill-formed
strings. e.g. Recent Chrome. Yet another is injections. i.e If user assumes
path name
encoding is UTF-8 and didn't escape, their program could be vulnerable to
injections.
Other programs are getting better to deal with invalid encodings, but
leaving invalid
encoding relies on other programmer's code for proper/safe operations. This
is not good.
Any external inputs that have certain form must be validated where it is
possible.
This way, we would not leave uncertainties/risks.
Regards,
--
Yasuo Ohgaki
yohgaki@ohgaki.net