On 30 Jul 2015, at 13:47, Xinchen Hui <larue...@php.net> wrote: > anyway, with PHP7's new zend_string, and string flags, the > implementation will become easier.
Hi Xinchen, Glad to hear that you are still looking into this... please let me know if there is anything I can do to help (unfortunately I'm not a C programer). Out of interest, if you are going to continue using "taint_marks", as the RFC suggested... can I suggest all variables start with 0 (or undefined)... then you can set flags as the variables are passed though functions like htmlentities and pg_escape_literal? This way all variables are treated as plain (unsafe), and then developers either need to escape them (e.g. when printing to output, or using in SQL, CLI, etc), or they can mark them as having already been escaped (rare). Likewise, I know you have examples that say "SCRIPT_FILENAME" is safe by default (I kind of disagree)... it would still be advisable to encode them, even if they are being included in the HTML... personally I would not have any variables marked as safe by default (with the single exception of strings that are defined in the PHP code itself). Craig On 30 Jul 2015, at 13:47, Xinchen Hui <larue...@php.net> wrote: > Hey: > > On Thu, Jul 30, 2015 at 8:14 PM, Joe Watkins <pthre...@pthreads.org> wrote: >> I find myself agreeing with Pierre; The wrong signal would be sent. History >> should teach us there is no such thing as (a) safe mode. >> >> Xinchen did used to work on a taint extension, I wonder why that was >> stopped ? > yes, it is https://github.com/laruence/php-taint > > Anyway, I was too busy so I didn't make it supports PHP-5.6, I was > hoping someone could help(it supports 5.5 now). > > it is a complex extension, and using tricky way to keep taint infos > > anyway, with PHP7's new zend_string, and string flags, the > implementation will become easier. > > I have a plan to make it supports PHP7.. > > thanks >> >> Worth noticing that the extension is rather complex, touching many parts of >> the engine, changing many things ... which I don't really like. >> >> Cheers >> Joe >> >> On Thu, Jul 30, 2015 at 10:14 AM, Craig Francis <cr...@craigfrancis.co.uk> >> wrote: >> >>> On 30 Jul 2015, at 08:24, Lester Caine <les...@lsces.co.uk> wrote: >>> >>>> But that is a perfect example of what I am talking about. You do not >>>> educate people by publishing the very thing that is wrong. You educate >>>> them by pointing out to them WHY the '?' was there in the first place. >>> >>> >>> >>> >>> I completely agree on education, and what I'm hoping for... and this is >>> how we can educate everyone :-) >>> >>> My suggestion for taints (not quite the same as the one from Matt or >>> Wietse) was not to change the way good programs are created/executed, but >>> simply an education device, which can also pick up mistakes that >>> experienced developers make. >>> >>> While my first post on this mailing list gives a better overview: >>> >>> http://news.php.net/php.internals/87207 >>> >>> The original implementation suggestion is at: >>> >>> https://bugs.php.net/bug.php?id=69886 >>> >>> You will see that it does nothing more than create notices to say "erm, do >>> you want to be doing this?". >>> >>> This is something that only PHP can do, unless you can find a way of >>> changing every single article / code example on the internet :-) >>> >>> So, with your example... if you want to use a variable for a table/field >>> prefix, that is perfectly fine... in fact, it won't need any changes, as >>> the prefix will probably be hard coded as a string within a PHP script >>> (something I called ETYPE_CONSTANT). >>> >>> But if not (e.g. storing the prefix in an ini file?), then I've shown an >>> example of how that can be handled with the proposed "string_encoding_set" >>> function (something I should have probably called string_escaping_set)... >>> which is simply to tell PHP that this one variable is already safe >>> (something I can't see being needed very often). >>> >>> Craig >>> >>> >>> >>> >>> >>> On 30 Jul 2015, at 08:24, Lester Caine <les...@lsces.co.uk> wrote: >>> >>>> On 29/07/15 16:11, Craig Francis wrote: >>>>> I completely disagree... prepared statements are just as vulnerable, >>> and so are ORM's. >>>>> >>>>> You can push developers towards these solutions, and that would be >>> good, but you are completely blind if you think an uneducated developer >>> won't do: >>>>> >>>>> if ($stmt = $mysqli->prepare("SELECT District FROM City WHERE >>> Name=" . $_GET['name'])) { >>>>> } >>>> >>>> But that is a perfect example of what I am talking about. You do not >>>> educate people by publishing the very thing that is wrong. You educate >>>> them by pointing out to them WHY the '?' was there in the first place. >>>> >>>> Since the taint extension only covers mysql and sqlite it's of little >>>> use if we manage to convert 'uneducated developer' to any of the more >>>> secure databases, and that was one of the reasons why mysql was dropped >>>> from being loaded by default. Once one starts from a base of >>>> parametrised sql queries the lax programming methods many mysql guides >>>> and books continue to push can be reversed. Throwing more bloat into php >>>> to create 'WTF' errors just adds to a new users frustration and annoys >>>> experienced users who have very good reasons for building queries using >>>> clean variables. MANY abstraction layers use variables to add prefixes >>>> to table names or fields. >>>> >>>> Educate ... don't nanny ... >>>> >>>> -- >>>> 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 >>>> >>>> -- >>>> PHP Internals - PHP Runtime Development Mailing List >>>> To unsubscribe, visit: http://www.php.net/unsub.php >>>> >>> >>> >>> -- >>> PHP Internals - PHP Runtime Development Mailing List >>> To unsubscribe, visit: http://www.php.net/unsub.php >>> >>> > > > > -- > Xinchen Hui > @Laruence > http://www.laruence.com/ -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
