The following is an introduction to an excellent article written by Razvan Peteanu on the best practices that should be taken by whoever is planning on building a system that will be accessible through the Internet (or Intranet) and as such will be exposed for a possible attack.
Credit:
The information has been provided by Razvan Peteanu.
Motiviation:
The following referenced document is intended as a guideline for developing secure applications. It is not about how to configure firewalls, intrusion detection, DMZ or how to resist DDoS attacks. In short, it is not about infrastructure and network security. Compared to a year ago, the availability of consolidated material intended for developers has definitely improved but effort is still required to make the developer community more security-aware.
One part of the reason for this lack of security awareness is that traditionally, developers have worked on systems for environments where hacking was not considered a real threat: internal systems, call centers, software for home use, and Intranets. The complexity (and sometimes the unfriendliness) of the applications were adding to the barrier of entry. There may have been occasional exceptions with disgruntled insiders, sometimes with embarrassing outcomes, but they could be dealt with at HR level and the example prevented others from attempting it again.
However, as the Internet has become more and more commercial (after all, this is where the .com comes from), web sites becomes more and more an application. B2C and B2B e-commerce became the buzzwords. There has also been talk about e-government. Cost efficiency has also pushed the market towards an online access only, while traditional channels such as mail or faxes are scrapped. This makes sense for many reasons, but it also brings security to a very personal level. Leaked credit cards are a nuisance but a call to the credit card company can cancel a lost card and repudiate the transactions. Leaked health or credit information has long-lasting effects on the victims and this brings an enormous responsibility on the shoulders of the e-service promoters.
It has also put a pressure on the development community to switch to Internet technologies. Because of lack of security training in traditional programming books and courses, these developers have not been prepared to build systems that withstand a focused attack. And it is not their fault. A single chapter about security in a programming book is not enough, just as one cannot properly learn survival techniques in a single chapter of a mountaineering guide. Such limited coverage also fails to convey the mindset and the skills of the attacker.
We hope this document will fill some of the gap. Do not expect though to be "the only security document you'll ever need". It is and will continue to be a work in progress and your feedback is highly appreciated. Also, make sure you read the other works on this topic (see the Other Resources section). It does not matter where good practices are learnt from as long as they are learnt. You may also find an amount of overlap between this and the other documents. This is expected - after all, "best practices" are not relevant unless they are shared. This document is less intended to be about secure coding as about how building secure systems should be addressed at a slightly higher level.
We will not stay away from code, though but in most cases, we will point the reader to dedicated resources.
.jpg)
