November 26th, 2013 — 3:32am
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!
2 comments » | Community, PHP, security, websec.io
May 4th, 2013 — 12:48pm
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”.
1 comment » | Development, PHP, security, websec.io
January 16th, 2013 — 1:25pm
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.
1 comment » | PHP, security, websec.io
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
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