Pádraic Brady » PHP General

PHP: Innocent Villagefolk or a Pillagin’ Pirate?

padraic — Thu, 12 Apr 2012 15:28:29 +0000

This is a train of thought article (i.e. it may make sense…or not). You’ve been warned in advance. The CL;DR will be posted to Twitter when Hell freezes over, pigs fly, and Hollywood makes an ensemble casted DC Universe movie. This is what happens when you have a laptop, an editor, a train ride home, and have just realised that the wifi connection is not working.

In PHP, we’re well insulated from what happens in other programming languages. This is not by accident – mentioning PHP while among a crowd of Java, Ruby, Python or Perl programmers is liable to result in a heated argument, several fistfights and one dead PHP programmer. Death by mobbing is not a pretty way to go. I’m sure a few of us have been there – at a web conference where people dismiss PHP out of hand as a kiddie toy for the weak minded and demented. When everyone around you starts nodding, remember to make yourself as inconspicuous as possible and request armed backup from the local PUG.

Of course, PHP programmers all know that the other programming languages are just jealous – PHP has no true OOP model, it’s ugly as sin, can’t figure out which parameter order is right, and is several years behind the curve in adopting best practices but the damn thing remains extremely popular, keeps getting faster, has the best reference manual ever invented, more frameworks than grains of sand on a beach, and in recent years has become a hotbed of innovative libraries now that PEAR and its messy aftermath have been displaced by Github. It’s sickening.

I often wonder why that is. I could go with the usual arguments – PHP is easy to learn, very effective, yada yada yada. Those are the boring reasons we try very hard to believe in. Ruby is easy to learn, very effective, and has even more yadas to go around. It’s still sitting at 11 on the Tiobe Index to PHP’s 6.

What’s fascinating about some programming languages is their reaction to and life after maturity. PHP is an immature programming language which pretends to be mature (to earn Enterprise cookies) but otherwise couldn’t give a toss. I don’t mean that in a bad sense. PHP continues to exude a sense of adventure as it playfully steals ideas left, right and center from its peers. Most of our foremost advances are “borrowed” years after their adoption elsewhere. What PHP excels at is tireless consumption. Marathon races make one hungry and we can’t help but notice the feasts being exposed by Rubyland or Pythonville as they do their best to sprint past us. Without that thieving spirit, PHP would long since have entered obscurity as a quaint HTML oriented scripting language used by college students to build cheap websites with flashing text and under construction GIFs.

To me, PHP is a rogue. If we were playing an RPG, PHP would have pointy ears, a cloak, a couple of daggers and as many lockpicks as it could fit in its inventory (leaving sufficient room for liberated loot, of course). Ruby will never see us coming…our sneak skill is epic. PHP figured out how to keep the W key depressed while crouched in a corner in Elder Scrolls: Morrowind before the game was even designed.

I’m sure this comes across as being a bit humourous, but is it? Sometimes when I hear about PHP being innovative I almost crack up on the spot from disbelief. As PHP developers we’re not often (as in never) in the limelight generating new programming paradigms and practices – we’re most likely to be found connecting the dots between PHP and some novel idea we stumbled across elsewhere. Our strength lies in our ability to connect the dots several hundred times over to the point where the best dot connector gains a critical mass of adoption and we get something like Doctrine, or Composer, or PHP’s new Traits, or whichever of the zillion popular frameworks you prefer that are desperately trying to eke any form of differentiation from MVC (up to and including liberal interpretations of its definition).

It’s a process that works for the simple reason that PHP programmers are immature gits. We love paddling in other programming languages, we love to reinvent the wheel and brag about it, we love to overstate our personal preferences’ importance, and we love ignoring best practices and fighting for the bad ones. There’s a weird benefit to our craziness – trying to get any two PHP programmers to agree to anything is doomed to fail but it promotes competition very well. We’ll write a million versions of anything that isn’t nailed down or too boring to behold while Ruby developers console each other over their One True Way consuming the Last Hope of Mankind (Rails ate Merb and suffered from chronic indigestion – a true but very sad story).

What we really need is a new PHP motto. Something deep and meaningful that exposes PHP’s true nature. I was thinking “Rob ‘em blind, matie!” would be a good one but I remembered that we need to cater for the Enterprise audience. Suggestions welcome.

In the meantime, as we struggle with our identity and stay one step ahead of the city guards who have it in for wanted thieves (tends to happen in all Elder Scroll titles), we should be preparing for our next mark: node.js. It claims to be non-blocking. This is excellent, we can get in close with our daggers without any pesky shields getting in the way.

Ruby is terrified by node.js because node.js is the new hotness. Rails 4.0, which is in beta, is the second version of that framework showing fatally unstylish signs of becoming a mature platform for application development. It even demonstrates a use of design patterns. The bastards. There’s only so much the fashionistas can take before they jump ship to the next immature poorly designed piece of crud needing a massive influx of early adopters to beat it into a usable form over the next semi-decade. I’m being overly harsh – it’s not poorly designed, I’m sure stuff like database reads, and filesystem ops can be made non-blocking. Somehow. Pixie dust? Reality distortion field usurped from the bones of Steve Jobs? It sounds like it will be something valuable and very very shiny.

PHP is also terrified of node.js – in the sense that we know its name and think it has something to do with Javascript. Now that it has joined the race and is sprinting far behind us towards the finish line, we can look forward to years of replicating its best features which is in no way to say that we will stab it though the heart in an alleyway and strip it of valuables. You can’t literally do that with a programming language afterall. Pity.

So my brothers and sisters, embrace your inner pirate and revel in it. Now, anyone know if there’s anything worth stealing from NXT-G? It managed to sneak into 20th position on the Tiobe index up from 56th. I want its shiny stuff.

A Hitchhiker’s Guide to Cross-Site Scripting (XSS) in PHP (Part 1): How Not To Use Htmlspecialchars() For Output Escaping

padraic — Mon, 12 Mar 2012 20:49:36 +0000

(Photo credit: bertboerland)

In recent weeks, I consulted with the second most intelligent species on the planet: Dolphins. Dolphins are renowned across the known Universe for their awesome programming skills. After all, it was they who developed such insightful works as “Evolution By Example”, “Dude! We Wrote The Laws Of Physics!”, and “How Many Humans Does It Take To Screw Up A Planet?”. The answer to the last will be published on 01/01/2013 after the experiment is shut down and sent to a landfill site assuming the Supreme Spaghetti Monster signs off on the permit.

