Wanted: ZF2 Security Guide Editors/Contributors

[Pádraic Brady]

My fellow minions,

I've been tasked with putting together a Security Guide for Zend
Framework 2.0. United under the boot of our Glorious Overlord, Matthew
Weier O'Phinney, we will ensure that our users do not contribute to
the overload of SQL Injection and Cross-Site Scripting attacks that
web applications suffer. At the same time, I've brushed the dust off
an old project I abandoned a year back when family obligations took me
away from open source for a while. That project was to compile a
reasonably complete reference book on security in PHP. Since I'm
loathe to throw away that effort, and writing long blog posts and a
completely separate ZF2 guide largely replicates its purpose, I'll be
publishing this (freely online) in the medium term independently of
Zend Framework.

My proposal is that the drafted copy of this book be re-edited to fit
within any narrower confines needed for a shorter Zend Framework
specific guide. Some material can stay, some can be dropped and some
sections will likely need some redrafting with ZF2 in mind. The book
itself will be converted to be ZF2 oriented anyway so hopefully that
won't be a huge task. Preferably the result will be a simple subset of
the whole so future editing isn't a complex pain in the ass.

What I need from the community, and being conscious that getting out
ZF2 is a higher priority, are some volunteers to peer review the text
as editors. Anyone who wishes to step up and do more on the writing
side is also welcome. That will necessitate reviewing the book or full
guide text since that is what the ZF2 guide will be extracted from.
The format of the larger text will follow the Github model - I'll be
releasing it under a liberal license to allow for Pull Requests and
external contributions (while maintaining the role of editor in chief,
i.e. Dictator). It will most likely follow the doc format we're now
using to keep usage simple.

There are a few points to consider as a result:

