Re: [PHP-DEV] Providing sandboxed versions of include and require language constructs
2012/3/7 Ángel González keis...@gmail.com
On 07/03/12 00:04, Adam Jon Richardson wrote:
It would be the responsibility of the framework or CMS or application
to protect against this type of attack (which they do quite well.)
When you can force a plugin to work through your API, you can take
appropriate measures. When the plugin can avoid working through, say,
a file API that protects against misuse by using the internal file
functions, this is a much more difficult issue to mitigate.
The key point is precisely, how do you ensure they can only call your API?
The idea would be to have a default whitelist of internal functions that
can be easily expanded per include as needed. That way, the script
including another script can determine how much power/trust they're willing
to hand off.
For example:
// EXAMPLE 1: included script would only be able to call functions found in
default whitelist
include_restricted('file/path1');
// EXAMPLE 2: included script would only be able to call functions found in
default whitelist and PDO
include_restricted('file/path2', $whitelist = array(SANDBOX_PDO));
The types of restrictions that involve restricting calls to internal
functions (e.g., file()) are, at least conceptually, is straight forward.
However, PDO has an object interface. For objects, I'm researching the idea
of limiting the creation of new objects within the included script. That is
to say that in example 1, the included script would raise an error if it
tried to create a PDO object directly.
However, in some situations, the framework or CMS may hand off a PDO object
to the included script or expose a factory API (maybe the intent is to
share a DB connection), and in this case, the sandbox would allow the PDO
object to be utilized within the script. The idea is for the framework/CMS
to be the gatekeeper for all of the applications resources, and if the
framework designers want to hand off an object for use, then that fits with
the general model I'm proposing.
Right now, it's very difficult to enforce any restrictions on included
scripts because they have access to all of the internal functions available
to the framework/CMS (using something like the disable_functions directive
limits the framework/CMS too much and works from a blacklist approach.)
I'm not saying this would be easy to implement, or that it would be
perfectly secure. I am saying that it's worth careful examination and that
there are many potential solutions that could make things better in terms
of application security.
Thanks for the feedback,
Adam
Re: [PHP-DEV] Release process nit
On Mon, Mar 12, 2012 at 23:11, Christopher Jones christopher.jo...@oracle.com wrote: The autom4te.cache and *.orig files originally mentioned are included in php.net's php-5.4.0.tar.bz2 I.e. this is a valid issue. Ondřej, please log a bug. https://bugs.php.net/bug.php?id=61368 O. -- Ondřej Surý ond...@sury.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] CURL file posting
We could add a flag to disable the @ usage but I'm against having the '@' usage disabled by default. This BC break would be in my opinion too big. An other solution would be to have something like (We will also have to add the type and filename support to this solution so this is just a first proposal) : curl_setopt($curl_handle, CURLOPT_HTTPPOSTFIELDS, array( 'firstname' = 'pierrick', 'lastname' = array(CURL_FORMSTR, 'charron'), 'lastname' = array(CURL_FORMFILE, '/home/pierrick/picture.png') ); Pierrick Otherwise the safest way for people is to use http_build_query on their parameter array. Pierrick On 11 March 2012 19:29, Stas Malyshev smalys...@sugarcrm.com wrote: Hi! I'd sure like a PHP extension that didn't have this obvious and nasty bug: https://bugs.php.net/bug.php?id=46439 This doesn't look good. Documentation does say the @ prefix exists, but it has very high potential of creating security holes for unsuspecting people. open_basedir would help limit the impact, but still it's not a good thing. Any ideas on fixing it without breaking the BC? -- Stanislav Malyshev, Software Architect SugarCRM: http://www.sugarcrm.com/ (408)454-6900 ext. 227 -- 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
Re: [PHP-DEV] default charset confusion
Am 13.03.2012, 02:34 Uhr, schrieb Rasmus Lerdorf ras...@lerdorf.com: On 03/12/2012 05:52 PM, Yasuo Ohgaki wrote: I always set all parameters for htmlentities/htmlspecialchars, therefore I haven't noticed this was changed from 5.3. They may be migrating from 5.2 or older. (RHEL5 uses 5.1) No, like I showed, moving from 5.3 to 5.4 breaks because the new default UTF-8 encoding validates the input and 8859-1 in 5.3 does not. So for charsets that are actually safe for the low-ascii chars that are significant to html htmlspecialchars() now returns false in 5.4 because their chars fail the UTF8 validity check. For people who explicitly set all the parameters nothing has changed, of course. I second that. It causes us big PITA because we're still using 8859-1 (shame on us) and it is made even worse because the encoding parameter is after the (optional) flags parameter which now has to be given too. The sane version from my naive point of view would be to honor default_charset if nothing is given. That's what I expected when I read the migration guide. - Chris -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] default charset confusion
On Mon, March 12, 2012 2:44 pm, Rasmus Lerdorf wrote: But you can't necessarily hardcode the encoding if you are writing portable code. That's a bit like hardcoding a timezone. In order to write portable code you need to give people the ability to localize it. If you wanted it portable, wouldn't you need to have a variable there, so it can survive the ISO-8859-1 to UTF-8 change, and to allow people to change it despite whatever non-standard setting might happen to be in somebody else's php.ini? I mean, sure, it's nice if it just works for the folks who want to install and have it localized for their own charset hard-coded in php.ini, but if it's being multi-national website, you have to pass in a variable there, which seems the more portable option to this naive reader. Having it default to whatever happens to be in php.ini only solves the use case of people who only want to serve up their content in their own charset. I'd have to agree with Stas that everybody should start passing in a variable there, that can be set somewhere in a config, or, perhaps, would DEFAULT to, e... You can't default to a function call. ANOTHER magic constant like __INI_CHARSET__ ??? That's probably a bad idea... -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Git Migration: Status Update
On Wed, March 7, 2012 1:51 pm, Sebastian Bergmann wrote: Am 07.03.2012 19:46, schrieb Kris Craig: As I and others have said already, using a Subversion branching model on Git just doesn't make any sense. How often does it have to be explained to you and others that we would like to do this step by step? First we change the tool, then we change the process. Shouldn't be too hard to understand ... Maybe it's just me, but if I told my boss we were going to change the tool and decide and document the fundamental business processes later, I don't think that would float... That said, I still can't get my head around Git at all, and so far have only managed to checkout/update on a read-only basis. Not that it matters. My code contributions to PHP have been nil so far anyway. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Re: Git Migration: Status Update
+1 Git can be confusing for seasoned Subversion developers at first, as it really is a fundamental paradigm shift in many respects. I'm not sure why you're only able to do read-only access, though. The add/commit syntax for Git is fairly similar to that of SVN. Have you tried creating a dummy repo locally and making commits to that? I'm not privy to the latest on the Git migration project, but it could just be a Git and/or FSO permissions issue on the remote origin. --Kris On Tue, Mar 13, 2012 at 8:18 AM, Richard Lynch c...@l-i-e.com wrote: On Wed, March 7, 2012 1:51 pm, Sebastian Bergmann wrote: Am 07.03.2012 19:46, schrieb Kris Craig: As I and others have said already, using a Subversion branching model on Git just doesn't make any sense. How often does it have to be explained to you and others that we would like to do this step by step? First we change the tool, then we change the process. Shouldn't be too hard to understand ... Maybe it's just me, but if I told my boss we were going to change the tool and decide and document the fundamental business processes later, I don't think that would float... That said, I still can't get my head around Git at all, and so far have only managed to checkout/update on a read-only basis. Not that it matters. My code contributions to PHP have been nil so far anyway. -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] default charset confusion
2012.03.13 16:38 Richard Lynch rašė: I'd have to agree with Stas that everybody should start passing in a variable there, that can be set somewhere in a config, or, perhaps, would DEFAULT to, e... You do realize that suggestions on this thread and original bug reporter failed to make correct decisions about values that should be used to migrate original function to PHP 5.4 compatible syntax? htmlspecialchars without arguments does not default to ENT_QUOTES or NULL. Failure to choose proper second argument value will lead to different exploit or data corruption. You can't default to a function call. Changing default in function was bad idea. Ignoring bug reports about fed up documentation and closing them with bogus explanations might not be bad idea, but it really helps in alienating your developer base. -- Tomas -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEADS UP: 5.4 branch is open again
On Fri, March 2, 2012 4:26 am, Ferenc Kovacs wrote: If we can agree upon the next version number beforehand, and we decide that we will go with the major release (be that php 6 or 7, whatever), we don't to do anything right now, we can branch the version from trunk/master, when the time comes. If we can't agree upon the next version number, or we agree upon that there will be an 5.5 version, I think it would make sense to create a branch for it ASAP, so there is place (trunk/master) for the approved but backward incompatible changes, and people don't have to hold patches. What do you think? If I was in charge, and thankfully I'm not, I'd just create 5.5 and 6.0 If you have patches that don't break BC, put them in both. If you're too busy to do both, put it in 6.0 Somebody will back-port or not, based on their relative need/availability or not. If it breaks BC, put it in 6.0 Or perhaps I misunderstand the tiny bit I thought I got it of the point of using Git in the first place... Branches and merges are supposed to be seamless, right??? -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] HEADS UP: 5.4 branch is open again
Yes, IF you're using a proper branching model. If you're just using it the same way you'd use Subversion, which currently is the direction we seem to be moving in, those advantages are mostly negated. I agree that PHP 5.5 (and maybe even 5.6, etc) should come before PHP 6. That being said, at some point a parallel development workflow might be prudent IMHO, but even that would be a ways off I think. --Kris On Tue, Mar 13, 2012 at 11:55 AM, Richard Lynch c...@l-i-e.com wrote: On Fri, March 2, 2012 4:26 am, Ferenc Kovacs wrote: If we can agree upon the next version number beforehand, and we decide that we will go with the major release (be that php 6 or 7, whatever), we don't to do anything right now, we can branch the version from trunk/master, when the time comes. If we can't agree upon the next version number, or we agree upon that there will be an 5.5 version, I think it would make sense to create a branch for it ASAP, so there is place (trunk/master) for the approved but backward incompatible changes, and people don't have to hold patches. What do you think? If I was in charge, and thankfully I'm not, I'd just create 5.5 and 6.0 If you have patches that don't break BC, put them in both. If you're too busy to do both, put it in 6.0 Somebody will back-port or not, based on their relative need/availability or not. If it breaks BC, put it in 6.0 Or perhaps I misunderstand the tiny bit I thought I got it of the point of using Git in the first place... Branches and merges are supposed to be seamless, right??? -- brain cancer update: http://richardlynch.blogspot.com/search/label/brain%20tumor Donate: https://www.paypal.com/cgi-bin/webscr?cmd=_s-xclickhosted_button_id=FS9NLTNEEKWBE -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