Dolphins think we are really dumb and theorise that this level of stupidity has one obvious cause: self-imposed ignorance. We are, after all, only the third most intelligent species on Earth and appear to have aspirations to lower our IQ just a bit more.

While it’s no harm poking fun at ourselves, in PHP we do have a serious problem. Cross-Site Scripting (XSS) remains one of the most significant classes of security problems afflicting PHP applications. Despite years of education, community awareness and the development of frameworks which can offer a huge boost in consistent practices – things are not getting any better.

So, I finally figured out what the core problem is: PHP programmers are completely clueless about XSS. It’s that simple. Instead of going out and studying the topic, we blindly follow some preferred herd of people offering advice with heartfelt conviction despite the fact that they are probably just as ignorant as the rest of us. Does that sound like the behaviour of something which allegedly evolved into an intelligent species? The result is a mix of ignorance and stagnant knowledge that leaves PHP in an unenviable position beset by wrongheaded zealots.

To get the ball rolling, this two-part article series is a tour of how NOT to use the htmlspecialchars() function that is typically pressed ganged into service as PHP’s universal output escaper. By offering an example based guide, I hope it will illustrate just how many ways a prospective attacker using XSS can exploit this function’s misuse to pull off a successful attack. The examples were written for PHP 5.3, so 5.4 users may need to imagine they still have 5.3 installed and/or lodge an official complaint with somebody who looks like they keep a complaints box handy (your local fast food restaurant is a good start).

This example led approach has another motive. Simple examples can be translated into unit tests. Ideally, many of the current crop of frameworks can use this article as a guide to what their unit tests should be looking for. This also makes it far easier for everyday programmers to consume the article and run around the place, drunk with ungodly power, identifying issues in the libraries, frameworks and other projects that they rely on.

To help us on the path of enlightenment before it’s too late (I’d lodge an appeal with the Supreme Spaghetti Monster but apparently the Mayans already tried and failed), I also invite other PHP programmers to blog about a security topic over the next month or two. Give programmers one last chance to get it right before the Planet is demolished by the Vogon destructor fleet. Just pick a topic that drives you up the walls in defiance of gravity and spend an hour writing something useful and (optionally) expletive filled. Every little bit helps.

What Is Htmlspecialchars()?

According to many programmers from Earth, htmlspecialchars() is a function used to escape output to prevent XSS. This is however a completely wrong definition. The function was actually co-opted by programmers to combat XSS because it was either that or create slow userland functions for which the internals developers might get around to creating, when the full moon coincided with the right planetary alignment in another 314 years, a speedier C alternative to. The actual definition (along with a half-hearted self-doubting nod to preventing XSS) is as follows:

Certain characters have special significance in HTML, and should be represented by HTML entities if they are to preserve their meanings. This function returns a string with some of these conversions made; the translations made are those most useful for everyday web programming. If you require all HTML character entities to be translated, use htmlentities() instead. This function is useful in preventing user-supplied text from containing HTML markup, such as in a message board or guest book application.

Note that this hints at, but does not explicitly use, the terms Cross-Site Scripting, XSS or even Security. Then again, it does refer to guest book applications so it was probably written in 1790 by the Dolphin who created PHP v86 and who then got around to backporting version 1.0 for Humans in the late 20th Century out of extreme pity for our reliance on CGI. No, not the let’s take an action movie and turn it into a plotless eyesore with computer generated fake stuff style CGI – though memories of both are comparably bad.

Does this make htmlspecialchars() terrible at preventing XSS? No. As part of a comprehensive well-understood strategy to prevent XSS, the function is very useful. However, in PHP it is frequently overused, misused, abused, confused and…. Darn it, ran out of rhyming words again. Suffice it to say that a good description of htmlspecialchars() is that it’s an unsuitable tool for preventing XSS that has slowly evolved into a better suited tool over the years. I keep telling myself that, at least.

The function, htmlspecialchars(), accepts four parameters. Here is its function prototype as of PHP 5.4:

string htmlspecialchars ( string $string [, int $flags = ENT_COMPAT | ENT_HTML401 [, string $encoding = 'UTF-8' [, bool $double_encode = true ]]] )

The first parameter accepts a string whose special HTML characters will be converted to HTML entities. The second accepts one or more flags which defaults to using ENT_COMPAT (does not convert single quotes to entities) but should be set to use ENT_QUOTES (does convert single quotes to entities). You can include another flag, in PHP 5.4, called ENT_SUBSTITUTE which is not a bad idea for UTF-8, i.e. ENT_QUOTES | ENT_SUBSTITUTE. You can pretend that all the other constants don’t exist. The third parameter accepts a string indicating the character encoding of the string being processed and defaults to ISO-8859-1 for PHP 5.3, and UTF-8 for PHP 5.4. Don’t ever set the fourth parameter to TRUE when escaping unless your filtering logic was written by an Über Dolphin – always keep filtering and escaping separate from each other to avoid confusing the two and then having to pointlessly argue why your way is better in defiance of all logic.

The function, if correctly configured using this super simple article for guidance, will now convert the following characters to entities: <, >, ‘, ” and &. These characters make sense to escape since they are used to construct HTML tags, delineate attribute values or reference HTML entities – none of which we want users to be able to do!

If you want some very good advice before your brain implodes from too much reading, a good way to potentially make yourself vulnerable to XSS is to not explicitly set the first two optional parameters ($flags and $encoding) to an appropriate value. In fact, if you see htmlspecialchars() missing any of those two parameters in someone’s source code, you should request that they fix it or, at the very least, curse their name and pray for the Supreme Spaghetti Monster to label them as biohazardous waste in need of emergency disposal.

Now, let’s get down to overloading your brain with information. I’m told that this part is like being sucked into the Total Perspective Vortex machine on Frogstar World B.

To Quote Or Not To Quote. How Is That A Question?

As it turns out, HTML is not simply a popular markup language, it is a popular markup language designed by a bureaucratic species of transdimensional beings seeking to drive Humanity insane by inventing the most impossible-to-secure markup language known in 172 Universes which is then interpreted by “browsers” written by Mice to test the patience of security professionals and keep the really intelligent Humans distracted from the truth of their soon-to-end existence as they search out ever more ludicrous examples of parsing weirdness. Excuse me, I held my breath writing that and need to fetch my Oxygen tank…

Consider the following example. If you want to see whether they work without copy pasting, you can clone all examples from my ominously titled xss repository on Github into a webroot somewhere to read or execute them.

Single Quoted Attributes

 header('Content-Type: text/html; charset=UTF-8'); ?>