1. How big should a ZF2 security guide be? Should it be allowed to
simply reflect the entire text or a subset?
2. Tying an independent security work in as ZF2's guide has both an
upside and a downside: On one hand it will reflect positively on the
framework but, on the other, the full text would not be subject to
direct ZF2 control outside of what the editors determine should be
extracted/changed for the ZF2 guide.
3. I'm grumpy and I won't hesitate to point out ZF2 practices I
consider substandard (just in case you don't know me!)
4. Licensing of the documentation and copyright assignment obviously
needs to facilitate the independent usage/editing of the text.
5. Apart from the Security Guide what standard do we hold each
individual component's document to in terms of passing on security
related tips?

If interesting in an editor role, you should be at least passably
familiar with security in PHP. I am hopeful that the full text will
attract even more involvement from the greater PHP community.

Thoughts?

Regards,
Paddy

--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team

[Artur Bodera]

On Thu, Jul 19, 2012 at 8:50 PM, Pádraic Brady <[hidden email]> wrote:

My fellow minions,

I've been tasked with putting together a Security Guide for Zend
Framework 2.0. United under the boot of our Glorious Overlord, Matthew
Weier O'Phinney, we will ensure that our users do not contribute to
the overload of SQL Injection and Cross-Site Scripting attacks that
web applications suffer. At the same time, I've brushed the dust off
an old project I abandoned a year back when family obligations took me
away from open source for a while. That project was to compile a
reasonably complete reference book on security in PHP. Since I'm
loathe to throw away that effort, and writing long blog posts and a
completely separate ZF2 guide largely replicates its purpose, I'll be
publishing this (freely online) in the medium term independently of
Zend Framework.

My proposal is that the drafted copy of this book be re-edited to fit
within any narrower confines needed for a shorter Zend Framework
specific guide. Some material can stay, some can be dropped and some
sections will likely need some redrafting with ZF2 in mind. The book
itself will be converted to be ZF2 oriented anyway so hopefully that
won't be a huge task. Preferably the result will be a simple subset of
the whole so future editing isn't a complex pain in the ass.

What I need from the community, and being conscious that getting out
ZF2 is a higher priority, are some volunteers to peer review the text
as editors. Anyone who wishes to step up and do more on the writing
side is also welcome. That will necessitate reviewing the book or full
guide text since that is what the ZF2 guide will be extracted from.
The format of the larger text will follow the Github model - I'll be
releasing it under a liberal license to allow for Pull Requests and
external contributions (while maintaining the role of editor in chief,
i.e. Dictator). It will most likely follow the doc format we're now
using to keep usage simple.

There are a few points to consider as a result:

1. How big should a ZF2 security guide be? Should it be allowed to
simply reflect the entire text or a subset?
2. Tying an independent security work in as ZF2's guide has both an
upside and a downside: On one hand it will reflect positively on the
framework but, on the other, the full text would not be subject to
direct ZF2 control outside of what the editors determine should be
extracted/changed for the ZF2 guide.
3. I'm grumpy and I won't hesitate to point out ZF2 practices I
consider substandard (just in case you don't know me!)
4. Licensing of the documentation and copyright assignment obviously
needs to facilitate the independent usage/editing of the text.
5. Apart from the Security Guide what standard do we hold each
individual component's document to in terms of passing on security
related tips?

If interesting in an editor role, you should be at least passably
familiar with security in PHP. I am hopeful that the full text will
attract even more involvement from the greater PHP community.

Thoughts?

Brilliant idea. It's greatly desirable for such reference material focused on PHP security to exist.

It's even more desirable for it to be ZF2-centered, though I believe there are statistically more broken web apps that do not use any framework at all, or use in-house solutions.

That said, I'd propose to make an attempt at creating (one of) the first _forkable book_. 

If we go Github style, I do not see any downsides of people forking the main book  and adapting it to Symfony 2, Cake, ezComponents and any other framework, library, CMS, CMF or other system out there.

As a trivial example, I'd invite you to imagine a chapter about escaping. The "main branch" book would go into the topic explaining attack vectors, providing sample PHP code and best practices using plain PHP functionality. 

A ZendFramework 2 fork would replace those examples with ones that utilize Zend\Filter, Zend\Validator. It would also detail ZF2 specific attack vectors and things to watch out for with ZF2 components (i.e. MVC, View, Db, rendered Form, etc.).

A Symfony2 fork would use their own components and MVC style, again relating to the same security principals, but from a S2-user perspective.

The "main repo" book should be complete, comprehensive and potentially verbose. The actual volume might differ from fork to fork - for example a lot of plain PHP code would be replaced by one-liners in ZF2 that provide same/better security, but that particular section might have more additional ZF2-specific tips. We might find forks to be smaller or bigger or comparable. The most important thing is for forks NOT to skew the original security issues described in the book, nor to selectively omit (ignore) included guidelines. A fork must be complete - in the sense that it must contain at the very least the original text and original plain php examples (until fork authors replace them with framework-specific stuff).

-- 
      __
     /.)\   [phone]
     \(./   [hidden email]

[Pádraic Brady]

Hey Artur,

On Tue, Jul 24, 2012 at 10:30 PM, Artur Bodera <[hidden email]> wrote:
> Brilliant idea. It's greatly desirable for such reference material focused
> on PHP security to exist.
> It's even more desirable for it to be ZF2-centered, though I believe there
> are statistically more broken web apps that do not use any framework at all,
> or use in-house solutions.
>
> That said, I'd propose to make an attempt at creating (one of) the first
> _forkable book_.

I'm hoping that forking will help improve the quality of the resulting
book, promote translations and so on. Also, I don't pretend to be an
expert in all security fields - an open book is perfect for allowing
other PHP folk with that expertise to put their own stamp of authority
on it. I haven't decided how to do final publishing offline - I joke a
lot about Macbooks but nobody writes books looking to make a fortune.
I'll figure out the best non-profit way of doing that. The book does
need to remain somewhat generic and it's unavoidable that some of the
material just won't be directly applicable to ZF2 anyway.

> If we go Github style, I do not see any downsides of people forking the main
> book  and adapting it to Symfony 2, Cake, ezComponents and any other
> framework, library, CMS, CMF or other system out there.
>
> As a trivial example, I'd invite you to imagine a chapter about escaping.
> The "main branch" book would go into the topic explaining attack vectors,
> providing sample PHP code and best practices using plain PHP functionality.
>
> A ZendFramework 2 fork would replace those examples with ones that utilize
> Zend\Filter, Zend\Validator. It would also detail ZF2 specific attack
> vectors and things to watch out for with ZF2 components (i.e. MVC, View, Db,
> rendered Form, etc.).
>
> A Symfony2 fork would use their own components and MVC style, again relating
> to the same security principals, but from a S2-user perspective.

It's possible, and they'll be free to borrow or rework the text as a
derivative work once it's out of initial draft. If nothing else it
should double as a PHP specific reference for security attacks. My
priority though is to wrap up the English text and hopefully get
translators involved. Code examples are rare at the moment since they
can be layered in at any future time easily.

> The "main repo" book should be complete, comprehensive and potentially
> verbose. The actual volume might differ from fork to fork - for example a
> lot of plain PHP code would be replaced by one-liners in ZF2 that provide
> same/better security, but that particular section might have more additional
> ZF2-specific tips. We might find forks to be smaller or bigger or
> comparable. The most important thing is for forks NOT to skew the original
> security issues described in the book, nor to selectively omit (ignore)
> included guidelines. A fork must be complete - in the sense that it must
> contain at the very least the original text and original plain php examples
> (until fork authors replace them with framework-specific stuff).

It will be reasonably verbose since there's a LOT of ground to cover
and I do call it a "book". I picked up a few samples of security books
in PHP a while back and some of them are atrocious in their coverage
of security issues. One of the most recently published copies actually
points users to a HTML Sanitiser that one of the authors created and
never mentions HTMLPurifier. Bad sign right there. I decided to follow
the sentiment of the OWASP Top 10 attacks instead since it focuses on
possible attacks (there are dozens) rather than on broad categories
which don't give a sense of what attackers can actually pull off in
reality and skips mentioning a ton of possible attack vectors.

I've so far drafted three chapters (Intro, Input Validation and
Injection Attacks) with a 4th on XSS in progress. If I can round out
those four, it should be enough to get it online and start GH's
hardcore forking wheel. That will let everyone figure out how to use
it in terms of offering a dedicated ZF2 guide. I decided to stick with
a continuing theme and title it "Survive The Deep End: PHP Security".

I may get hate mail from publishers selling security books for a
profit to PHP programmers though ;).

