Re: Resolution for ver_export()/addslashes() encoding based script execution attack?

From: 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 [email protected] to get a copy of this message
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

Thread (20 messages)

« previous php.internals (#72825) next »