PHP : Preparing for the Penetration Testing

Chris Cornutt wrote “PREPARING FOR PENTESTING (@ LONGHORN PHP 2018)” blog post for his upcoming talk at the conference.  I’d gladly attend the talk, but the time and place didn’t work out for me this time.  Here are a few useful links from his blog post that might come in handy for anyone evaluating the security of their PHP application and preparing for the penetration testing:

The above are not a replacement for the talk, but if you are like me and can’t attend, these should at least get you started in the right direction.

WordPress Plugin Boilerplate – a standardized, organized, object-oriented foundation for building high-quality WordPress Plugins

WordPress is an excellent system for a whole lot of different projects and needs.  It’s widely used, fast, and flexible.  However it does show its age in many ways.  One of the areas where things could be a lot better and simpler is the WordPress plugin development.

WordPress plugins are still non-trivial to develop.  This is mostly because WordPress is behind the current technology in many ways: new features of PHP programming language, such as Object-Oriented Programming (OOP), namespaces, dependency management with composer, unit testing, etc.   There are good reasons for this, but those don’t help WordPress plugin developers.

What does help is, for example, this WordPress Plugin Boilerplate, which is a standardized, organized, object-oriented foundation for building high-quality WordPress plugins.  Using it still requires a bit of effort and dumb find-replace changes.  But it saves a tonne of time, as well as trial and error, especially for those people who are working on their first or second WordPress plugin.

CakePHP 3.6.0 release

My all time favorite PHP framework – CakePHP has recently announced the availability of the long awaited version 3.6.0.  What’s so special about this particular version? – those of you not very familiar with CakePHP might ask.  And I’ll tell you.

CakePHP is a well established framework, with long history – going strong for 13 years now (initial release was in April of 2005).  In web development, 13 years is a very long time.  Old tools fade away. New versions of the language and popular libraries come into play.  And it’s the job of the framework to change and adjust smoothly, providing the developer with the best and greatest, without breaking applications.  That’s not an easy task – ask anybody who had to maintain any codebase for longer than a couple of years.

I started using CakePHP back in 2007-2008 or so.  It was version 1.x and it was great.  At the time.  Then, a few years later, version 2.x was released, and as a major releases often do, it broke backward compatibility.  The most painful change at the time was still easy to fix – it was the change in the naming convention for folders, files, and classes.  CakePHP 2.x switched from their own naming convention to the PSR-2 Coding Style.

About 4 years ago, CakePHP 3.x was released, and this time it was the major of the major releases.  CakePHP framework got a lot better (and I do mean A LOT), but the price was an impossible migration.  One of the big changes in that version was the complete rewrite of the model layer and the ORM, which meant moving the CakePHP application from version 2.x to 3.x meant an almost complete rewrite (as most applications have most of the code in the model layer anyway).

That was a huge pain and community reacted.  Everybody wanted to use the cool new features of CakePHP 3, but nobody could afford to rewrite almost all of the application for this version of the framework.  (By the way, this situation is not unique to CakePHP – pretty much all other frameworks, both in PHP and other languages, either faced it or will face it in the future – that’s just how things are done).

When the CakePHP 4 roadmap was announced, one of the first things that CakePHP core developers team addressed was the upgrade path.  From the start they said that there must be a better way to handle major upgrades of the framework, and that they will find it.  And they did!

This time around, there was some ground work laid out.  Instead of just dropping another major release into developers’ laps and all the upgrade pain that comes with it, CakePHP developers absorbed a lot of it on their end, and softened the transition.  How did they do it?

Well, that’s where we get to the exciting CakePHP 3.6.0 release!  You see, the plan was do provide the gradual transition and give developers warnings and time to adjust their applications.  From the early stages of the CakePHP 3.x, a lot of functionality was commented as deprecated.  Any developer building with CakePHP framework could easily find what’s gonna go in the next major release.  But developers are always busy and never have the time for looking up things.  So what CakePHP 3.6.0 does is quite elegant.  It introduces deprecated warnings for all the functionality that will be removed in CakePHP 4.  This means that once you upgrade to CakePHP 3.6.0 your logs will get a lot noisier, telling you exactly what needs fixing.  If you don’t have the time right now, or want to ignore these warnings for now, you can simply disable them by adjusting the error reporting configuration, and all works as before.  But if you want to get ready for the next major version of CakePHP, then you have precise information of what needs to be fixed in your application.  Fixing one issue at a time, when you have the time, is great!

