application security

Social Security

Let me preface this by saying I think that sharing knowledge and experiences is a great thing. I love that there’s so many tutorials out there from people showing good practices in security and things they’ve learned along the way. Unfortunately, this is the same place where I see a major downfall. This kind of “social security” is a problem and it needs fixing so secure application development can really thrive.

Technology is great, especially PHP. Sure, there’ll be haters out there and they’ll throw stones at the glass house that is PHP hoping to break down the walls and push it off away from the public eye and into the “Not A Real Language” world. Fortunately, this will never happen especially with more recent improvements to the language and its consistent popularity among web developers. PHP is both easy to pick up but difficult to master, especially when it comes to the security of the applications written with it. Along with this low barrier for entry comes people sharing things either in tutorials or just articles that they’ve found to be useful or think is a good practice. The web is littered with articles like these, some being a bit more factual than others. *This is where the real problem is.*

Well-meaning developers post tutorials about things like preventing XSS with just htmlspecialchars or only fixing SQL injection with prepared statements and bound parameters. While these are good practices in themselves, they’re not the only thing that needs to be done to prevent these issues. Security is a complicated subject and there’s no one answer to any problem. Usually a robust solution involves multiple layers (defense in depth anyone?) to ensure the problem doesn’t pop up again or in another location. Even worse are the numerous older articles posted around the internet that have bad or old information. Sadly I see some of these that are *years* old being recommended as good resources to learn from.

I see two kinds of resources out there:

  • Those that are posts from individuals or groups and are wholly maintained by them
  • community resources such as the OWASP wiki

I’ve done some picking on OWASP in the past about the quality of their PHP materials and what seems to be their general feel around PHP and PHP-centric security. This time, though, I don’t want to talk as much about their content itself but about the process they follow for generating that content.

I appreciate what OWASP is going for application security, I really do, but I think the “everyone can edit” mentality of their content is very flawed. I know it’s just not feasible for a single organization largely made up of volunteers to manage and audit all of the content on their site. I get that, I really do, but when I see people referring to PHP resources that haven’t been updated since 2006 or 2007 it makes me cringe. And, because of the visibility of the group, those are the resources people find and recommend not knowing any different.

I think this is the crux of my opinion – having resources where anyone can contribute and not auditing those resources is a “Bad Thing” in my book. Unfortunately, in the case of the masses of tutorials posted out on the web, there’s not much that can be done about that. Those are there to stay and search engines will continue to ensure they show in results regardless of their quality or relevance to the current state of things.

I’m not saying I want people to stop contributing here, I just think there needs to be a balance. There’s a lot of regurgitation of the same kinds of advice out there (“let’s rehash the Top 10 again…”) but there’s also a lot of more innovative content that gets deeper into PHP security matters beyond just the prevention of the most common issues. In my experience, PHP developers are becoming more and more savvy about the security of their applications (even if it is a “negative deliverable” so to speak) and require tips and techniques beyond these simple ten point checklists.

Unfortunately, there’s just not a good answer here. As long as the web continues to be a free for all in terms of posting content developers will keep posting the same things or they’ll post bad suggestions (or ones that just don’t make any sense). The only thing I can think to do is to offer advice to those doing research or reading through PHP security content to ensure they’re getting the best information they can:

  1. Check the article date. If it’s older than 9-12 months, close the tab and move on. That’s not content you need to be reading.
  2. If the content talks about “preventing the most common vulnerabilities” in PHP applications, chances are it’s just another Top 10 article. If you know those already, skip it.
  3. Favor articles with links from things other than search engine results. If you come across an article from a recommendation on another non-linkbait site chances are the content is at least mildly useful.
  4. Consider the source. Do a little research on the author, if they don’t have much of a presence on the web around PHP-related things either take the advice with a large grain of salt or move on.
  5. Look for things that are well-written. Chances are if something is easy to understand or provides plenty of technical detail (and less hand waving “do this not that”) you’ve found something worth reading through.

These are just guidelines, obviously. Ultimately it’s up to your best judgement and research skills to determine the validity of the content and if it applies to your situation.

Developer Security Outreach

I’ve been thinking a lot lately about how to try to bring the security and development communities together, most specifically for PHP (see these two posts for more on that). PHP has a long standing reputation for being an insecure language that it’s had to overcome. I like to think that evidence in more recent years is helping to dissuade that, but it’s an uphill battle. Anyway, that’s not what I’m hear to talk about. True to the title of the post, I want to talk about developer outreach as it relates to security and secure development practices.

While comments were made on my two previous post about the relationship going both ways, I want to focus in on things from the perspective of the organization with the bulk of the knowledge – the application security group/company. Yes, it’s good for developers to contribute back to shared resources so both parties can benefit, but with so many new developers coming to the language every day, I see a real need for engagement. There are a lot of groups and individuals out there on the security side that specialize in training and resources to help developers write their code more securely. They provide training classes and white papers on new technologies that can be used to get the ideas across, but usually only in a limited fashion. They write blog posts about the latest exploits and vulnerabilities or even speak at conferences with case studies and their own real-world experience in the world of application security.

So, take a step back – do you see a problem with this model? Most of these things I’ve listed involve talking at the developers and not with them. Sure, some of the training classes are more hands-on and can be much more effective at getting the speaker’s ideas across. However, these kinds of resources are mostly provided if requested or actively sought out by the developer. There’s a wealth of information out there about securing applications, even PHP ones, that’s tucked away and only shown when the right Google search is performed.

Is there a solution? In thinking about it some this morning, I see a pretty obvious one – developer outreach. I’ve mentioned this same idea before in another post, but that one was more targeted towards the OWASP group and the services/resources it provides. It still surprises me when I ask in my sessions at PHP-related conference how many people have heard of OWASP and some hands go up but a lot don’t. Likewise, there’s a lot of companies out there that provide application security training (such as the Denim Group, WhiteHat Security or even SANS) but those are still presented as passive resources. Developers, by their nature, are notoriously lazy. They try to find the most efficient, most robust solutions to problems. How much would they benefit from someone from the Denim group reaching out to them or even just the PHP community as a whole and sharing what they have to offer.

Am I suggesting they hop on the various community mailing lists and start spamming them with ads for their training courses? Of course not. Here’s what I am proposing:

If you provide training, resources or any other kind of resources that developers could benefit from to create more secure applications, find an advocate (or a few) in the community of your choice and request their help to get the word out. I’d even go so far as to suggest having someone dedicated to working with communities, maybe even different people for different communities. This person should be dedicated to not only sharing what kind of things the company/group has to offer the developer community but to also act as a guide to keep them on the right path.

There’s a security subculture in just about every language out there. The key for those with the security knowledge and resources to do is to tap into it. Break into the community with a sense of humility, an open mind to learn about its members and a passion for teaching and sharing knowledge on a personal level.