My introduction

[Chris Cornutt]

Hi all, just wanted to chime in with my own introduction...I've been doing the PHP thing for 10+ years now and only within the last few years have I taken much interest in the security of things. Sadly, I think  there's a lot of developers out there that don't even get to that point. I think a lot of them either think "no one cares enough to hack me" or "only large companies need to worry about security"....until they're proved wrong (Timthumb anyone?)

I'm in agreement with Paddy, though - there's a lot of people out there talking about good PHP security (myself being one of them) and not much doing anything about it. If I see one more "OWASP Top Ten in PHP" articles, I think I'm going to have to hurt someone ;)

I'm trying to create a resource that can be used in compliment to Paddy's security book as a source for smaller chunks of information over an entire wholistic resource - http://websec.io. I've written up most of the articles myself, but am always looking for good, informative content to put there. 

Thanks all and I'm looking forward to what this group can do in the future! I think having a good core group can go a long way to helping both the PHP community and its developers write better, safer code.

--
Senior Editor
PHPDeveloper.org
ccor...@phpdeveloper.org

@enygma

[Evert Pot]

On Sep 5, 2012, at 1:57 PM, Chris Cornutt wrote:

> Hi all, just wanted to chime in with my own introduction...I've been doing the PHP thing for 10+ years now and only within the last few years have I taken much interest in the security of things. Sadly, I think there's a lot of developers out there that don't even get to that point. I think a lot of them either think "no one cares enough to hack me" or "only large companies need to worry about security"....until they're proved wrong (Timthumb anyone?)

I also think this is a problematic, or at least not a pragmatic way of thinking.
One of the common wisdoms of security, is that everything can be broken.

If this means that every system can (and will) have security holes, it also implies that we can spend a theoretical infinite amount of time attempting to make things more secure.

In daily life the unfortunate fact is that deadlines need to be hit, and things need to be done. Shortcuts have to be made from time to time, even if this would anger the fury of the purists.

The hard part is determining this balance. When is it worth plugging a hole? when can you make the decision that feature X or product Y is under the radar enough, it's not an immediate threat. Maybe the potential exploit is actually not damaging enough to make it a priority.

Doing a great job explaining people what the various risks are, and the potential side effects is important. As long as people understand the various vectors, they can do a much better job making this judgement. If this were not true, there would be no market for virus scanners, firewalls or (dare I say it) WAF's.

Not at all arguing against you Chris though, I just felt like rant ;)

Evert

P.S: Everybody should start using Content Security Policy TODAY! If you don't, you suck :P

[Chris Cornutt]

Actually, seems more like you're agreeing with me ;)

So, call me optimistic, but I think that it's possible for security minded thinking to become more ingrained into the PHP culture in the same way that some of the best practices that we have for other aspects (like the PSRs or abstraction layers) have a permanent seat at the table now.

Don't get me wrong, I know it's an uphill battle, but I think there's been too little offense and too much push to make this sort of thing happen. 

-chris

--

[Pádraic Brady]

Hi Evert,

There certainly is a balance out there. Some security vulnerabilities are more annoyances than catastrophes, or require more financing than it would cost to suffer an attack. That said, there are two other considerations before we get to determining when the balance is sufficient:

1. What is the minimum level of security to implement?
2. At what point have we done enough that attacks can be blunted/mitigated?

It's probably not entirely apparent from my blog posts, but the book I'm writing does far better at hinting at those. Incidentally, http://phpsecurity.readthedocs.org for those on the list who haven't found it by word of mouth yet (it's a WIP).

In observing PHP (been using it since '97/'98) we have serious ongoing problems with both. There are continual errors made in reaching a minimal security defense. I could name names but this is based on tools/libs built by professionals that are either growing popular or new enough to be in my recent memory.

Secondly, programmers underestimate potential damage all the time. It's one reason why alert(document.cookie) is such a funny XSS example. Just use HttpOnly flags for your cookies. Swap that for something realistic, however, and you should see jQuery, XmlHttpRequest, Prototype and other libraries being used by the attacker. Who needs a cookie, silly, when you can just get the user to instantly make all the requests you can dream of? Another component of underestimating damage, is that programmers don't always get the concept of "attack chains". One small vuln can be leveraged to use another, then another, and then...boom. (Recent discussions re XML External Entity Injection show signs of this.)

Everything CAN be broken. There are new exploits and tools by the week. Security is a fast-paced business with white and black hats racing to find new ones. There IS a balance to consider also. However, I do think PHP suffers from a disconnect in figuring out what that balance is and often ends up setting it far too low.

And...now I'm blogging on a mailing list again ;).

You end point is spot on, Evert - we need to be able to explain the risks, attacks, etc in a way that makes them understandable. Too often we use simplistic or obvious examples that don't communicate this properly, or communicate it as something silly that shouldn't be worried about.

Paddy

[Chris Cornutt]

I totally agree - I think the "attack chains" idea is something that hasn't been touched on hardly at all. I think out of the 100s of blog posts I've read over the years, there's maybe one or two that even mentioned the fact that "this attack could lead to this attack" sort of thing. I hate that most things are presented in isolation from PHPers ("prevent XSS!", "prevent CSRF!") and not in context. I wonder if there's a way to say "if you're vulnerable to this, here's other things to watch out for...

-chris

--
 
 

[Sky Gunning]

Hello

Evert, this :

Too often we use simplistic or obvious examples that don't communicate this properly, or communicate it as something silly that shouldn't be worried about.

Thats one of the ig problems.
Lots of information out there ... but not for situations ... its just a example of some "potential situation" and often far to simple to be usefull.

I have been looking around for ideas on how to store passwords...
Lots of good information out there, but no good examples on how to implement the solution according to the 'hole picture' (server settings, php version, etc...)

Sky

--
 
 

[Pádraic Brady]

It's understandable to a point. Look up @troyhunt on Twitter whose blog does a good job at dissecting website security around SSL. Teasing out the details and linking them together to show how a seemingly small issue can spiral into a serious attack (with a little public info and social engineering thrown in) isn't easy but we need more of it articulated in PHP.

I should probably mention that Troy is an ASP.NET developer. Try not to hold it against him ;). He's worth a follow on Twitter.

Writers (esp. some of those big article sites) have a tendency not to look outside the box for new knowledge to import into PHP. PHP, Ruby, Python and Java are all in the same boat with web applications - they all have evolved varying approaches of value worth consideration.

Also, re websec.io - it's a cool resource for articles. I'll "spam" it every now and again on Twitter and look into contributing a couple myself ;).

Paddy