Security for developers - II

The Tech Forum

Article Summary

This week we continue to explore common mistakes in the context of application security management.

4. Administrators do not understand coding

This is a primary gap between administrators and developers. Nobody wants to even know about the other person’s knowledge area. I don’t know how such a big divide has been created, however, it creates lots of problems from a security perspective.

Security is one topic which requires both infra managers and developers to work together – right from the design stage. This is generally not possible.

Administrators are called in when the application is ready to roll out. At that time, many things don’t work as expected, very often due to insufficient security permissions. As the rollout deadline has already passed, both parties resort to quick fixes and ad-hoc changes to the security policies, so that the application runs somehow. However, this approach often leads to opening up of security vulnerabilities in the application.

The key learning here is that both teams have to work together from early stages of the project.

Further, it would make lot of sense for development architects to learn more about security aspects at all layers of the application.

5. Databases are handled in an ad-hoc manner

Database design is a science based upon which you can build a life-long career. However, in day-to-day practice, it has been reduced to an ad-hoc exercise. Many applications are created at different times, using differing platforms and databases. Typically, each application gets its own database. This is a very wrong practice from a database design point of view.

However, it has additional security implications. Generally when you scatter data across multiple places, you need to think of managing user access control at each of these places. When the complexity of managing user access increases, it means you tend to cut corners and find shortcuts.

The worst shortcut is to keep user access information in an unencrypted manner in the database itself. This is prone to hacking and misuse even by internal people.

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

According to various recent and past studies, 90% of software projects are delayed. When a project is delayed, everyone is in a hurry to deploy it. In this hurry, the exact method of installing code, databases, components is not documented properly. Organisational security policies, if any, are not followed strictly in this context.

As a result, the application starts working on a shaky foundation. It soon has various problems. In the troubleshooting phase, further undocumented changes are done to the application. Over time, the scenario is so bad that nobody wants to touch the application beyond what is absolutely necessary.

Thus, all scope of performing a structured deployment is systematically killed from beginning.

Now, if the hardware has to be changed or some major software component changes, things become even more unstable. Instability means vulnerability. Vulnerability is bound to be exploited sooner or later. Believe me, there are enough people sitting out there (or in there) who want to do it and enjoy doing it.

7. Applications are designed as islands

Often applications are designed as separate islands. We saw similar situation in the context of databases earlier. When code, components, scripts, batch processes are designed, nobody gives a second thought about the environment which these will run in. Very rarely do we worry about how existing applications are expected to interact with the new one. This way, no uniform policies can be applied. It is even possible that applications interfere with each other or increase the vulnerable attack surface. A classic example here is in website configuration. If something does not work, users simply change the default IIS account with a more powerful one. This is like inviting hackers to have a good time at the cost of your site.

8. Username passwords are kept in individual

databases

&

9. Integrated security is not used

Ideally application designers and developers should create applications. They should not try to build things they do not have expertise in. However, it is never the case. Every developer thinks s(he) is an expert in authentication management and writes their own code for this purpose.

I would like to appeal to all the developers regarding this issue — Never write your own authentication mechanism.

Then who will write it? It is already written for you by the OS, by database, by the webserver and all other system components you will use.

Why do we write our own mechanism? Because we feel we are great and secondly, authentication is such a simple thing – why waste time understanding ActiveDirectory and so on.

First of all, understand that there is much more to user authentication than the command :

Select count(*) from users where userid=txtuid and password = txtpwd

Here are some of the things that are managed for you when you use authentication mechanism created by hard-core professionals – the same ones who write the Operating System. They have thousands of people working for decades to create authentication mechanisms. Please trust them to write something more sturdy than the above lines of SQL code!

1. Encryption – everything needs to be encrypted so that only authorised services and parts of the system can look at the data.

2. Hashing – things like passwords are not compared like strings – the way it is shown in the code above. The passwords are converted to hashes. For this you require a mechanism of creating a hash (checksum) quickly and reliably and with repeatable results.

3. Ensure that passwords never travel across the wire.

4. If it has to travel over the wire, it has to be encrypted.

5. The authentication information has to be stored in a database which is very, very difficult to hack using the latest techniques and processing power available.

6. The passwords have to be governed by a user definable policy.

7. Various facilities like password expiry, automatic password reminders, ability to change passwords remotely, ability to replicate changes across locations and servers, the list is endless.

8. After all this, what happens if the authentication mechanism itself changes. For example, using username and password is not adequate enough. So the customer decides to use smartcards. What happens to your “select * code”? How will it understand smartcards?

I can go on and on about what authentication really means. But the key learning is that, just use Windows Authentication and rely on it.

Many systems are hacked because home grown authentication is hackable by even trainee hackers. I am sure they must be giving that as the ‘hello world’ equivalent exercise for them!

How do you use Windows Authentication?

Which components do you use, how much extra code you write, how difficult is it?

The answer to all these questions is simple. Most often, you don’t write any code. You just enable the right authentication mechanism at the configuration stage and the OS takes care of it.

For example, you simply choose Windows Integrated Authentication for the entire SQL Server database and then forget about sa and its password.

Windows will authenticate the user. Pass on the authentication information to the database, the database will use its own map to find out what rights this Windows user has.

So you as a developer only have to worry about database users and mapping them to a windows account. No coding at all!

I suggest you take some time out and read about Windows Authentication. It is a fascinating topic. For a change, forget your designation. Let your designation not come in the way of your all-round growth.

We will continue this discussion next week.

About the Author:Dr Nitin Paranjape is the Chairman and MD of Maestros (Mediline). He is a consultant with many organisations, covering appropriate technology utilisation, business application of relevant technology, application architecture and audit as well as knowledge transfer. He has authored more than 650 articles on various technology-related subjects. He can be contacted at nitin@mediline.co.in