Re: Resolution for ver_export()/addslashes() encoding based script execution attack?
| From: | Lester Caine | Date: | Wed, 26 Feb 2014 12:32:06 +0000 |
| Subject: | Re: Resolution for ver_export()/addslashes() encoding based script execution attack? | ||
| References: | 1 2 3 4 5 6 7 8 9 10 | Groups: | php.internals |
| Request: | Send a blank email to internals+get-72825@lists.php.net to get a copy of this message | ||
Yasuo Ohgaki wrote:
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.ukAs 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.