$input = <<
' onmouseover='alert(/Meow!/);
INPUT;
/**
 * NOTE: This is equivalent to using htmlspecialchars($input, ENT_COMPAT)
 */
$output = htmlspecialchars($input);
?>
    Single Quoted Attribute
    
        
            What's that latin placeholder text again?
        
    

If you run the example from a browser and pass your mouse pointer over the text, you will get a popup saying “/Meow!/”. Granted, this is hardly the most impressive XSS ever but remember that the Javascript executed could be a lot more ingenious and damaging. The reason you see alert() used everywhere in XSS examples is to prove that Javascript was executable – a real attacker will hardly advertise his success like this.

In this case, the htmlspecialchars() function call omits the second parameter which defaults to using the ENT_COMPAT flag. With this setting, the function does not convert single quotes to entities, allowing us to inject an unescaped single quote (to close the title attribute value) and another to start a new attribute and value which will be closed by the final single quote used in the template.

We can fix this problem in one of two ways:

1. Use double quotes which will prevent user input from breaking out of the HTML attribute value context using single quotes; or

2. Set the second parameter to htmlspecialchars() to use the ENT_QUOTES flag which will escape any single quotes a user tries to inject.

The moral of the story can be made even clearer by another example. In this case we use another perfectly validating means of delineating attribute values in HTML5 – we just don’t bother using quotes at all!

Quoteless Attributes

 header('Content-Type: text/html; charset=UTF-8'); ?>
$input = <<
faketitle onmouseover=alert(/Meow!/);
INPUT;
$output = htmlspecialchars($input, ENT_QUOTES);
?>
    Quoteless Attribute
    
         echo $output ?>>
            What's that latin placeholder text again?
        
    

Without quotes delineating the attribute value, any space character (including any character a browser might interpret as a space – there are a lot!) allows the user to inject new attributes and values. As from the above, converting all quotes to entities is pointless if there are no quotes to start with! Our escaping doesn’t convert spaces or other space-interpreted characters into entities at all.

By now, you should see the obvious. All HTML attribute values MUST be quoted, and preferably DOUBLE quoted, in any scenario where you suspect untrusted input will be injected into an attribute value, or where htmlspecialchars() calls do not set the second parameter to use ENT_QUOTES. Believe it or not, using single quotes or no quotes remains popular and is perfectly valid under the new HTML5 spec. Some people even celebrate this new insanity. Keep an eye on any designers who look a bit wild eyed or spend too much time smiling while staring into empty space.

Excuse Me, Sir, But Someone Ate My Quotes

One of the great mysteries in escaping output is a common myth known as the Great ASCII Delusion (GAD). Those under the influence of this delusion, besides hearing voices in their head, have arrived at a belief that many character encodings are equivalent for the purposes of escaping those characters which have a special meaning for HTML, e.g ISO-8859-1 and UTF-8. Alas, this is untrue because the Mice created something called Internet Explorer 6 – a thoroughly shameful (but still commonly used) browser which corporations across the Planet continue to insist on using because buying new computers and upgrading operating systems just to use some fancy new Microsoft Office version is seen as a waste of shareholder funds.

Internet Explorer 6 is the bad boy of the XSS world since it’s vulnerable to ridiculous exploits no decent modern browser would dare associate with. Even Netscape would probably spit on it from beyond the grave. For example, have a go with this example using IE6 and PHP 5.3. If you need a testing version of all IE browsers since IE 5.5, you can download IETester from http://www.my-debugbar.com/ietester/index_all.php and use it from Windows. Try hard, I know Windows is bad and the new Tablet makeover for Windows 8 makes you feel ill, but it’s important to see these examples in action.

Source code

 header('Content-Type: text/html; charset=UTF-8'); ?>
/**
 * You could also subsititute \xC0 or any other impacted character
 * above ASCII number 192
 */
$input1 = 'fakeimage'.chr(192);
$input2 = <<
onerror=alert(/Meow!/)//
INPUT2;
$output1 = htmlspecialchars($input1, ENT_QUOTES);
$output2 = htmlspecialchars($input2, ENT_QUOTES);
?>
    Swallowed Quotes
    
         echo $output1 ?>"
        title=" echo $output2 ?>">
    

With the above example, something very weird happens. Using ASCII character number 192 just before a double quote in a document being interpreted as UTF-8 results in the double quote…vanishing in IE6. Seriously, it’s there but not there. Obviously the Mice are behind it – no Human could possibly defy Physics like this!

This allows an attacker to once again break out of the HTML attribute they can inject values into. Using a coincidental opportunity to inject a second free text string nearby which a browser will concatenate to the broken out attribute value of the first, you get an effective XSS combo attack.

This IE6 quirk even bypasses the call to htmlspecialchars() which, as explained above, defaults to the ISO-8859-1 character encoding for PHP 5.3 or less. If the Great ASCII Delusion were not a fabrication of someone’s imaginative wishful thinking, this should not be possible. Not to be too harsh though, this weirdness is due primarily to a bug in IE6′s treatment of the various character encodings where you can trick the browser into thinking something like \xC0 (in hex) is the start of a multi-byte character thus swallowing the next ASCII character (the double quote).

To fix the above weirdness, you must make sure that escaping is done using the same character encoding that the document is being served as. The above HTML document is identifying itself as being UTF-8 but the default htmlspecialchars() encoding is ISO-8859-1 in PHP 5.3 – there’s obviously something not agreeing there! This brings us to the absolutely perfect use (well, almost) of htmlspecialchars(), the golden rule, the Word of The Supreme Spaghetti Monster, the bringer of frustration to XSS attackers:

Always set the third parameter to htmlspecialchars(), set it correctly, and make sure your document is never served with a mismatched or invalid character encoding! Don’t expect some theoretically perfect world to magically appear – browsers are filthily efficient at doing weird things you don’t expect.

I suppose I have to mention that most versions of IE have similar issues with other character encodings such as BIG5 and Shift-JIS. You can test your IE versions using http://ha.ckers.org/weird/variable-width-encoding.cgi to see what characters can be used across different character encodings. Believe it or not, these character encodings are actually still being used and, for some strange reason, people from China and Japan do use PHP.

If you want to be completely paranoid, you can either check the input for invalid UTF-8 (Drupal and HTMLPurifier have reusable functions/classes for this), and/or run it through a conversion function which should theoretically filter out the naughty bits:

$input = mb_convert_encoding($input, 'UTF-8', 'UTF-8');

