Re: utf-8 filenames in phar files.

From: 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

« previous php.internals (#73759) next »