December 17th, 2012 — 12:59pm
My post for this year’s Web Advent was posted last night – Security in the Round. It’s a pretty high level look at something that’s easy for developers to forget about. To quote Bruce Schneier:
The mantra of any good security engineer is “Security is not a product, but a process.
It’s more than just designing strong cryptography into a system; it’s designing the entire system such that all security measures, including cryptography, work together.
It’s about people, networks, systems, hardware, processes….oh yeah, and the code. Don’t forget the bigger picture. I presented some about this (and other more PHP-related topics) at True North PHP, you can see the slides here.
Comment » | PHP, security
November 30th, 2012 — 3:35am
In my research and writings that I’ve already done, I’ve noticed something about trying to share helpful security advice to fellow developers – you can provide all of the code examples and describe the threats all you want, but the problem really boils down to two words:
Much like other development-related issues, there’s a lot of things you have to take into consideration when thinking about the security of your application. Code security by itself is good, and there’s some best practices for that that have been shared all over the web. Unfortunately, this only paints a small part of the picture. Web applications, by their nature, are really complex systems composed of multiple pieces of software all running together to make this useful, functional service for its consumers. If you’re a PHP developer, there’s things you can do to help prevent common attacks (like XSS, CSRF or SQL injection to name some popular ones), but unless you look at the bigger picture, you’re getting a false sense of security.
“But I’m only responsible for the code!” you say. You like the idea that your code can be as secure as possible by filtering output, escaping user input and using defensive coding techniques. You commit your code, run your tests and happily go about your business, thinking things are good. Unfortunately, if you don’t consider the ecosystem your application lives in, chances are you missed something.
I’m not talking about code challenges here – preventing things like XSS or SQL injections is relatively easy (as long as you know what to do). The problems I’m talking about are things that may be true for one environment but not for another – things like:
- Working with multiple databases and storing their credentials securely
- Effective logging to a remote syslog server
- Potentially protecting your data from a physical intrusion
- Working with sensitive data
- Bridging authentication/authorization across applications
- Concurrency issues coming from multiple installations of the same application
While a lot of these kinds of concerns revolve around the architecture of the application, developers still need to keep them in mind when creating their applications. At the very least, you need to keep these kinds of concerns in mind when writing your code. Like anything else, there’s ways to structure the code to make things like this simpler to change. The trick is to keep things loosely coupled enough to make life simpler down the road.
Comment » | Development, Opinion, PHP, security, websec.io
November 21st, 2012 — 3:28am
As anyone that’s been around the PHP community recently (within the last six to nine months) knows, Chris Hartjes has taken up the lead in an effort to increase awareness about unit testing – really testing in general – of PHP applications. He favors things like test-driven development and having good tests to back up and reinforce a good resulting product. I admire him for his efforts (including his book) and I wonder if this same movement could be used to help kickstart a security testing “revolution” in the PHP community too.
For a long time, PHP has had an unfortunate reputation as being an insecure language to develop web-based applications in. The language itself has very few built-in security features and favors offering the ability to plug in techniques and tools of their own to make things secure. Unfortunately, this leaves a lot of the beginner level applications wide open to potential attacks. Developers aren’t immediately given options to do things like filter their data or secure the data they’re storing in their sessions. Most developers that I know that are just starting out with PHP don’t even know these sorts of things need to be done. They blindly accept user data and expect that nothing other than what they’re wanting will come through. Sadly, this sort of thing has lead to this insecure reputation – bad code written by inexperienced users. One of PHP’s best attributes is its low learning curve…and also its worst.
Many developers don’t even realize the need for security in the code they write until it’s too late. One day they wake up and – either because something they’ve written has been hacked or they read an article that talks about it – realize that they’ve been blind about protecting themselves and their data from Those People out on the web. This usually seems to happen about the time that most of them discover frameworks and how useful they can be. They start poking around what the framework has to offer and come across things like access control, user authentication and yes, maybe even secure session handling. A switch is flipped and the developer reacts in one of two ways – they take it as a charge to get better about their secure coding practices or they freak out and start going crazy with filtering, encryption and escaping.
Back to my original point – I wonder if it’s possible to take this momentum that Chris has gotten going and use it to encourage more testing for the security of applications up front. I’ve been doing what I can over on websec.io to try to help educate developers about things like secure coding practices, common infosec terms and information about securing their applications from would-be attackers, but it’s not enough. It’s not even a blip on the radar in what is a very serious matter that should be a consideration for all PHP developers.
Testing application security early, whether it be through the use of something like skipfish or a static code scanning tool, can save you time in the long run, just as unit testing your code helps track down and eliminate bugs faster. I want to promote early testing for security issues in applications and the mitigation of them, but I’m not sure how to reach developers in a way that they’ll listen.
Pádraic Brady has started up an effort to create a guide to some of the most common issues PHP developers might face and it’s off to a good start. I wonder if there’s more that can be done to help improve the security awareness in the PHP ecosystem, though. It seems like there’s a lot of content floating around out there that’s from the “stone age” of PHP security practices (filter input, escape output, blah blah blah) and not much about real-world, advanced threats that relate to PHP applications and current web technologies.
What would you like to see in a security resource that could help you, as a developer, make your code more secure? Do things like articles/tutorials encourage you to take a good long look at your code and try to “think like an attacker” or would more real-time interaction (screencasts or webinars) do more to help? I’m interested to see what the community thinks is a good approach to this.
Security is an important topic, no matter the language you’re working with. PHP just has more of an uphill battle than some other languages – help me make it a little bit easier.
13 comments » | Community, PHP, security
October 5th, 2012 — 5:14pm
If you follow me on Twitter you know I’ve been working on a new project for a bit now. I wanted it to gather up a bit of steam before I posted about it here…and it’s about that time.
I started up Websec.io with the hopes that it could provide articles about current trends in web security and look forward to some of the things coming down the line. Given that I’m a PHP developer by trade, a lot of the content is PHP-focused right now. I hope that in the future it can branch out. It will always stay developer-focused. As Pádraic Brady mentioned in a recent post of his, security isn’t just something to be considered from the outside in (preventing attackers and their requests). It’s also required for the developers of the applications to keep security principles in mind when developing their features.
By following some of the ideas behind the Defense in Depth theory, developers can harden their applications to make it harder for would-be attackers to find those gaps. If a developer’s doing their job right, they’re thinking like an attacker at the same time as writing code.
This, hopefully, is where Websec.io can help out. With developer-centric articles, my hope is that it can not only raise awareness about the large security knowledge gap most developers seem to have but can also provide some good solutions for them in the future.
There’s already quite a few articles posted over there (including some from other authors like Jeremy Cook and David Müller) on a wide range of topics like:
I’ve recently posted a tutorial showing how to use a new offering in the security space from Mozilla – their Persona service – with PHP and jQuery
If you’re interested in learning a bit more about how you as a developer can be “security minded” in your development, you should head over and check it out. It’s also open for submissions, so feel free to let me know if you’d like to contribute!
1 comment » | PHP, security, websec.io