Newsgroups: php.internals Path: news.php.net Xref: news.php.net php.internals:72825 Return-Path: Mailing-List: contact internals-help@lists.php.net; run by ezmlm Delivered-To: mailing list internals@lists.php.net Received: (qmail 75761 invoked from network); 26 Feb 2014 12:27:37 -0000 Received: from unknown (HELO lists.php.net) (127.0.0.1) by localhost with SMTP; 26 Feb 2014 12:27:37 -0000 Authentication-Results: pb1.pair.com header.from=lester@lsces.co.uk; sender-id=unknown Authentication-Results: pb1.pair.com smtp.mail=lester@lsces.co.uk; spf=permerror; sender-id=unknown Received-SPF: error (pb1.pair.com: domain lsces.co.uk from 217.147.176.204 cause and error) X-PHP-List-Original-Sender: lester@lsces.co.uk X-Host-Fingerprint: 217.147.176.204 mail4.serversure.net Linux 2.6 Received: from [217.147.176.204] ([217.147.176.204:33943] helo=mail4.serversure.net) by pb1.pair.com (ecelerity 2.1.1.9-wez r(12769M)) with ESMTP id 02/91-01653-7BDDD035 for ; Wed, 26 Feb 2014 07:27:36 -0500 Received: (qmail 23869 invoked by uid 89); 26 Feb 2014 12:27:32 -0000 Received: by simscan 1.3.1 ppid: 23863, pid: 23866, t: 0.0793s scanners: attach: 1.3.1 clamav: 0.96/m:52 Received: from unknown (HELO linux-dev4.lsces.org.uk) (lester@rainbowdigitalmedia.org.uk@81.138.11.136) by mail4.serversure.net with ESMTPA; 26 Feb 2014 12:27:32 -0000 Message-ID: <530DDEC6.9010901@lsces.co.uk> Date: Wed, 26 Feb 2014 12:32:06 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:27.0) Gecko/20100101 Firefox/27.0 SeaMonkey/2.24 MIME-Version: 1.0 To: "internals@lists.php.net" References: <530C3C7B.8080907@sugarcrm.com> <530C77F8.2060809@sugarcrm.com> <1393328380.5233.45.camel@guybrush> <530DADC7.2070302@lsces.co.uk> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [PHP-DEV] Resolution for ver_export()/addslashes() encoding based script execution attack? From: lester@lsces.co.uk (Lester Caine) Yasuo Ohgaki wrote: > As you know, all databases' escaping functions have encoding parameter. > PostgreSQL uses encoding parameter stored in db connection structure. This > is the reason why pg_escape_string() has optional database base connection > parameter for escaping. > > > On the whole any database access I'm doing with Firebird is done using > parameters which are handled in the database connection rather than having > to worry about many of these sorts of 'protections'. The result for me is > that I don't have to worry about many of the problems the more lax handling > of data in MySQL can create. But the more important thing here is that I've > not used a 'locale' other than UTF8 for websites for many years and so the > whole underlying structure needs fixing rather than trying to patch small > areas that are better handled by doing the job correctly in the first place! > > > We cannot force users to use Unicode for database/file/etc ;) > I'm not proposing use of locale, but new escape API that support multibyte > encoding. My point Yasuo is that I think the reason this has been rejected is simply because there needs to be a more comprehensive review of how 'multi_byte' characters are handled? There needs to be at least some agreement moving forward if PHP should be made fully UTF-8 complaint or the alternative 'ASCII only' for code, so that perhaps 'mb_' SHOULD be the only way to handle multi byte strings? Short term fixes are just exacerbating the real problem? Also I don't see how the RFC addressed the problem anyway. While I use UTF-8 output exclusively I've not had to resort to mbstring extension to do so yet so would not even use the extra functions in normal production. -- Lester Caine - G8HFL ----------------------------- Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk Rainbow Digital Media - http://rainbowdigitalmedia.co.uk