This is probably a good idea for older PHP versions pre 2010 or earlier but recent PHP versions have specifically improved htmlspecialchars() to disallow invalid characters such as the above (if you set the right character encoding!). You should be aware, though, that htmlspecialchars() may still return blank strings on certain malformed input and, since PHP 5.4, will not issue any warnings about this.

I Broke It! I Broke It!

Before you think htmlspecialchars() is getting off lightly, there is one minor quibble. We’ll keep picking on Internet Explorer 6 for the rest of this article since it’s so easy to exploit.

Source code

 header('Content-Type: text/html; charset=UTF-8'); ?>
$input1 = 'fakeimage'."\xC0";
$input2 = <<
onerror=alert(/Meow!/)//
INPUT2;
/**
 * If you think PHP 5.4 will save you - empty strings make it guess the encoding
 * or use the default_charset value from php.ini. You sure everyone on the whole
 * planet uses UTF-8? Under 5.3 - empty strings === default encoding.
 */
$encoding = ''; // from outside source or unvalidated variable
$output1 = htmlspecialchars($input1, ENT_QUOTES, $encoding);
$output2 = htmlspecialchars($input2, ENT_QUOTES, $encoding);
?>
    Swallowed Quotes
    
         echo $output1 ?>"
        title=" echo $output2 ?>">
    

Setting the third $encoding parameter of htmlspecialchars() to an empty string in PHP 5.4 will set the encoding to be auto-detected, grabbed from the php.ini value of default_charset, or guessed from the current locale (in that order). Be very careful under PHP 5.4 NEVER to let this happen. Don’t leave your escaping parameters to chance.

Use empty() or strlen(), for example, to spot this issue if accepting encodings from another source or variable that might allow for empty strings. Again, this behaviour is very secure and there’s nothing wrong with it whatsoever. Oh, who am I kidding… This is the dumbest parameter behaviour ever invented. NULL means use the default encoding; blank string means play a guessing game. Even Vogon poetry pales in comparison to such nonsense. One slip and an empty parameter string can rip apart this house of cards because who knows which character encoding will be used.

Oooh, I wonder what this does under PHP 5.3… Yes, er, don’t allow blank encoding parameter strings under PHP 5.3 either. Setting an empty string in PHP 5.3 is interpreted as setting the default character encoding, i.e. ISO-8859-1, instead of triggering the expected warning about an unsupported encoding.

So, be careful kids. When setting the encoding for htmlspecialchars() do a safety check to make sure it’s not an empty string you are passing in. Keep it predictable and consistent.

There’s also one other curious behaviour when using htmlspecialchars().

Source code

 header('Content-Type: text/html; charset=UTF-8'); ?>
error_reporting(E_ALL);
ini_set('display_errors', 1);
$input1 = 'fakeimage'."\xC0";
$input2 = <<
onerror=alert(/Meow!/)//
INPUT2;
/**
 * Invalid encoding makes htmlspecialchars() throw a warning but it continues
 * the current operation anyway using the default encoding even if the default
 * is an unsafe choice for the application. Don't allow invalid encodings!
 */
$encoding = 'invalid-encoding'; // from outside source or unvalidated variable
$output1 = htmlspecialchars($input1, ENT_QUOTES, $encoding);
$output2 = htmlspecialchars($input2, ENT_QUOTES, $encoding);
?>
    Swallowed Quotes
    
         echo $output1 ?>"
        title=" echo $output2 ?>">
    

When you set an invalid character encoding, not the empty string of doom, htmlspecialchars() will issue a Warning level error…and continue merrily on its way by reinstating the default encoding. In a production scenario, you will likely have display_errors disabled and this warning will be logged and possibly ignored by some users. If this makes it through, setting an invalid character encoding whether by a deliberate user value or simple programmer error may create an exploitable scenario.

So, make sure you also validate the character encoding. Don’t just leave it up to htmlspecialchars() since it allows the continued execution of the application. Arguably this should be a fatal error since a bad encoding is itself a security problem.

Seriously, this function is like handing a box of matches to a Human and telling them there’s a rainforest nearby that’s essential to all life on Earth…

Internet Explorer: Master Of Supporting Stupid Character Encodings

Internet Explorer is unique in the Universe. Designed by Mice to be the dumbest, most frustrating, most stubbornly non-upgradeable piece of crap ever, it does things that make XSS far easier. The terrible part is that IE is popular with corporations and businesses using commodity hardware imported from whichever country currently has the lowest paid PC assemblers on Earth. One would think they’d like a more secure browser to protect their money making endeavours.

It’s no wonder that Dolphins had to think long and hard before deciding we were marginally smarter than the average cat. Cats, coincidentally, strenuously deny this claim having spent thousands of years demonstrating a lack of Human intelligence by showing how easy it is to make Humans cater to their every need…for free. Even their main rivals, Dogs, are expected to do useful work like herding sheep, chasing cars, digging holes, barking at strangers, and keeping bill bearing postal workers at bay.

All versions of Internet Explorer support a troublesome character encoding called UTF-7 which, oddly enough, is not supported by htmlspecialchars(). You can probably see where this is going. How do you escape a character encoding that your escaper doesn’t even support? Easy, you can’t. JUST DON’T USE UTF-7! EVER! UTF-7 has the distinction of definitely not being ASCII compatible – it encodes angle brackets (used to open and close HTML tags) very differently so they are never detected by filters or escapers relying on other character encodings.

Unfortunately, some applications do allow users to cherry pick an encoding. It’s not uncommon in international websites (e.g. Google which had this problem). Here’s an example of what not to do:

Source code

$input1 = 'UTF-7';
$input2 = <<
INPUT2;
$input2 = mb_convert_encoding($input2, 'UTF-7', 'UTF-8');
$output1 = htmlspecialchars($input1, ENT_QUOTES, 'UTF-8');
$output2 = htmlspecialchars($input2, ENT_QUOTES, 'UTF-8');
 
header('Content-Type: text/html; charset='.trim($output1));
?>
    Mismatched Encoding
    
    content="text/html; charset= echo $output1 ?>">
         echo $output2 ?>
    

This works in all IE versions. The problem here is that we’re letting the user set the character encoding without validating it against a safe whitelist of encodings that we can actually escape. This also works even when you plead with the Supreme Spaghetti Monster and try passing UTF-7 to htmlspecialchars() since the function simply issues a warning and reinstates its ISO-8859-1 or UTF-8 default before continuing on its merry way to making you vulnerable to XSS. Yes, very secure behaviour there…

