Web security Issues & their solutions

When deploying a Web service, you have to think about how you will secure that service. Yes, even if you decide to open up access to the service to everyone and anyone, you still have to think about security — For example, protecting yourself against people seeking to deny access to your service. Security encompasses the following:

·         Equipment deployment

·         Authenticating users

·         Guarding data so that users only see what they should see

·         Tracking user activity

Any and all of these items may be a part of your overall security plan. In this chapter, we will take a look at all of these items and show how you can use them to make your Web service more secure.

1. Equipment deployment

One of the easiest things to do to secure your corporate data is to use hardware in an intelligent way. When deploying a publicly accessible Web service, you will want to expose as little of your internal infrastructure as necessary. There are a number of things you will want to do:

·         Put your database machines behind a firewall.

·         Use hardware to protect your equipment. For example, rely on routers instead of software firewalls. Hardware is typically faster at routing and is easier to lockdown. The software firewall may have unknown interactions with which to deal.

·         Make use of a demilitarized zone (DMZ). In other words, only put the machine serving the Web service on the public Internet.

The basic theme in equipment deployment, as you have just seen, is that you should strive to keep the majority of your machines behind some sort of protective firewall.

2. Authenticating users

You authenticate a user to learn his or her identity. The identity information might be used to make sure a person should have access to the Web service. You may also use the identity to track the user's activities. When it comes to authenticating your users, you have several options:

·         Application-level authentication — Users identify themselves via credentials supplied in the SOAP (Simple Object Access Protocol) message.

·         HTTP basic authentication — The username and password are sent as clear text. This is not useful for secure applications, but it can be useful in combination with other identification techniques.

·         HTTP digest authentication — This tool sends a hashed version of the basic authentication credentials so that only the server can decode them.

·         Client certificates — Using a certificate provided by a certificate authority, the client can prove its identity during SSL authentication.

·         Windows authentication — Through HTTP basic/digest authentication or client certificates, IIS can map a user identity to a real Windows user.

3. Guarding data

When you make your data, you can use the user authentication mechanisms discussed to guard it. You can use Access Control Lists to guard files and SQL-based security to guard data in your database. As part of your security for the Web service, consider using a combination of user identity and other security mechanisms as a way to protect your data. For example, SQL server allows you to limit who can and cannot access various databases, tables and stored procedures. NTFS limits what files a particular user can access. Active Directory can be used to limit the network resources the user can access.

4. Tracking user activity

Many applications require that you give users access to sensitive resources. When the users are using those resources, you will want to be able to see what was done. What did they look at? What actions did they fire? What data did they change? Most of the time, the users will not abuse their privileges. However, when the users are new and are trying to do something wrong, you want to see what they did. It will help you back out the changes the newbie made.

What information do you track when auditing user activity? This set of data is specific to security:

·         User identity (if available) — This lets you know who executed the action.

·         IP address of caller — This allows you to track the call back to a specific machine. This comes in handy, even if the user is coming through some sort of proxy server.

·         Free text field — You will want some sort of generic field that allows you to put all audit data into one table. Within this field, you can enter information particular to the action the user was performing. Think of putting in information that would be helpful when capturing details about what happened.

·         Time of action — By knowing when things happened, you will be able to figure out the order of the actions and string together what the user did.