--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team

[Artur Bodera]

On Wed, Jul 25, 2012 at 9:17 PM, Pádraic Brady <[hidden email]> wrote:

I'll figure out the best non-profit way of doing that. The book does
need to remain somewhat generic and it's unavoidable that some of the
material just won't be directly applicable to ZF2 anyway.

That's why I proposed framework-specific forks. In that case, it does not have to be generic --- or, can be generic in theory and specific in implementation.

 

. My

priority though is to wrap up the English text and hopefully get
translators involved.

Good priority. I'll whip Polish translation in no time.

 

Code examples are rare at the moment since they
can be layered in at any future time easily.

That's bad. Learning by examples is VERY potent... to the extent, that sometimes I waste hours upon hours of explaining, with the knowledge then ending not being implemented or used in the wrong way... but after giving just 1 or 2 examples, people start "aaaah"-ing and the education can proceed.

 

It will be reasonably verbose since there's a LOT of ground to cover

and I do call it a "book". I picked up a few samples of security books
in PHP a while back and some of them are atrocious in their coverage
of security issues. One of the most recently published copies actually
points users to a HTML Sanitiser that one of the authors created and
never mentions HTMLPurifier. Bad sign right there.

That's actually quite interesting topic there. Considering the main book will be "generic" and will not be tied to any specific framework or tool, many tasks are simply not feasible (or difficult) with plain PHP. That means, it'd be best to recommend library X or component Y of framework Z.... but that hurts neutrality and framework Z-specific fork.

 

I decided to follow
the sentiment of the OWASP Top 10 attacks instead since it focuses on
possible attacks (there are dozens) rather than on broad categories
which don't give a sense of what attackers can actually pull off in 

reality and skips mentioning a ton of possible attack vectors.

But is that good ? I know it's possible to explain to the kid the dangers of cutting yourself with a knife, without actually cutting yourself... but without showing how the knife works and cutting an orange, that knowledge might not be fully digested.

Similar to your blog posts, it's quite easy to understand an exploit if you show a 3-liner which presents the exploit. Aside from "wow" moment (which is good for marketing) it gives you an actual working material and can, at very least, inspire you to try this particular attack on your real-world application --- and see what happens (learning by experimentation).

 

I've so far drafted three chapters (Intro, Input Validation and
Injection Attacks) with a 4th on XSS in progress. If I can round out
those four, it should be enough to get it online and start GH's
hardcore forking wheel. That will let everyone figure out how to use
it in terms of offering a dedicated ZF2 guide. I decided to stick with
a continuing theme and title it "Survive The Deep End: PHP Security".

Nice branding btw ;)

I may get hate mail from publishers selling security books for a
profit to PHP programmers though ;).

Probably not much more hate than blog-owners get from them. Book publisher is a dying concept, similar to newspapers, so it will happen whether they like it or not. There will still be a market for books and .... we could even try to cut a deal with some publisher, that'd be interesting in printing that github book and selling it for a low price, giving the profit to one of education foundations out there (there are a few that directly support teaching programming in underprivileged schools, for example).

Just a thought - not really about the money, but about the fact that some people prefer to have a printed copy, and some people seek knowledge in book stores. If such book was conceived, finding it on a shelve would just help spread (good, valuable) security knowledge to folks.

 