Note: putting the @ symbol in front of htmlspecialchars() to hide these warning errors during development is not considered an act worthy of an intelligent species. Don’t let the cats win!

Now, you might think that this would be the end of it, but there’s one other problem afflicting older browsers (fixed as of Internet Explorer 9). In certain scenarios you can trick the browser into rendering pages as UTF-7 even when you can’t set the page’s character encoding. This is due to a bug in how some browser versions guess the character encoding when it’s absent (i.e. not set in a header or meta tag, or set incorrectly, e.g. UTF-8 is valid; UTF8 is NOT).

To pull off this exploit, you need to first set some UTF-7 text which is persisted across requests, e.g. a blog comment. Since we can’t escape UTF-7 in PHP, the persisted text will contain some UTF-7 encoded XSS code. Just in case, you’re smart and you’re thinking that mbstring functions might help detect UTF-7 – they won’t. mbstring will detect UTF-7 as UTF-8, and UTF-8 as UTF-7 depending on the detection order set in mb_detect_encoding(). After that it’s a long winded story of using iframes to trick a browser into rendering the innocent looking UTF-7 strings on your webpages as UTF-7.

Where escaping fails, some common sense should win out. Just make sure all the responses you serve have a header that sets the appropriate character encoding for the content (use a valid encoding string, not an invalid string form). In HTML, use the relevant meta tag to indicate the content’s character encoding as a backup should the header be somehow omitted.

Conclusion

Htmlspecialchars() as a function for escaping output has its limitations. If you’re unaware of these and wish to persist in using it incorrectly, you should expect to be burned. No, seriously, there really is an incinerator for those labelled as biohazardous waste over in Alpha Centauri.

I get the feeling I’ve written enough for you today. I’m very sorry for the 0.006% of you that Vogon studies indicate are now sitting at their desk drooling all over their keyboards from encroaching insanity. If you’re worried about joining the 0.006%, please submit the correct form in triplicate, completed in capitals using a blue ball-point pen, to your local Alpha Centauri Medical Facility where the friendly Vogon staff will give you a free brain scan and determine whether the incinerator next door needs more fuel.

So, what next? In Part 2, we continue our voyage into madness with more examples using htmlspecialchars() though in another direction this time. In the meantime, you have a lot of examples (aka ammunition) and there are a lot of applications/frameworks/libraries (targets). I figure the rest is obvious.

See you for Part 2!

Mockery 0.7.2 Released (And On Packagist.org!)

padraic — Wed, 25 Jan 2012 11:07:07 +0000

Mockery is a simple yet flexible PHP mock object framework for use in unit testing with PHPUnit, PHPSpec or any other testing framework. Its core goal is to offer a framework for creating test doubles like mock objects through the use of a simple and succint API capable of clearly defining all possible object operations and interactions using a human readable Domain Specific Language (DSL). Designed as a drop in alternative to PHPUnit’s phpunit-mock-objects library, Mockery is easy to integrate with PHPUnit and can happily operate alongside phpunit-mock-objects.

Today, I am pleased to announce the release of Mockery 0.7.2, a maintenance release fixing a small number of bugs and annoyances. A special thanks to all those who forked the Github project at and submitted pull requests! Leaving a developer with hardly any work to do other than a quick test and merge is always appreciated! You can install or upgrade to the new version from the survivethedeepend.com PEAR channel.

Another piece of news is that Mockery is now available on Packagist.org for users of Composer. Composer is a tool to help you manage your own projects’ or librarys’ dependencies and it can handle and mix dependencies from Composer compatible repositories like Packagist.org, any git repository using tags, and any PEAR channel. I do this of my own free will and not because Luis Cordova and Benjamin Eberlei are standing behind me with pitchforks .

The more pertinant fixes include:

Fixed a problem in resolving methods chains which abuse the Law of Demeter (thanks to the wizardly Robert Basic).
Fixed unexpected static calls to an alias mock which were causing fatal errors (thanks to Luis Cordova).
Fixed a crash present since PHP 5.3.6 due to a referenced $this variable entering a closure (thanks to Martin Sadovy).
Added support for PHP_CodeCoverage 1.1 whose filter class is no longer a singleton (thanks to Matthew Vivian).
Added non-halting exception handling (for Mockery exceptions) to the PHPUnit TestListener (thanks to Adrian Slade).
Added boolean $prepend (defaults to FALSE) parameter to \Mockery\Loader::register() to allow for registering Mockery’s autoloader to the top of the autoloader stack even after other autoloaders have been registered (thanks to Hermann Kosselowski).
Updated documentation/tests for the release of Hamcrest 1.0.0 several days ago (thanks to me, me, me – who finally got to do something nobody else had a pull request for!).
Added new \Mockery::self() static method to make retrieving the current mock object simpler and more readable while setting expectations without the need to refer back to past variable assignments.

Users should also note that Hamcrest 1.0.0, which includes a small filename change (hamcrest.php was capitalised to Hamcrest.php), was released several days ago. If you use Hamcrest matchers with Mockery, you should ensure that both libraries are updated on your system.

As always, please report any bugs or potential improvements to the Github issue tracker using the relevant label or, even more appreciated, send me a pull request.

Storing Session Data In Cookies: Problems And Security Concerns To Be Aware Of

padraic — Mon, 23 Jan 2012 21:20:12 +0000

Image via Wikipedia

Back from my extended leave of absence, I’ll re-open the dusty cobwebbed depths of this blog to echo the sentiments of Paul Reinheimer in his recent article “Cookies don’t replace Sessions“. The topic is actually an old one since Ruby On Rails has adopted the strategy of storing application session data in cookies by default (take note, performance hounds). The purposes of storing sessions in userland cookies rather than the conventional “stick-it-on-the-filesystem/database” used by many apps is one of performance and a little obscuration. Cookie data can be accessed faster than hitting the filesystem/database plus it has the dubious ability to disguise the session-targeted programming language. Really though, PHP is assumed to be on all web servers so hiding its existence is a bit like trying to hide an elephant in a zoo. Hide it all you want – we still know there has to be one in there!

In exchange for speeding up session reading, storing session data in cookies has some fairly uncomfortable costs.

