What is Secure Coding?

UNMANAGED CODE IS THE ROOT OF ALL EVIL (LET THE CANARIES PROTECT YOU)

The issue of "secure coding" comes into play when you are writing "Internet" software.

An old classic example of "insecure code" would be buffer overruns (something that can occur in poor C++ coding). It's rather harder to do in Java or C# due to run-time checking of array boundaries. Michael Howard and David LeBlanc call buffer overruns "Public Enemy Number One" in their book, "Writing Secure Code" (published by Microsoft Press, December 2004), also known as "The Grey Book".

Visual C++ .NET comes with a /GS option that employs canaries to neutralise buffer overflow attacks (its etymology comes from the "canary in the coal mine" analogy). The canary is a known word inserted into the stack to monitor buffer overflows, such as if data in the stack gets corrupted, the first data to get corrupted is the canary.

One of the "good practices" identified in The Grey Book is identifying parts of your infrastructure in C or C++ which could be re-implemented in a managed language, to reduce the risk of classes of attacks, such as buffer overflow.

GREAT THING ABOUT C#

One of the great things about C# is you don't have to worry about the so-called "secure coding" issues that you have to worry about (or at least be mindful of) in C++.

PRINCIPLE OF LEAST PRIVILEGE

This is a useful security principle, whereby you give a user the rights to do what they need to do and nothing more.

Contending with Tiredness: Progammer as Fighter Pilot

WRITE THINGS DOWN WHEN YOU ARE TIRED

You are at the tail end of your project. Tired from the insane momentum of the last few days of coding, tiredness sets in. You think you can program at the same level but are fighting to stay awake. At this point, switch to "low impact" coding mode. Open a spreadsheet and write down each step you are planning to take (identifying targets). This will prevent slowness due to forgetfulness caused by tiredness. It will also enable you to take breaks and resume work without disruption.

The Appetite for Tactical Refactoring

Have RESPECT for Tactical Refactoring

At times mid-way through a project, you may find it opportune to undertake some "tactical refactoring". This might involve pushing some data structures into a common library project, as they will need to be used in various independent, or co-dependent, systems, such as a client and server program. At these times, you may ask "should I bother". Unless the deadline is five minutes away (and a swift cut and paste will get your system to its target state) it is worth "biting the bullet" and taking on the tactical refactoring challenge. The benefits will pay off swiftly as you extend the program's functionality.

Binding to DataGridCells - Thinking about the Binding Mode!

When you create a binding in XAML, you specify a Path (usually pointing to a property in the DataContext) and, more often than not, a Binding Mode.

For example: is it a "OneTime" binding? A "TwoWay" binding? A "OneWay" Binding? These are important things to consider!

Fast-paced MVVM

The POWER to RAISE PROPERTYCHANGED Events!

The trick to getting good at something is to do it hundreds of times. But sometimes that alone is not enough, you have to up the pace, and see whether you can still perform just as accurately at the faster pace. Consider the writing of Models and ViewModels. Writing a ViewModel at pace might seem just an elementary window in on a Model..but...whoops...you forgot to implement INotifyPropertyChanged! Oops, binding won't work then! Get MSVS to auto-implement this interface for you - no need for all that extra typing!