-- 
      __
     /.)\   [phone]
     \(./   [hidden email]

[Pádraic Brady]

Hey Artur,

On Fri, Jul 27, 2012 at 12:48 PM, Artur Bodera <[hidden email]> wrote:

> On Wed, Jul 25, 2012 at 9:17 PM, Pádraic Brady <[hidden email]>
> wrote:
>>
>> I'll figure out the best non-profit way of doing that. The book does
>> need to remain somewhat generic and it's unavoidable that some of the
>> material just won't be directly applicable to ZF2 anyway.
>
>
> That's why I proposed framework-specific forks. In that case, it does not
> have to be generic --- or, can be generic in theory and specific in
> implementation.
>> . My
>> priority though is to wrap up the English text and hopefully get
>> translators involved.
>
>
> Good priority. I'll whip Polish translation in no time.
>
>
>> Code examples are rare at the moment since they
>> can be layered in at any future time easily.
>
>
> That's bad. Learning by examples is VERY potent... to the extent, that
> sometimes I waste hours upon hours of explaining, with the knowledge then
> ending not being implemented or used in the wrong way... but after giving
> just 1 or 2 examples, people start "aaaah"-ing and the education can
> proceed.

It's a temporary situation. Blog articles can be written once and
published. This stuff needs to be drafted, re-drafted, edited, and
more gradually built up towards a final text. It's time consuming
whereas examples can be added after the fact quite easily once their
place in the text and the context is established. Also the writing
itself determines the examples so it needs to be completed first - and
what I'm including is getting fairly comprehensive:

1. Introduction
2. Input Validation
3. Injection
4. Cross-Site Scripting
5. UI Redressing

The Injection chapter has about 10 attacks of which SQL Injection is
just 1. Chapter 5 is barely even PHP related since UI Redress is a
browser issue which can only be partially mitigated with XSS defenses.

>> It will be reasonably verbose since there's a LOT of ground to cover
>> and I do call it a "book". I picked up a few samples of security books
>> in PHP a while back and some of them are atrocious in their coverage
>> of security issues. One of the most recently published copies actually
>> points users to a HTML Sanitiser that one of the authors created and
>> never mentions HTMLPurifier. Bad sign right there.
>
> That's actually quite interesting topic there. Considering the main book
> will be "generic" and will not be tied to any specific framework or tool,
> many tasks are simply not feasible (or difficult) with plain PHP. That
> means, it'd be best to recommend library X or component Y of framework Z....
> but that hurts neutrality and framework Z-specific fork.

HTMLPurifier is exceptional as a recommendation since it's the only
safe standalone HTML Sanitiser in PHP I know of. I documented the
flaws in common alternatives myself. I'd prefer not to recommend
though I may specifically tell readers not to use something.

>> I decided to follow
>> the sentiment of the OWASP Top 10 attacks instead since it focuses on
>> possible attacks (there are dozens) rather than on broad categories
>> which don't give a sense of what attackers can actually pull off in
>>reality and skips mentioning a ton of possible attack vectors.
>
>
> But is that good ? I know it's possible to explain to the kid the dangers of
> cutting yourself with a knife, without actually cutting yourself... but
> without showing how the knife works and cutting an orange, that knowledge
> might not be fully digested.
>
> Similar to your blog posts, it's quite easy to understand an exploit if you
> show a 3-liner which presents the exploit. Aside from "wow" moment (which is
> good for marketing) it gives you an actual working material and can, at very
> least, inspire you to try this particular attack on your real-world
> application --- and see what happens (learning by experimentation).

Examples will follow ;). One of the features I hope the book exhibits
is that it is oriented towards educating readers about how to conduct
attacks, how to combine them, how to defeat traditional entrenched
defenses, and how to combine PHP defenses with non-PHP defenses (e.g.
browser features, HTTP headers, Javascript framebusters, etc.).
Obviously, there will need to be examples - a lot of them!

>> I've so far drafted three chapters (Intro, Input Validation and
>> Injection Attacks) with a 4th on XSS in progress. If I can round out
>> those four, it should be enough to get it online and start GH's
>> hardcore forking wheel. That will let everyone figure out how to use
>> it in terms of offering a dedicated ZF2 guide. I decided to stick with
>> a continuing theme and title it "Survive The Deep End: PHP Security".
>
> Nice branding btw ;)

I suppose you're quite right, Survive The Deep End is trending towards
being my brand. I may alias my blog to it since it's been stuck on an
unused gaming domain since it started.

>>
>> I may get hate mail from publishers selling security books for a
>> profit to PHP programmers though ;).
>
> Probably not much more hate than blog-owners get from them. Book publisher
> is a dying concept, similar to newspapers, so it will happen whether they
> like it or not. There will still be a market for books and .... we could
> even try to cut a deal with some publisher, that'd be interesting in
> printing that github book and selling it for a low price, giving the profit
> to one of education foundations out there (there are a few that directly
> support teaching programming in underprivileged schools, for example).
>
> Just a thought - not really about the money, but about the fact that some
> people prefer to have a printed copy, and some people seek knowledge in book
> stores. If such book was conceived, finding it on a shelve would just help
> spread (good, valuable) security knowledge to folks.

Yeah, I just want to be sensitive. Effectively this will be an open
(sourced) book afterall and I'd like to have a hardcopy available for
those who really want one.



--
Pádraic Brady

http://blog.astrumfutura.com
http://www.survivethedeepend.com
Zend Framework Community Review Team