Now, developers are not unaware of the problems of storing potentially sensitive application data in plain text files on the user’s PC which users can manipulate, copy, and mangle to their (or the hacker’s currently fiddling with the user’s PC) heart’s content. It’s dangerous depending on just how much you rely on session data to drive other security rules or restrictions on business logic within the application. Technically, the reliance placed on sessions should be close to nothing – session data should drive the application towards other storage solutions for the really essential stuff and just stay around as a minimal identifier/stash of basic ID info. Such minimal information can be dumped, corrupted, or overwritten with the only cost being to perhaps require a user to login again when that happens. Stuffing a bank balance into a session, on the other hand, is one (very exaggerated!) example of the kind of data you should be shot for relying on a session for.

Programmers being programmers, it’s not rare to see sessions become a more intrinsically important storage location than it should be. In those cases, being able to manipulate the session data can become a problem and may give rise to exploitation scenarios where tampering with the stored data leads to some benefit for the manipulator. Obviously we want to make sure that that can’t happen even in scenarios where programmers may be a bit loose with where they store data. We don’t build frameworks and libraries for Gurus, we build them for all programmers – even the sometimes ignorant and under trained ones. This cookie stored session data is often coupled with the ability to encrypt that data. However…

As Paul Rainheimer remarks in his article, “Encryption is often viewed as a panacea for security problems, you sprinkle a little encryption dust around, and your problems dissolve”. This is an absolute truth in programming – programmers often view encryption as a solution without regard for one teeny tiny problem. If you encrypt a set of data for any purpose, even though it’s encrypted, the user (or the hacker hacking the user’s account) still has the data in some usable form!

With perfectly intact data, and even through it’s hidden by encryption, that data can be recycled simply by copying it to another machine. Depending on the data that is stored (which admittedly may require the hacker/user to figure out by doing actual work like finding your open source app on Github or breaking a developer’s fingers until they spill the beans), you can restore past data just by copying over a backup of a prior cookie or repeat a past transaction by continually reusing the original cookie it required. Paul offers a few trivial examples in his article.

Such reuse of data is known as a replay attack. A scenario where even encrypted data can be constantly reused to give rise to a positive result – all without any need whatsoever to break the encryption. The antidote to this vulnerability is to ensure that all data sets are unique and can be used only once, i.e. you include a single-use nonce (some generated set of characters or bits) in the data which is updated whenever that data is used. This continually forces the update of the relevant digital HMAC signature and/or encryption result (even for the exact same data otherwise) in order to prevent any reuse of old data in a replay attack. Once a nonce is used, it’s discarded, and the old data can no longer be accepted by your application. Of course, the downside is that since the nonce must be single-use, you need to keep track of all nonces to ensure they are not accidentally used again. You will need a database, possibly using a nonce-included timestamp as a time limit so your storage requirements aren’t completed insane, which obviously means that just using the traditional database storage for sessions in the first place would have been a much better and simpler choice.

So, in summary, encryption prevents the reading of data but it does not prevent the reuse of existing data. For that to be prevented you need a nonce implementation. And, due to the complexity of using and tracking nonces, practically no cookie stored session solutions will actually offer nonce support because it would eliminate their speed advantage. Which means they are susceptible to replay attacks, which means they are dangerous tools to be swinging around blindly, which means that the old local session storage strategies are still far superior from a security perspective, which all means that you should avoid cookie stores like the damned plague and stick to the old, traditional but secure session storage strategies we already have unless you a) are crazy or b) trust your colleagues (and yourself) not to screw it up.

Even without the security concerns, there is also another less critical downside to storing sessions in cookies which is that cookies have a storage limit of around 4KB. No other storage solution for session data should have that problem but you need to be aware of it anyway as using encryption may push you there sooner than the base data size might suggest (encrypted data size is usually larger than the original data). While noting this, you should never really hit that limit unless you are storing data there that you likely shouldn’t be anyway!

So, cookie based session storage: It’s very fast but lethally insecure if you store the wrong type of data. If you’re going to use it, make sure you keep a tight rein on what data is being stored.

Interfacing The PHP World Would Be Good

padraic — Wed, 26 Oct 2011 15:52:19 +0000

With some precious free time today, I sat down to read Lukas Smith’s Interfacing The PHP World. It was good timing since last night I heard someone complain, again, about tight coupling in Zend Framework so I was in a good frame of mind to digest the blog post.

Before we start, tight coupling exists in a scenario where any one class relies upon another concrete class type (usually enforced using type hinting). Because the coupling is between two concrete classes, the only way to bypass it is through monkey patching the dependent class. Monkey patching has long been the lazy option for fixing stuff in PHP and we’re trying to get away from it. Loose coupling, on the other hand, exists when a class is dependent on an interface. Because we can write any class that adheres to that interface, we can inject any class we can imagine so long as it implements that interface. This is a far simple and maintainable situation since a) we are favouring composition over inheritance and b) there’s no fracking monkey patching!

The common denominator in loose coupling is therefore ensuring your dependent classes accept any dependency matching an agreed interface. Question: Whose interface are we agreeing on?

Every PHP framework has it’s own unique set of interfaces for common operations such as logging, caching, http clients, filtering, validation, etc. This creates a situation where a framework tends to be loosely coupled but only within the scope of its own interfaces. Thus, Symfony 2 components using HTTP can’t simply swap the existing client for Zend\Http\Client. Symfony 2 and Zend Framework 2 do not abide by an agreed interface – they have two distinct and incompatible ones.

Loose coupling is therefore a bad joke. It is a narrowly defined concept usually described within the scope of one particular application. We never really apply the concept across multiple applications written with different frameworks because, at that point, the disparate interfaces of both frameworks would immediately make loose coupling unobtainable.

That is the crux of Lukas’ idea – and it’s a really good idea. More interestingly, it’s almost an even better idea for Zend Framework 2 than Symfony 2. Zend Framework would benefit even more because we also distribute scores of component libraries and the interfaces relied upon make using Zend Framework components almost certainly contingent on the use of many other Zend Framework components to meet dependencies.

A simple example is Zend\Feed\Reader. For want of an agreed HTTP Client interface, we’re stuck with using…Zend\Http\Client. You could use Symfony 2′s client but then you’d need to create an abstract class to mediate between that client’s methods and the mismatched interface implemented by Zend\Http\Client. The result is therefore obvious – it requires more work and you’ll probably end up using both HTTP Clients rather than taking the hard road. Throw in a few more framework odds and ends, and you can be putting a lot of duplicated functionality to work just because they won’t speak the same language.

