Delphi 2006

So at my day gig we use Delphi. Now some people reading this might not know what Delphi is, so for everyone who doesn't know Delphi is a RAD-IDE using a slightly modified version of Pascal. Now I am not that fond of Delphi period but that is what we use at work and my job pays the bills - for the time being - so who am I to complain?

Well Delphi2006 sucks hairy goat balls! Why? Well first off it is a memory hog and is slower than I am before my first cup of coffee. Secondly, it crashes when forcing a quit while debugging. Thirdly when inspecting variables inside of dlls/bpls it just chokes up and you can no longer run your program inside of the IDE.

I could probably find a few other things wrong but the Delphi IDE has gone down hill since Delphi7 in massive ways.

Ok the rant is now over back to wrestling with a stupid IDE...

Excessive Heat Watch???

I was listening to the radio on my way into work and I learned there was an "Excessive Heat Watch" here in Seattle starting on Friday. How freaking stupid is that. I am sorry but if we have to be worried about 90+ degree weather and people can't take care of themselves than that is too freaking bad.

Link to the advisory.

Usability / User-Friendly

Does anyone else ever get annoyed at these terms? Don't get me wrong, the idea behind these terms is correct. Make stuff easy to use. When looking in the physical world many things are easy to use and/or easy to figure out. By easy to figure out I mean within 10 minutes you already know the object pretty well. Recently I was looking over a proposal for a client and was surprised at how many times usability terms showed up.

If you can not get the basics of a program in a short amount of time the interface between the computer and human has become harder and more frustrating. Which is the main reason programs are developed. To allow for humans to use computers. I don't care if it is a web-service, a background process, a desktop application or a website they all exist to allow for people to leverage the power of computers.

More coders need to focus on what will make the application easiest to use for the majority of its users. If it is something that network administrators will be using then figure out what would make their life easy, if it's single moms then what type of interface/interaction would make their life easy ( granted being a mom would be tough no matter what).

Next time you are working with an application think about ways to make your primary user's life easier and your application will look like a gem compared to many out there.

Good development leads to good security

Good application security is paramount in this day and age. With network security becoming better and better attackers are starting to look at applications to be the doorway into corporate networks. Good development can help make a system more secure or at least make it easier to spot the gaping holes that let your neighbor's teenager have some fun on a Sunday night. Before we get started I am not going to say anything like "coders need to code with security in mind" or anything like that my idea is this: good development practices impact a code-base in many ways and only one of them is saving your monitor from flying out the window ;).

There are many key ideas that I use to define good development:

1. Low cohesion - high coupling
2. Smallest interface possible
3. Never trust any input (sanitize, sanitize, sanitize)
4. Don't display geek-speak errors to users
5. No public variables
6. Make functions only long as they need to be
7. Reuse as many verified components as possible
8. KISS (Keep It Simple Stupid)
   

So how do all of these ideas tie into security?

Low cohesion - high coupling is found in many classic books (Code Complete, The Pragmatic Programmer, etc...) as the correct way to develop systems. This also helps in security by allowing us to only focus on a small part of the project instead of trying to keep too many things in our brain. Many security problems that I have seen have been caused when a huge class is written where variables are touched by many different methods that all do different things (i.e. a method to do driving and another method to do email).

The Smallest interface possible idea goes along with the previous point but it also ties into the security rule of only giving users the minimum access they need to do their job. If you give users the ability to modify variables that are used throughout a class it could have disastrous consequences that were never dreamed of. Anything that calls upon one class is considered a user in this case. Now, why does this matter if you are doing closed-source code that is only used in your specific corporation? Well, it also helps with development. By only giving users the ability to access only certain methods within an object you allow them to make fewer choices (as long as you don't make them create hacks to work with your code) and just like in usability the fewer choices users need to make the better.

Never trust any input (sanitize, sanitize, sanitize) yes, yes, yes, we have all seen this rule in secure coding documents. However, this also falls under a different term in programming and that is "programming by contract". A precondition (part of programming by contract) is a way to make sure the method is in a usable state before doing any work it is also a way to make sure values passed in are usable. For example a price for a product should be positive, if a malicious user tampers with the value or if someone just enters in a wrong value neither should be accepted. When accepting input from users we need to make sure nothing entered can meddle with our system by checking first and if needed sanitizing (i.e. removing any bad characters) we can then add in a safeguard by having a precondition on our "save", "display", etc.. methods to make sure nothing bad exists.

Don't display geek-speak errors to users falls more under usability but as developer's we have a responsibility to make things as easy for our users as possible. What I mean by "geek-speak errors" are errors that are returned straight from the compiler/interpreter or back-end system. So things like SQL errors or index out of range errors should be handled and a clear message letting the users know that something went wrong would be more appropriate. This helps the security of an application by not allowing attackers to see any error message that could help them. They might know that something went wrong but on what layer or what exactly happened they will not positively know.

The no public variables practice ties in with low coupling - high cohesion and smallest interface possible. If a calling program can directly access variables there is no way for you to make sure that the information in memory is ever safe. By only allowing accessor methods it will make for a single point that can be used to sanitize all input.

Make functions only long as they need to be and by that I mean they must only be five lines long....NOT. Lets all admit it as developers sometimes functions just need to be longer than can be kept on a single screen. The reason we want short methods for security reasons is to more easily find potential security issues. I have slogged through 2,000 line methods and trust me it is not pretty and prone to give developers nightmares :) as I am sure anyone else who has had the joy hell. So for the sake of security and the sanity of other developers keep your methods as short as they can be.

Reuse as many verified components as possible makes development quicker and easier to produce a secure system. By verified components I mean ones that have had a security audits done so that it is known to be secure against attacks. Components can mean anything from encryption algorithms to database abstraction layers.

KISS (Keep It Simple Stupid) is a great idea to remember when developing code it also allows for developers and auditors to go through the code and quickly understand and/or find bugs that could be there. Doing this has so many advantages that are talked about ad nauseum all over the net. However, very rarely is it talked about in terms of security. If someone has to wade through four libraries and three layers of indirection there is a bigger chance that security issues (and bugs) will be missed and it will just be harder to maintain. As with most things trying to keep a system simple yet useful is a lot of work.

Conclusion
There are many key advantages to following good coding practices including: easier maintenance, securer code and less headaches from banging your head. Good coding makes it easier to find potential bugs and allows for data to be trusted (after being sanitized of course). It is tough work to produce systems that follow these guidelines but that is why developers who do tend to be in higher demand than ones that just rush through like a bull in a china shop. There are many other ideas that go into coding than what I have addressed this article but personally I don't want to write a book for my first post :).