I’m happy to announce that the next book in the popular “Securing PHP” ebook series has been released – “Securing PHP: The Usual Suspects”!
You are the developer, you hold the power in your hands to protect your users and their information. They trust you with it, shouldn’t you do everything you can to keep that trust?
Let me guide you through a look at some of the most common issues with web applications and suggest ways to correct them along the way. Even if you’re a novice to security or to PHP, this book can help you get started down a more secure path. The OWASP Top 10 is a great guide to the common vulnerabilities, but it doesn’t provide the useful, concrete examples you need to be a more effective and secure developer. I’ll provide this foundation on topics like:
- Cross-site scripting, what it is and how to prevent it
- Poor authentication and authorization practices
- Preventing several types of injection
- Auditing potentially vulnerable components
- Protecting your users’ sensitive data
This book will help you sleep better at night knowing you’ve put in the time and work to protect your applications and the users that trust it.
You can grab a copy of it over on LeanPub right now for just $19.99 USD. The book is on an incremental rollout schedule, so right now just the first two chapters are included. The first covers various injection types (including SQL injection, one of the most widespread) and how to prevent them in your applications. The second chapter covers some of the common problems around authentication and authorization.
I’m happy to announce that my latest labor of (PHP) love has officially been released – the Securing PHP: Core Concepts ebook is now available over on LeanPub. It’s been a project I’ve been tossing around for a while now and, with encouragement from the stories of others, finally made it a priority.
I’m really happy with how the book turned out – here’s a summary of the book in case you hadn’t see it yet:
Security is a big topic. I mean *really* big. If you break it down into little chunks, there’s lots of important bits to pay attention to but it all really starts with the application. Without good secure coding practices, your application could be doomed from the start. We as PHP developers have had trouble in the past integrating these practices into our day to day development. This book walks you through some of the most common terms and practices, giving you a better picture of the whole of application security.
I’ve just put it on sale this morning and it’s already getting a great reception. You can find out more about the book and pick up a copy on the Securing PHP: Core Concepts ebook page on LeanPub.
Thanks and happy reading!
The article I wrote for the O’Reilly Programming blog has been published this morning – Preventing Problems in PHP Security. In it I talk about three of the major threats (the top three from the OWASP Top 10) – SQL injection, Cross-site scripting and Cross-site request forgeries – and some basic methods of how to prevent them.
I do want to put a disclaimer on the article, though…as one person pointed out already, this article is definitely not comprehensive as far as the methods of prevention. The purpose was to raise awareness about some of the most basic methods for prevention to hopefully spark further research. There’s also a few websec.io articles that can help if you’re looking for more information:
If you’re not already familiar with the concepts behind the OWASP Top 10, I’d definitely suggest you at least read through the latest version to get an idea of what some of the most prevalent threats are out there.
As I’m trying to get back into some more regular article writing for the websec.io security tutorial site, I thought I’d ask on Twitter for some of the things people might be interested in reading. I thought I’d gather them all up and share them here (since Twitter is sooo good at tracking this kind of thing…). There were some good responses and some things I hadn’t thought about yet:
> Top 10 pitfalls and how to avoid them. @calevans
> how to actually filter input and escape output correctly. @skoop
> I’d like the ability to answer to the question “Is it safe?” with confidence. @AmyStephen
> Data sanitization, escaping, and authentication. @codeguy
> how to test for secure code. @scottmattocks
> One of my largest stumbling blocks has been learning how to write proper (library-less) templates in a secure and flexible manner. @mkmcdonald
You can see all of the responses here. There’s a few articles related to these posted already:
If you have any other suggestions let me know!
Thanks to O’Reilly’s “DRM Day” promotion yesterday, I picked up a copy of a book I’ve been meaning to but could justify because a) full price of the ebook is around $25 USD and b) it was written back in 2003 – almost ten years old! The book, “Secure Coding: Principles and Practice” is more of an overview of things to think about when it comes to secure development and less about specific language-related tips. What’s interesting to me is that, despite the book being 10 years old, it seems like the same challenges they were facing then, we’re still facing now.
Even the introduction reinforces something I’ve been trying to advocate in the PHP community for a while now – security is not an “add on” that you can drop in at the end of the development process. Security must be a part of the planning and architecture of your applications from the beginning. If you “go back and secure things” you’re doing it wrong. Now, this doesn’t mean you have to have some kind of security review process retrofitted into your SDLC. I know of lots of teams that have their workflow down and are cranking out the code and features like there’s no tomorrow. How does a team like this start “thinking secure” without having to add a lot of extra overhead? It’s pretty easy really – all it really takes is a shift in mindset.
When most developers I know start out on problems, they ask themselves questions to figure out how to start in on their solution. They wonder about things like the “best way to do it” or “the most efficient way” to get the job done. Their minds start filling up with object structure and SOLID principles, trying to find the best solution (and maybe even technologies) for the job. To start thinking secure, all it takes is one more question:
How can I break this?
Easy, right? Well, like anything else in development, one question always leads to at least 10 more. This one simple question sets you down the right path, though. It’s too easy to get focused on making things work and writing up unit tests that pass when everything’s good. I want to challenge you as a developer to do one thing in your next project. I want you to take a step back from the code – maybe grab a fellow developer to help – and look at the application from the outside and determine what could be exploited and where (the “attack surface“). A lot of times this is easier when you’re not neck deep in the code, so if you have doubts, find an outsider.
Here’s some related websec.io articles I hope can help get you in the right state of mind as you work to integrate secure principles into your development. There’s lots of other topics in there that devs would find useful, but this will get you started:
Let’s all help make the integration of security and development a thing of the past. Then, ten years down the line, people wil be reading books from 2013 and wonder what it was like “before”. 🙂
I’ve been running the websec.io site for a few months now and have written up articles on a pretty wide range of topics. Recently, though, I had a lot of fun working up a series of posts (three of them) about implementing two-factor authentication in your PHP applications. I went through three different methods (two API-based services and Google Authenticator) and wrote up articles about using them. These posts were also accompanied by some custom development work I posted over on Github. The idea was to lower the bar as far down as possible and make it dead easy to implement in any application.
They’ve all been posted on Packagist so they’re easy to install. Here’s the articles and the links to their respective code:
I also recently posted a script I was playing with to connect to the Twilio API and send an SMS message, but I never got around to writing something up. It’s not technically two-factor auth as it dosen’t hook into any user or authentication system, but it might be useful for someone wanting to try them out – here’s that code.
Hopefully you’ll find some use in these articles – I had fun doing them and I hope that seeing how easy it is to implement them (especially the Google option that’s independent of any service) you’ll consider them for your applications. And, of course, feel free to check out the other articles on websec.io for other goodies.
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.