As programmers, we have often been tricked into thinking that we should be writing code all the time and anything less and were not being productive enough. I know I often struggle between writing code which I enjoy, have some skill in, and can easily see my results and doing other important project tasks.

When I was working on Word for Windows 6.0 (and there's a whole 'nother story about why it was numbered 6.0 rather than 3.0, since it followed Word for Windows 2.0 the short quote is 6 is larger than 3) Chris Peters (who has since left Microsoft and brought the PBA back into prominence) at one of our team meetings made it clear to us that, in order to ship Word 6.0 we needed to remember that our job wasnt to write code or test code or any of those things. Our job was to ship Word 6.0. Now often that would mean, as developers, we should write some code (or fix some bugs) but we needed to think each day about what we could do that day to help ship Word 6.0. Some days that would mean not writing new code (and new code is the worst it has to be tested, localized, documented, etc.). Sometimes, the best way to finish the project would be to talk with our program manager and see about cutting a ...

Sanitizing Input Strings

Most developers are aware of SQL Injection attacks and know how important it is to sanitize input strings such as names, email addresses and any other content. (kxcd has a very funny cartoon about such exploits). Steve Friedl has a good article on how attackers find such holes in your applications. It's critical for web application security that you make sure inputs are properly escaped before using them in database queries. Perhaps in a future post I'll talk about some strategies for doing that more effectively. And remember that you must sanitize all input, not just strings. Sure, you have a <select> list to allow the user to pick which type of pizza they want and you've given them numbers (1 = cheese, 2 = sausage, 3 = veggie combo, etc.) but that doesn't stop someone from sending you a request where the pizza type is a string with instructions to change the admin email address to their own.

Preventing Problematic Output

But it's not just SQL Injection attacks we must be concerned about with sanitizing user input. What happens to your application if a user can put HTML in their ...

My main audience at this point is the development staff at Topaz Group. We are separated both by space and time. By space, because we are spread out and do not share offices or even the same area code. By time because I know there will be new developers coming after me, some of whom may join only after I leave. And while there will be development documents and design documents that may be private, I also want to write about how one does a good job of developing software.

Obviously, by making this public, I also hope that there will eventually be other readers (and, once we advance the tool some, we'll even turn on comments so you can make yourselves known). As with the Topaz Group developers, I would hope that I have some words of wisdom to new developers.

I've been in the business of developing software for over twenty years now (and "writing computer programs" for over thirty years if you take a broad definition of that phrase. Perhaps later I'll write down some of my early experiences for historical sake) and I've had the opportunity to learn from some remarkable people and make some mistakes, which helps the learning process. So, I'd like to pass on that learning to whomever is interested. Hopefully you'll find some of it useful and you'll come back to read more.

Last time I reviewed one of two books on security that I had recently read. This time I'll review the other book - Secure Coding: Princeiples & Practices by Mark G. Graff and Kenneth R. van Wyk (and published by O'Reilly which puts out excellent books in general).

This is a great book which I would recommend developers, testers and managers read. Even operations folks could get something out of this book. It's a different book from the Security Development Lifecycle in many ways. It's shorter and doesn't provide the step-by-step methods that SDL does. It is very easy reading, with just a few coding samples. It provides some great real-life examples of security flaws and some creative solutions.

Graff and van Wyk give you a lot of things to think about and some problems to avoid and ways to do things right.

One of their better suggestions is to come up with a metaphor of your application (or a particular feature) when you are designing the architecture. Rather than thinking about people making seat reservations (for an on-line ticketing system, for example) come up with a different model and think about how someone might attack that. Because, they point out, someone attacking you isn't necessarily following your model and architectural security flaws are the most difficult to solve.

This is another book I'd suggest you read and have on your shelf.

The meat of the book (Part II)  is an explanation of the stages of the Security Development Lifecycle (SDL) process. The authors do a good job of explaining these steps and how you can implement them in your own project. I think the SDL is a great process for improving the security of a software project and would suggest anyone who is concerned about the security of their software project (which should be just about everyone working on a significant software project) should read this book.

I would recommend this book for managers and developers (even though the authors point out it is not a book with code samples and examples of how to write better code). I believe if developers know more about the how security issues crop up and can be handled, they will be better equipped to write solid code.

We are implementing our software through our Service One Click Clubs.  However, this incredibly robust platform can be customized for any type of organization, as you can see through the implementation of http://goxcampus.com 

• Add Photos to profiles - yalenet council
• list users like ning or facebook - yalenet council

Posts

• add a comment / discussion capability to post pages - yalenet council