And finally there has been some actual move­ment on secur­ing up the Zend Frame­work in an proac­tive fash­ion (at least from now on:) )

As announced ear­lier by Matthew, Zend Frame­work 1.9.7, 1.8.5 and 1.7.9 have been released incor­po­rat­ing rou­tine main­te­nance and a num­ber of secu­rity fixes detailed in the announce­ment. It's rec­om­mended that frame­work users upgrade as soon as pos­si­ble to the lat­est release of whichever of these minor branches they are using.

As the announce­ment also indi­cates, fol­low­ing December's excite­ment I spent much of the Christ­mas and New Year period con­duct­ing a secu­rity review of the frame­work. While an ongo­ing process, the ini­tial review focused on spe­cific areas most likely to deal directly or indi­rectly with user input and the out­put of user sourced data. The results of that ini­tial review were reported over the hol­i­days to the Zend team, who patiently put up with my long winded emails and man­aged not to stran­gle me…so far. I'm keep­ing myself holed up in the moun­tains for now .

The review also included an exam­i­na­tion of all new com­po­nents due to enter ser­vice with Zend Frame­work 1.10. This yielded a num­ber of issues whose fixes will pre­empt their release into a sta­ble ver­sion, and have been reported to the rel­e­vant lead devel­op­ers. These will not be dis­closed at this time, and will not form any new advi­sories for the sim­ple fact that ZF 1.10 cur­rently exists only as an alpha release where issues are to be expected any­way. Regard­less, you all owe me extra cook­ies for those .

On to the vul­ner­a­bil­i­ties, the major­ity are linked to encod­ing incon­sis­ten­cies. One of the more far-reaching results of the fixes is that all devel­op­ers should note the Zend Frame­work now enforces a default char­ac­ter encod­ing of UTF-8, includ­ing Zend_View which until now has defaulted to ISO-8859–1. This will require users need­ing that encod­ing to now set it man­u­ally. In addi­tion, numer­ous classes have been given meth­ods allow­ing devel­op­ers pass in their pre­ferred encod­ing. It's essen­tial you do so to ben­e­fit from the full pro­tec­tion of all escap­ing mech­a­nisms using html­spe­cialchars() and htm­len­ti­ties(). The remain­ing vul­ner­a­bil­i­ties are self-explanatory and, besides upgrad­ing, require lit­tle addi­tional work on your part.

It's also impor­tant to note that these fixes often go beyond fix­ing the imme­di­ate symp­toms. So reporter's credit aside, thanks to Matthew, Ralph and Thomas Wei­d­ner who worked on the patches for these fixes as well as spend­ing the time dis­cussing and debat­ing them all in turn. I'm sure Matthew and Ralph had lots of fun (in between apoplec­tic fits) prepar­ing for three releases but it's truly appreciated.

I remem­ber from Decem­ber (when not rant­ing ), that one of the iden­ti­fi­able prob­lems with the Zend Frame­work was its over­all secu­rity strat­egy which has been reac­tive in nature. The rea­son for per­form­ing this secu­rity review, in addi­tion to find­ing it excit­ing to spend hour after hour star­ing at source code (I'm being sar­cas­tic), is that my orig­i­nal rant was mis­di­rected in one aspect. If the frame­work is reac­tive, it is because every­one who con­tributes source code also con­tributes to that par­tic­u­lar atti­tude. Per­form­ing the review was one way of break­ing the reac­tive trend, and so instead of hav­ing these secu­rity issues per­sist into the framework's future ver­sions to be dis­cov­ered by acci­dent (or not), they have been delib­er­ately searched for, found, poked, prod­ded, debated and then duti­fully exter­mi­nated. Wel­come to proactivity.

If there is a point, it is that as Zend Frame­work con­trib­u­tors it's still ulti­mately our job to enforce and pro­mote a secu­rity aware­ness. We can't pass that respon­si­bil­ity to Zend (all of three employ­ees) and wave our hands inno­cently. We now have two new jobs we bet­ter get used to. The first is apply­ing the new Secu­rity Pol­icy and noti­fy­ing the secu­rity chan­nel of any reported or self-discovered secu­rity issues. Don't sit around won­der­ing if it's a prob­lem, send it in and let the guys look at it. That goes for all secu­rity issues with­out excep­tion (or should). Sec­ondly, we need to build some sem­blance of a secu­rity con­cious­ness because at present that is sorely lack­ing. I believe the Zend guys are on a sim­i­lar track here so they may have more to say in the near future. I'll doubtlessly blog about these two top­ics more specif­i­cally over the next few days.

In the mean­time, you have some new releases to work with . I sunk a lot of time into this, but being an open source project it's only right you exploit that for all it's worth .

via Mau­grim The Reaper’s Blog.

More From HackIX

• Zend Stu­dio code for­mat­ter for Zend Framework
• Deep Inte­gra­tion between Zend Frame­work and Doc­trine 1.2
• Zend Frame­work — Report­ing Poten­tial Secu­rity Issues

Ask HackIX To Rec­om­mend Your Posts

Tags: Security, Zend Framework

This entry was posted on 13 January, 2010 at 01:25. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.

Posted in Development Security Zend Framework by Danny Froberg No Comments Yet