We are moving our forum in GitHub Discussions. For questions about Phalcon v3/v4 you can visit here and for Phalcon v5 here.

Solved thread

This post is marked as solved. If you think the information contained on this thread must be part of the official documentation, please contribute submitting a pull request to its repository.

Phalcon and PHP Object injection

I published article about Phalcon http://webmastah.pl/phalcon-php-miedzy-moca-a-uzytecznoscia/ and one of commenters give me link to the presentation where are some information about security and Phalcon - http://prezi.com/5hif_vurb56p/php-object-injection-revisited/

What do you think about that?


The point is valid, virtually any external data entered by users or consumed must be validated or completely rejected, this is not something new. So what he states is that any PHP application could potentially be attacked if external data is unserialized and these data might contain dangerous data. I guess Phalcon is used as an example to say that neither an C-extension offers protection for such cases.

The second point in the video, is that he is performing an attack to a demo application by saving a logger in a cookie and then unserializing the cookie's content which is not common and it's probably a bad idea (for any php application), he also disabled the default encryption in the cookies component to send plain text to the client which is another bad idea. Also it seems that his server is configured with allow_url_include = On which is another bad idea also uncommon. In short, it seeks to demonstrate the maximum impact the attack could have, however the attack rely on very uncommon conditions.

I don't think there is a high chance that a developer do all this things together this because there is no practical sense in real life of:

1) Storing a logger in a cookie. 2) Use a cookie as the logger's path 3) Disable encryption in the cookies component 4) Enable allow_url_include = On

However, we added a fix in 1.2.3 to avoid that a developer can store a logger in a cookie (just in case). Note that any user can save objects in unencrypted cookies that expose internal details of the application, and there is not much we can do to prevent that from happening.

@Phalcon - thank you for answer.