In fact, at work, we loved this approach so much that we started using it for our own projects as well.  Switching between different projects across several developers, and working on some old projects, etc., makes things difficult to remember.  With deprecated warnings, things are a lot simpler.

So, ladies and gentlemen, if you were looking for a framework to try, give CakePHP 3.6.0 a go.  You’ll easily upgrade to CakePHP 4 when it becomes available.  And if you were already using CakePHP 3, upgrade to CakePHP 3.6.0 and check your logs for deprecated warnings.

And, of course, stay tuned for CakePHP 4!

money – PHP library to make working with money safer, easier, and fun

money is a PHP library that implements Martin Fowler’s design pattern for money.  See the official documentation and this blog post for more information.

Some of the issues addresses by this library are the binding of the money amount to the currency, and currency conversion operations.  If your code needs to deal with multiple currencies, you’ll definitely benefit from this library.  But even if you are dealing with a single currency, it’s still pretty handy, making the code more transparent and future proof.

A Comprehensive Guide To Web Design

A Comprehensive Guide To Web Design” is a rather lengthy article that focuses on the non-technical bits of the web design.  It’s not about the tools and technologies, but more about the meaning and good practices.  The article covers the design of navigation, content, call to action, web forms, accessibility, and other important bits which are frequently forgotten.

Slimming down Docker images

It’s been a while since I posted anything about Docker.  That’s mostly because I still don’t really use it for anything – playing around locally, testing and learning doesn’t count yet.

But just to keep the ball rolling, here are a couple of handy links for the ideas on how to improve your Docker images, so that Docker uses much less space, benefits more from caching, and brings up the containers faster:

Both articles are around the same theme – choose your  base image carefully, try to minimize the layers, use only what you need, and don’t forget to clean up the disk space with “docker system prune“.

17 Tips for Using Composer Efficiently

Martin Hujer has collected 17 tips for using composer efficiently, and then added a few more after receiving the feedback on the blog post.  I was familiar with most of these, but there are still a few that are new to me.

Tip #7: Run Travis CI builds with different versions of dependencies

I knew about the Travis CI matrix configuration, but used it only for other things.  I’ll be looking into extending it for the composer tests shortly.

Tip #8: Sort packages in require and require-dev by name

This is a great tip!  I read the composer documentation several times, but somehow I missed this option.  It is especially useful for the the way we manage projects at work (waterfall merges from templates and basic projects into more complex ones).

Tip #9: Do not attempt to merge composer.lock when rebasing or merging

Here, I’m not quite sure about the whole bit on git attributes.  Having git try to merge and generate a conflict creates a very visible problem.  Avoiding the merge might hide things a bit until they popup much later in the CI.  I guess I’ll have to play around with this to make up my mind.

Tip #13: Validate the composer.json during the CI build

This is a great tip!  I had plenty of issues with composer validations in the past.  Currently, we have a couple of unit tests that make sure that composer files are valid and up-to-date.  Using a native mechanism for that is a much better option.

Tip #15: Specify the production PHP version in composer.json

This sounds like an amazing feature which I once again missed.  Especially now that we are still migrating some projects from PHP 5.6 to PHP 7.1, and have to sort out dependency conflicts between the two versions.

Tip #20: Use authoritative class map in production

We are already almost doing it, but it’s a good opportunity to verify that we utilize the functionality correctly.

 

Defensive Programming : Object Calisthenics

I came across this nice and somewhat strongly opinionated video on Defensive Programming:

Marco Pivetta makes quite a few good points with I agree (and a few with which I disagree).  One thing that he mentioned though I haven’t heard about – Object Calisthenics.  Which turns out to be yet another set of rules and best practices for the object-oriented design and programming.  Here are the rules to get you started:

  1. Only One Level Of Indentation Per Method
  2. Don’t Use The ELSE Keyword
  3. Wrap All Primitives And Strings
  4. First Class Collections
  5. One Dot Per Line
  6. Don’t Abbreviate
  7. Keep All Entities Small
  8. No Classes With More Than Two Instance Variables
  9. No Getters/Setters/Properties

Read the whole article for explanations and examples.

Nginx Performance Tuning – Tips & Tricks

Here are a whole lot of “Performance Tuning – Tips & Tricks” directly from the Nginx team.  I’m sure you’ve seen bits and pieces of these all over the place, but it’s nice to have them all together and from the credible source as well.

The 2018 Guide to Building Secure PHP Software

The 2018 Guide to Building Secure PHP Software” is an excellent guide to writing modern PHP applications with security in mind.  It covers a bunch of the usual topics, but provides fresher solutions than most other similar guides.