This is actually a bad deal for PHP programmers. Instead of one common interface for HTTP Clients, you have dozens. They won’t interoperate, they can’t be swapped for each other, and they directly encourage framework specific implementations instead of interface specific implementations (i.e. with common interfaces the need to duplicate functionality because of NIH Syndrome might be significantly reduced). You’re also forgetting those libraries who feel compelled to internally and eternally duplicate HTTP client functions rather than simply depending on a preferred client using a common interface. Not to mention half those mini-clients are poorly written and tend to disable SSL certificate verification because they can’t be arsed about handling the errors from invalid certs even if it does amount to putting your users’ private data at a real risk of being compromised.

The detractors from Lukas’ proposal may point to Java (since it’s the antithesis to everything PHP except the PHP OOP syntax ). While a worthy scapegoat, Java lives in a whole other environment. The scary Enterprise world. There, common interfaces are not merely programming conveniences but a business necessity. Competing products can gain a competitive advantage if they can replace a competitor’s product, service or middleware with a minimum of fuss. One way to help achieve that is to fund, support and advocate common interfaces for a variety of purposes. Not to mention it still benefits start ups since they already have the template for what to implement. It’s no wonder you see these debates stocked with members from competing companies actually cooperating so they have the future opportunity to back stab each other with one less barrier .

Those detractors are not necessarily wrong either. On the web, history has favoured programming languages which are practical and flexible. PHP is an unstoppable force of nature for all that other language users criticise its sense of source code aesthetics. Ruby survives primarily because it has a popular framework built using the language. Javascript has proven invaluable for client side execution, and is even moving to the server side with developments like node.js. Python is, well, Python. How can you not like it (weird indentation aside)? Java, on the other hand, has declined in the web space and it’s sole remaining hope for a revival is greater adoption of the JVM for deploying the results of other languages boiled down into Java bytecode. Flexibility in setting interfaces would be important but that is a bit nonsensical when the adopters are frameworks who feel the competitive pressure to continually evolve…rapidly…and eek more sense out of PHP ugliness.

Then again, do I really want my baby, Zend\Feed\Reader, injected with Symfony 2 classes? It even sounds dirty. Filthy Symfony 2 classes (Zend Framework, my precious! Gollum! Gollum!). Yet, that’s the only real reason not to want common interfaces. By making your classes more accessible to the competitions’, you risk being commodotised as programmers mix and match from a selection of notable libraries instead of being hogtied to just a handful of sort-of-loosely coupled frameworks. Then again, HTTP Clients are already a dime a dozen. The real goal of competitiveness is having a better overall implementation in terms of features and all the other important stuff that meets the needs of the users you are targeting (this doesn’t include useless benchmarks though those do make a great butt for jokes).

So yes, common interfaces would benefit PHP and would make framework libraries more interoperable and thus usable within competing frameworks. Hey, if you can’t beat them at least make sure you can inject your classes into them. Hmm, still sounds dirty.

Zend Framework 2.0: Dependency Injection (Part 2)

padraic — Wed, 12 Oct 2011 14:20:20 +0000

Image via Wikipedia

In Part 1 of this miniseries, I expounded (it’s better than exploding) about Dependency Injection (DI) and Dependency Injection Containers (DICs). To summarise, DI is an obvious and ubiquitous design pattern used daily by most programmers to allow objects accept their dependencies from an external agent (e.g. a unit test which needs to inject mock objects). In an application, the ideal external agent is some container that can assemble objects on demand and create the necessary object graph from scratch outside of the application’s control flow. It is this object assembly function that can be fulfilled by a DIC.

For Part 2, we’re going to dig more into what a DIC is and isn’t. I’ve already noted one very simple DIC called Pimple which will continue as one of my reference points since it best illustrates just how simple a DIC can be. In Part 3, we’ll (finally) turn our attention to some actual source code. Baby steps. Parts 1 and 2 should get you thinking so that ZF 2.0′s DIC is a lot easier to understand and critique. We don’t want anyone panicking just by throwing them into the deep end .

Make sure to read Part 1 if you haven’t already!

Things Which Are Not A Dependency Injection Container (DIC)

Now, in explaining a DIC it’s worth noting there are related solutions which you should find very familiar.

You could use lots of Factories (classes or methods on a class in which the logic necessary to create an object is packaged for reuse). If you followed Part 1, you’d soon realise that the Pimple DIC, as simple as it is, looks very much like a collection of Factory Methods (as Closures). Zend_Application also appears to use Factory Methods or Classes to generate its resources. Along this line of thinking, a DIC is a container of executable Factories. These tend to be the simplest kind of DICs since they rely on source code instructions which can be combined in sequence to assemble a final dependent object and its injected dependencies.

The differences however all come back to the concept of an “external agent”. Factories are traditionally executed within and by an application object whereas a DIC operates from outside an application. Since this is a simple inversion of control, DICs following this mechanism can be written over a coffee break since it’s just a matter of aggregating and mixing Factories – or you can just standardise on Pimple .

Another possible solution is to use a Service Locator. This is often interpreted as an object which can create and retrieve objects. The Service Locator is injected into dependent objects as needed so they can lookup their own dependencies. For example, in our earlier Leprechaun class example from Part 1, we could have created a Service Locator capable of creating Pot classes, injected it into Leprechaun, and allowed the Leprechaun class to lookup whatever Pot it needs.

This too looks very similar to how a DIC appears to operate. It’s also similar to a Factory Class except it can construct many kinds of objects instead of just one particular type. A Pimple container, for example, can be passed into other objects which in turn can ask it to retrieve necessary objects or dependencies. The same holds true of Zend_Application’s resulting bootstrap object. So, in yet another line of thinking, a DIC is always a potential Service Locator – the difference is that we generally don’t inject DICs into dependent objects but allow the DIC create the dependent object from the outside (i.e. it’s an external agent).

In summary, a Dependency Injection Container is not simply a standalone invention – it’s a combination of a few well known patterns we use in PHP that, when combined, create something greater than its individual (and obvious) parts when acting solely as an external agent. That helps explain why most DICs you look at feel a bit too complex. You might see the simple task it performs but not quite grasp why it needs to be so complex until you realise it’s a combination of patterns. We’re used to seeing the constituent patterns isolated and scattered across our application – not brought together in one single entity.

The primary differentiating factor from the simpler patterns, especially Service Locators, lies in one simple concept: Is our DIC truly an external agent? All other solutions tend to require the container to be an internal agent, i.e. a dependency of other objects. Service Locators are injected into dependent objects, and Factories are called from dependent objects.

External Agents See The Bigger Picture

