Looking for more information on how to do PHP the right way? Check out PHP: The Right Way

Nikola Poša:
Using DIC the right way
Sep 05, 2017 @ 15:24:31

In a new post to his site Nikola Poša looks at dependency injection containers and shares what he thinks is the right way to use them in your applications.

DIC stands for Dependency Injection Container, which is a tool that manages the construction and wiring up of application services. It closely relates to the letter "D" of a SOLID acronym - Dependency Inversion Principle and is employed to facilitate adhering to the principle.

By their nature, DI Containers are also Service Locator implementations, design pattern that is the exact opposite to Dependency Injection. Because of that, DI Container is a double-edged sword which can mislead you if not used wisely, and ironically bring your code into a state in which there is no dependency injection at all.

He starts off by talking about two kinds of code in an application: core versus assembly. In this case "core" code is the piece of the application that are then used by "assembly" code to make things happen. He suggests that the DIC shouldn't leak into the core and should be put behind a separation between the core code and assembly code. He includes some sample code illustrating what he means and the idea of splitting out the DIC configuration to help that layer clean.

tagged: dependency injection container tutorial core assembly code abstraction leak

Link: http://blog.nikolaposa.in.rs/2017/09/03/using-dic-the-right-way/

Mattias Geniar:
Mitigating PHP’s long standing issue with OPCache leaking sensitive data
Feb 28, 2017 @ 17:39:33

In a new post to his site Mattias Geniar looks at an old security issue in PHP, opcache information leakage and how to mitigating the issue.

A very old security vulnerability has been fixed in PHP regarding the way it handles its OPCaches in environments where a single master process shares multiple PHP-FPM pools. This is the most common way to run PHP nowadays and might affect you, too.

He starts by talking about the vulnerability itself, that the PHP process doesn't validate the userid when fetching cached bytecode. This could result in information from other operations/scripts being exposed to other processes in a PHP-FPM pool. His solution? Upgrade PHP (the bug is fixed back in PHP 5.6.5) and set a few additional opcache ini settings to enforce the validation. Besides 5.6.29, it was also corrected in the PHP 7 releases (7.0.14 and 7.1.0). The post then talks about the potential exploit - an indirect local privilege escalation to root where the shared memory is read and access to outside information is possible.

tagged: opcache bytecode security issue leak sensitive information mitigation

Link: https://ma.ttias.be/mitigating-phps-long-standing-issue-opcache-leaking-sensitive-data/

Antony Dovgal's Blog:
locating memory hungry code with memtrack
Jan 28, 2009 @ 17:19:18

Sometimes finding that one spot in your code that's geting bloated and consuming at majority of your memory can be a bit difficult. Antony Dovgal has proposed one solution in a new post to his blog - the memtrack extension for from PECL.

We needed to locate where most of the memory is allocated in our scripts (as some of them became too memory hungry), so I've created memtrack extension. This extension helps us to see unusually big memory allocations in production code.

