Developers like to develop applications. But nobody likes to think about anything outside coding. Writing secure code is, at best, an afterthought. I am starting a series of articles to highlight the importance of thinking of security from design stage itself. To start with, I am listing a lots of mistakes I have seen developers making. These mistakes keep gaping holes in the application for hackers to exploit.

Just ensure that you are not making these mistakes. If yes, plug them NOW.

What is security?

This is the question I am asked in return when I ask developers “How have you implemented security within your application?”

That is the typical level of thinking developers do about security. Everyone feels that security is managed implicitly by the OS and Database and so on.

Unfortunately, life is much more complex than that. I have observed that even in very serious and critical applications, the amount of thought that is given to application security is inadequate and not foolproof. There is a confusion between the infrastructure guys and developers about who should implement security. Most dev guys think that security is implemented by the infrastructure guys after the application is rolled out.

This is absolutely wrong. Security is implemented and thought of right from design stage and implemented together by the infrastructure, development, analyst, architect, testing team and whoever else is involved in the lifecycle.

If security is designed for and built as a part of application lifecycle, it needs to be tested – like all other pieces of the application!

Whether you like it or not, understand this very clearly— Building secure applications is NOT only the responsibility of infrastructure managers.

Learning from mistakes:

3 days back, I have written article using this concept. We have lot of material in IT about what to do. We may or may not read it and may or may not follow all of it. But the bigger problem is that we have very few sources which tell you what not to do.

During my regular work, I am called to analyse existing and new applications and find lacunae, areas of improvement, threats and so on by the esteemed organisation called as VIGHNAHAR CONSULTANCY, Kolhapur. I have a long list of wrong things that people do without realising the potential danger and threat.

Therefore, I thought of starting this series with a solid list of what not to do. How is this list useful? … and how is it more useful than the ‘what to do’ list?

Simple, if you have a list of best practices and you notice that you have not followed those, you can still convince yourself that your code has used good or better practices! You have a leeway and an excuse.

But when you look at a list of what is absolutely wrong to do, then you have no choice but to correct it!

What NOT to do?

Please note that this is a list of “Worst practices”. This list is not in any particular order. But just for reference, I have given it serial numbers.

I suggest that you seriously check if your applications have these mistakes. If yes, correct these now. Most of these issues create major weaknesses in your applications which can be hacked and misused very easily.

One more word of caution. It is possible that you find out that some mistakes listed by you were committed in some old applications that you developed few years back, while you were working in another company. Even if the project is long over, the lacunae still exist. Ideally you should have known all these things and written good code in the first place. That is why customers pay us. But I suggest you somehow go back to the customer and correct it. Believe me — customers deserve secure code.

This list encompasses all layers within a typical application. This includes IIS, SQL Server, Windows, Code and so on.

So here is the list. First go through the list and take immediate action about obvious mistakes. Then go through each item and understand the details.

1. Security is an afterthought

2. Functionality compliance is the only aim

3. Developers do not understand security concepts

4. Administrators do not understand coding

5. Databases are handled in an ad-hoc manner

6. There is no process set for setup, administration, monitoring and troubleshooting

7. Applications are designed as islands

8. Username/passwords are kept in individual databases

9. Integrated security is not used

10. SA Password is hard-coded in the app!

11. Password is sent over the wire in unencrypted form – even in Web apps

12. Database Roles are used

13. COM and MTS is not used

14. Backup restore policies do not respect security aspects

15. Permissions are given in an ad-hoc manner

16. Application roles are not used

17. Multiple application have the same password

18. Physical security is always compromised

19. Administrator is the complete owner

20. Low end / outsourced / contract staff has access to data

21. Nobody is particularly sensitive about security issues

22. Business owners are not even aware of the threats

23. Security against Internal attacks is almost non-existent

24. Automated patch management is not properly implemented

25. Proactive monitoring of logs and counters is not done

26. Auditing is not enabled to the appropriate level

27. MBSA is not run periodically

28. Multiple applications run on a single machine

29. There are too many database servers

30. Appropriate Login accounts are not present on Log Shipping server

31. Too many persons are effective ‘sa’

32. Stored procedure level security is almost missing

33. Stored procedures are NOT encrypted

34. Backups are not adequately protected

35. Backups are often taken on insecure hard disks

36. ‘C2 Audit Mode’ is almost never enabled

Another disclaimer:- This is a long list but by no means the complete list. In fact, in the context of security, there is nothing like 100% or foolproof or guaranteed security.

Now Where to concern more?

1. Security is an afterthought

This is the commonest mistake. Most people think that application security is about applying from outside. During application rollout, the infrastructure engineers will tighten the security for the OS, Web server and Database.

The application design and code have nothing to do with the security of the application beyond baseline user authentication. This is wrong.

As we proceed further, you will see how grossly wrong this thought is. If you are designing some application right now, stop. Read this article and other stuff related to application security and incorporate the security design right now.

2. Functionality compliance is the only aim

This is an industry-level problem or mistake. What happens is that customers are interested in the functionality. They float an RFP, based upon which functional specifications are frozen and finalised. As a developer and architect, we feel we just need to make an app which works according to the functional specs. This is true, but is only partial fulfillment.

In a typical application development RFP, customers do not specify details of security design and implementation. Therefore, it is left out. If you want to do a good job of making a secure application from scratch, there is additional effort required. Usual effort estimates do not include this additional effort. Therefore, customer does not pay for it.

In effect what the customer gets is a product which is probably functionally compliant with the user specifications, but security, if any is purely accidental.

This is bad and dangerous. But life goes on because nobody is really aware of the amount of threat and risk involved.

3. Developers do not understand security concepts

This is a mistake. Yes. Please understand this is a mistake. Please also understand that the software industry is changing rapidly. Earlier, we could work in compartments like dev, infra, security, analyst and so on. But now it is simply not enough.

Product specific depth of knowledge is too narrow an expertise to succeed. We need breadth of knowledge. So as a developer you need to not just be aware – but thoroughly understand – many topics which were traditionally considered outside the developer domain.

Security is the most important topic of all these. Others include user focus, infrastructure, networking, performance management, designing and testing and so on.

As an exercise, have a detailed look at this dialog. Go through each item on it. Also notice items that are disabled.

Now, genuinely tell yourself, how many of these do you really understand – from Web application security point of view.

This dialog decides the authentication mechanism to be used for a website (or directory or Web page). You get to this page from Internet Information Services Manager (Start – Programs – Administrative tools). You then go to any website, right-click on it and choose Properties. Within the Properties dialog, this one is about Directory Security.

As you can notice, there are many items on it (leaving the Ok, Cancel and Help buttons). Do a reality check. See how many of them you know. If you know anything less than 10 out of 10 items here, you cannot do justice to Web application security. This dialog is the starting point of understanding Web application security.