The ideal DIC is an independent external agent. I use the term “external agent” a lot because it’s a good description that’s easy to grasp. The idea is that the DIC creates all other objects, and their dependencies, and will inject the correct dependencies into the right dependent objects. In other words, it’s a master manipulator orbiting our application but not actually embedded in it. In a framework, it would be used to create almost everything without the rest of the framework even being aware of its existence. Nearly all other possible solutions can’t operate in this fashion. A Service Locator must be embedded into other classes and Factories are all called from within other classes too, i.e. they are internal agents…not external.

Now, programmers have two fundamental questions when it comes to basic OOP:

1. Where do I create objects?
2. How do I transport objects across application layers?

DICs answer the first question. You can create objects using a DIC which is independent of the application. It’s our external agent. They also answer the second question. In applying Dependency Injection, your DIC knows how to inject dependencies into the objects needing them, even if those objects come from different layers of the application. This should render the need for Service Locators, Factories, and the always popular Registry pattern almost defunct.

This is what makes the concept of Dependency Injection and DICs useful in frameworks. If you’ve ever used Zend Framework before the arrival of Zend_Application you’ll be familiar with the two questions from above. Creating and transporting objects was an unanswered question at the time, with users running in all directions using Registries, Service Locators, In-Controller instantiation and bootstrap instantiation (mixed with non-static Registries and the handy FrontController parameter transport) – and that’s just the generic groups. In reality, people developed dozens of varying implementations on these themes. This lack of consistency was an irksome problem. By implementing good DICs, both Symfony 2 and Zend Framework 2.0 have settled on one consistent direction.

However, using a DIC in its designed role requires something of a leap of faith. PHP programmers use Service Locators, Factories and Registries all the time. We’re comfortable with those patterns and many of us will always crave their simple natures even when we understand why Dependency Injection is a better solution. This craving can end up corrupting the idea of DI by implementing a common antipattern: turning the DIC external agent into an internal agent.

DICs As Dependencies Are Evil: They Are Not Service Locators

For example, bearing in mind my earlier creation/transportation question duo. Let’s say we create a NewsletterController in a Zend Framework 1.x application using a DIC like Pimple. Our Controller requires an instance of Zend_Mail for its emailAction method. How do you get the Zend_Mail object into the Controller? Well, using Dependency Injection the answer is very obvious – you define either a setter, a constructor parameter or a public property on the Controller class. Then you can program Pimple to a) create the Zend_Mail instance, b) create the Controller and c) inject the Zend_Mail instance into the Controller (e.g. using a setter method). Creation and transportation are neatly solved. The best part is that none of the participants are aware of the DIC, the acid test being that anything a DIC can do, you could have done it by hand without a DIC (hint: a DIC can replace a lot of what ZF users would normally call bootstrapping).

Both Zend Framework 2.0 and Symfony 2 optionally allow another possibility. When we create the NewsController, we can inject the DIC into the Controller itself. This would allow the Controller to lookup resources from the DIC instead of the DIC injecting them from outside the Controller, i.e. our external agent just became an internal agent.

The switch may appear very convenient and comforting. Instead of all this running around with a DIC magically creating Controllers, you could have a typical Dispatch/Execute cycle and add the code for object creation/retrieval into your Controller actions. This has benefits – object creation is clearly visible in all your controllers. However, your intuition is slightly off base.

Firstly, this isn’t Dependency Injection. Our dependent objects have now internalised dependency creation. Since it’s not DI, a DIC is obviously a misplaced tool. So instead of a DIC, you are actually mutating it into a Service Locator. The side effects of eliminating DI are to make it harder to understand dependencies (not easier as you might suspect!). A Service Locator just needs a name to lookup – there are no setters or constructor parameters with typehinting or useful Docblocks to refer to. So your intuition was wrong – it might make your life easier, but everyone else who lacks your familiarity with the source code you’re writing will spend a lot of time dissecting your DIC to figure out what the concrete dependencies really are. Yes, it’s the age old justification for many practices these days – ensuring the long term costs of change are minimised.

Secondly, it creates objects which are useless without the specific DIC interface it depends on. Given an application tends to use only one DIC, importing classes from other sources which need a completely different DIC in order to work is a PITA. Classes which don’t need to be framework specific MUST NEVER be framework specific (i.e. frameworks all use different DICs and depending on one excludes using your classes with another). If classes are DIC specific – you have done something horribly wrong in practicing OOP (and by extension DI).

This is very similar to my past arguments as to why my idea of Zend Framework Modules does not include Libraries/Components. Apples and oranges. Putting a generic library into any form of framework specific packaging or tying it to a framework specific import/DIC mechanism is just plain wrong if it restricts reuse outside of your preferred framework. It gets a lot worse should such dependencies expand from your Controllers (where they could be restricted in practice) to your service/model layer which shouldn’t be aware of the framework at all!

Thirdly, DICs are really bad Service Locators. Since your average DIC likely knows almost everything about objects in the application across multiple application layers (by design since it’s an external agent with that specific purpose), any object into which a DIC is injected might now have access to any other object the DIC knows about. This is crazy. If every object can access every other object, it will result in the same thing as having every function able to access every other function (which we endured before PHP got a good OOP model): Spaghetti Code.

Then again, the Flying Spaghetti Monster might be offended by good OOP…

The potential for enabling Spaghetti Coding, DIC/framework specific dependencies, and elimination of Dependency Injection practices are all serious issues – which is why injecting DICs into any other object outside a controlling bootstrap mechanism used to initiate the DIC and get your MVC framework prepped is referred to as an anti-pattern by some. It’s a Bad Thing.

Why Do Frameworks Enable Bad Practice?

Why is water wet? Frameworks operate to a specific set of needs: a compromise between the ideals of the developers and the needs of the users. The goal of a framework is not to hold your hand 100% of the time but to offer an opinionated (all of them are to some degree!) framework which developers hope is capable of meeting a broad set of user needs so that you can get your application off the ground on the cheap and focus on developing your application’s model. Since many PHP programmers will very quickly want the DIC-Injection anti-pattern, frameworks will inevitably offer it. It may not be considered good practice, but it’s one that nearly all PHP programmers have used to some degree. The trick is knowing whether the cost is worth it and, if not, how to opt-out of (or avoid opting-in to!) the anti-pattern.

If it makes you feel any better, framework developers spend an inordinate amount of time debating similar topics. We’re not out to hang you but compromise and education are often a better solution to being overly restrictive. In reading this topic, I hope this little slice of education will inform you on future decisions around how to recognise, implement and use DICs. Even if you wrote it over your coffee break.

In any case, in Part 3 we’ll meet Zend\Di. Code at last .