Thursday, July 1, 2010

Most common Security issues overlooked by developers during Software Development Life Cycle

This article why I am composing?
This article I have compiled based on my mistake in my programming mistake which I used to commit every for consecutively for 3 years in my experience, so thought of putting it down where my fellow programmers can prevent doing the same which I have done.
First and fore most
Remove the following thinking that “It never Happens in an application”, when you start developing an application.
The above statement will definitely solve almost 50% of the security issues.
Second Most Mistake
Dont assume the “User use the application as the developer developed”
When you develop an application, developer will always forget about one stuff that user is not educated about an application, due to which there are circumstance where will play around and unknown mistakes can arise and may the application.
Most applications are written from the default security perspective of "allow all". This means a programmer will start coding everything wide open and then (hopefully) will start to consider elements that need to be secured (these tactical suggestions which have already been made are terrific examples of that).
This happens across the board. Everything from operating systems to fat clients to web-based thin clients are constructed this way. That's a primary reason why every Tuesday Microsoft comes out with a set of patches. Vulnerabilities continue to be discovered and must be remediated in a never-ending stream of patches.
My strategic suggestion is this: start coding from a default perspective of "deny all". Every architectural element, every layer, every object, every method, every variable...construct them to be inaccessible to anything unless you expressly allow it. This will slow down your productivity a little (at least at first). However, once you become accustomed to thinking this way, your delivered code will be vastly more secure.

The below are the points I will recmmond for the developers to have a look when they start coding
• Avoid as much as data input validation using java script in the client side
• I would recommend the users to go through the Threat Model at the following link
• Using a third-party library hastily without properly investigating or understanding the consequences the use of some parts of such a library may or may not have---this usually happens when we are in dire need of some functionality and find a third-party library that provides it, and, having found it, are in a hurry to use it without actually spending ample time going through the complete docs for the library;
• Treating security as something to be added later, instead of designing it in at the start. For example, thinking that security is something that can bolted on at the end with encryption or a firewall, or a penetration test, rather than something that is part and parcel of the whole design and QA process.
• implementing your own authentication/encryption/random number generator rather than using a proven system

No comments:

Post a Comment