The extension logs memory usage information out to the standard error log file (however that'd defined on your system) and comes with a few configuration options. These let you control things like a "soft limit" at which to report the usage problems, the ability to ignore certain functions that you might know will cause a high load and and "vm_limit" setting that can help if your script is leaking memory at the end of its run.

tagged: memory leak memtrack pecl extension bloat problem

Link:

SitePoint PHP Blog:
Dealing with Dependencies
Feb 04, 2008 @ 18:09:00

On the SitePoint PHP blog today, Troels Knak-Nielsen has written up an article that talks about dependencies in your applications - those little interconnections your code relies on to do more with less.

In lack of better words, I'll call this compositional programming style. It's a style which is usually more prevalent with experienced programmers. [...] There is, however, a dark side to composition — dependencies.

He starts with a definition to bring everyone up to a level field then moves on to how their used (through a "global symbol" or directly passed in) and how they can "leak" if you're not careful.

To help protect you and your code from any kind of damage down the line, Troels suggests making a container to keep objects where they need to be. He even includes an example with namespace support to make things even easier down the road.

tagged: dependencies tutorial compositional programming container leak namespace

Link:

Christopher Jones' Blog:
Temporary LOBS in PHP's OCI8 Extension. Instant Client.
Jan 21, 2008 @ 18:05:00

Christopher Jones talks today on his blog about a bug he's just corrected and integrated into the release of the Oracle Instant Client that lets PHP correctly take advantage of the temporary LOBS functionality.

When PHP is done with the temporary LOB, it needs to tell Oracle to destroy it. If this isn't done, then the temporary LOB will hang around using DB space until the connection is closed. I just merged a fix worked on by Krishna Mohan and myself for bug 43497.

Example code is included showing two instances of its use - a normal use that frees the memory correctly and the other showing how to create the temporary lob to hold the data as needed.

tagged: temporary lob patch oci8 extension instant client memory leak

Link:

Paul Jones' Blog:
Memory Leaks With Objects in PHP 5
Sep 28, 2007 @ 13:46:00

Paul Jones presents a problem he was having in a new post to his blog - the issue was with memory leaks in objects in a PHP5 application he was working on.

One of the nice things about using a scripting language is that it automates garbage collection for you. You don't have to worry about releasing memory when you’re done with your variables. [...] But there is at least one circumstance in which PHP will not free memory for you when you call unset(). Cf. http://bugs.php.net/bug.php?id=33595.

The problem is that, when trying to unset the parent object in a parent/child relationship, the memory space for the parent reference in the child isn't removed. The problem, left unchecked can cause a script to go over the memory limit pretty easily (especially with larger objects).

He suggests two solutions - one that the user can control (calling a destructor before unsetting the object) or a PHP internals method that involves fixing issues with the reference counts created with the objects.

tagged: memory leak object php5 reference parent child release memory leak object php5 reference parent child release

Link:

Paul Jones' Blog:
Memory Leaks With Objects in PHP 5
Sep 28, 2007 @ 13:46:00

Paul Jones presents a problem he was having in a new post to his blog - the issue was with memory leaks in objects in a PHP5 application he was working on.

One of the nice things about using a scripting language is that it automates garbage collection for you. You don't have to worry about releasing memory when you’re done with your variables. [...] But there is at least one circumstance in which PHP will not free memory for you when you call unset(). Cf. http://bugs.php.net/bug.php?id=33595.

The problem is that, when trying to unset the parent object in a parent/child relationship, the memory space for the parent reference in the child isn't removed. The problem, left unchecked can cause a script to go over the memory limit pretty easily (especially with larger objects).

He suggests two solutions - one that the user can control (calling a destructor before unsetting the object) or a PHP internals method that involves fixing issues with the reference counts created with the objects.

tagged: memory leak object php5 reference parent child release memory leak object php5 reference parent child release

Link:

Community News:
Facebook PHP Source Leaked
Aug 13, 2007 @ 12:56:00

As many people noted in the past few days, there was a code leak over on Facebook.com. Some of the PHP code that runs the website was exposed as plain text to viewers. Unfortunately, several people are blaming PHP as the source of the issue including Nik Cubrilovic, a writer for TechCrunch:

I just posted on TC about the Facebook code leak. PHP has always been notorious for sometimes not processing requests poorly and sending back the source code for pages to the client. Because of the way mod_php works with apache, if mod_php fails in intercepting and processing the request, then apache will just serve it back to the client as an ordinary text file.

Of course, the PHP community is speaking back to the allegations including Clay Loveless in a new blog entry on his site:

I agree with Cubrilovic that the inadvertent delivery of source code instead of the result of that source code is certainly a horrific situation, with potentially serious ramifications for any company that experiences such a problem on a large scale basis. [...] Unfortunately, the updates appended to the article imply that PHP is somehow responsible for this leakage.

He supports some of the issues (a server misconfiguration could cause odd behavior) but refutes others (the "known issue" of PHP pushing out source code under high load).

tagged: facebook source leak server misconfigure facebook source leak server misconfigure

Link:

Community News:
Facebook PHP Source Leaked
Aug 13, 2007 @ 12:56:00

As many people noted in the past few days, there was a code leak over on Facebook.com. Some of the PHP code that runs the website was exposed as plain text to viewers. Unfortunately, several people are blaming PHP as the source of the issue including Nik Cubrilovic, a writer for TechCrunch:

I just posted on TC about the Facebook code leak. PHP has always been notorious for sometimes not processing requests poorly and sending back the source code for pages to the client. Because of the way mod_php works with apache, if mod_php fails in intercepting and processing the request, then apache will just serve it back to the client as an ordinary text file.

Of course, the PHP community is speaking back to the allegations including Clay Loveless in a new blog entry on his site:

I agree with Cubrilovic that the inadvertent delivery of source code instead of the result of that source code is certainly a horrific situation, with potentially serious ramifications for any company that experiences such a problem on a large scale basis. [...] Unfortunately, the updates appended to the article imply that PHP is somehow responsible for this leakage.

He supports some of the issues (a server misconfiguration could cause odd behavior) but refutes others (the "known issue" of PHP pushing out source code under high load).

tagged: facebook source leak server misconfigure facebook source leak server misconfigure

Link:

PHP Magazine:
SuSE - New PHP Packages Fix XSS and Information Leak
May 09, 2006 @ 11:30:34

The SuSE linux group has released new packages, according to this post on the PHP Magazine site, to deal with the XSS and information leak issues found recently in PHP4 and PHP5.

A new update fixes security issues in the scripting languages PHP4 and PHP5 including a vulnerability in copy() and tempnam() functions that could bypass open_basedir restrictions, a cross-site-scripting (XSS) bug in phpinfo(), a vulnerability in mb_send_mail() that lacked safe_mode checks, and a bug in html_entity_decode() that could expose memory content. Fixed packages are available from ftp.suse.com.

It is strongly suggested that you upgrade your installation to prevent any issues/problems from arrising.

tagged: suse linux packages fix xss information leak suse linux packages fix xss information leak

Link:


Trending Topics: