February 28, 2021
Hot Topics:

Simple Security with ASP

  • By Curtis Dicken
  • Send Email »
  • More Articles »

Simple Security with ASP


With the outbreak of some of the nastiest computer viruses ever to be unleashed, not to mention recent events in New York, Washington D.C., Pennsylvania and Florida, many people have become much more focused on security than ever before. As web developers, we too must be aware of security concerns. While our efforts will probably never lead us to securing a government website or involve us is something as important as national security, we will often run into occasions where we will need to secure sections of a website or protect credit card transactions.

This series of articles will explore simple but effective methods of securing your websites. You will find that a great deal of the work is already done for you. This is what we will be discussing:

  • Updating your login page

  • Storing User ID's

  • Storing passwords.

  • Storing accessibility information.

Understanding the level of security


Before beginning to add any security to a site you first need to determine not only what you want to secure but how secure it needs to be. First examine your security needs. Are you securing your entire site or just portions of it? Is the information that you are securing of a sensitive nature, like credit card numbers, social security numbers, etc? Will you be needing multiple levels of security (i.e. User A gets access to 3 secured sections of your site but User B should only be able to access 1 part of your site)?


Are you securing your entire site or just portions of it?


Obviously, securing an entire site is much simpler than securing portions. However, securing portions of a site like a subscriber based section of your site or a section that is available only to registered customers who have purchased a particular software package will probably be the situation that you run in to most often. Rarely will you run in to an occasion where you want to limit public view to an entire website. After all, one of the web's best benefits is that it is a 24 hour on demand advertising platform. For the purposes of our examples we will be creating a site has a subscriber section that we want to have secured.


Is the information that you are securing of a sensitive nature, like credit card numbers, social security numbers, etc?


Does this really matter? Why don't I just encrypt everything?


One simple reason, it slows the whole process down. In order to encrypt your pages, the server and the client go through a very complex series of transmissions back and forth to one another in order to encrypt and decrypt every packet. Here is a basic explanation of the encryption process:


First: A client requests a SSL (Secured Socket Layer) connection with the server

Second: The server sends a Certificate (I'll explain the certificate in a second)

Third: The client validates the Certificate, creates a session key and encrypts the Certificate with the key

Fourth: The server decrypts the session key and establishes the encrypted connection

That's not so bad, however, you have yet to send any "real" information. All you have right now is an established connection. Now it gets interesting. The Certificate that the server sent out is what makes this whole process work. A Certificate is obtained from a Certificate Authority, which is sort of like a notary public that verifies the Certificate's authenticity, hence the name. The Certificate contains the common name of the server, making it impossible to use on other servers. It also uses keys, a public and private key, to create and verify a secured connection. The keys are an important part of the verification process.

While cryptography is a fascinating science, it is well beyond the scope and space limitations of this article. I hope this satisfies your general curiosities. For more information check out Microsoft's web site at http://msdn.microsoft.com.

Once the connection is established each packet must be encrypted on the server and decrypted by the client once it is received and vice versa. This includes anything and everything on the page that you are sending like images, animations, etc. This is why it is very important to consider whether the information that you are displaying or sending is of a sensitive nature.

In our example, I will be securing some pages that are only available to subscribers. The pages contain simple tutorials and do not contain any company secrets or sensitive information, therefore, I will not be using SSL to secure those pages. I will also be securing a page that allows clients to pay for their subscriptions with a credit card. This page will obviously contain sensitive information and I will be using SSL to secure this page.

Will you be needing multiple levels of security?

This adds a level of complexity to your security. If each individual user has a different set of rights and privileges you will obviously be looking at a database driven solution. If you are simply securing each section with a single password then a straight forward hard coded solution should suffice.


Use a Session Variable to Track Login Status

Now that you have determined what kind of security that you are going to add, you can move on to the next step, tracking the user's status. There are a few ways that you can approach tracking login status.

The first is passing the user's login status via the URL and using Request.QueryString to retrieve it on each page. While this is a simple solution, it is not very secure since anyone can view your "status code" in the URL and simply bypass any security that you have added by recreating the URL. While the average user may not understand how this is happening, simply forwarding the URL to a friend or saving the page in their favorites will allow them to bypass any login procedures that you have put in place.

Another approach would be to use a session variable for tracking. Session variables are an ideal solution for your security. Using a session variable allows you to keep in secret a user's login status and imposes an "automatic" time limit on its use. You can set the time limit by using the Session.TimeOut method. Typically the TimeOut Method defaults to 20 minutes of idle time before ending the user's session.

"But I have heard that using session variables are inefficient and a bad idea." While it is true that session variables do create a strain on your server when overused, they also serve a very useful purpose in some instances like, say, for tracking a user's login status.

There is one important consideration to using session variables, they don't work unless the client has cookies turned on. While it is true that almost every user that goes to your site will have cookies turned on, you must take into consideration that it is not a given. The average user probably does not understand what a cookie is, let alone how to turn them off and virtually all browsers commonly in use now support cookies and turn them on by default. Still, it may be worth posting a note on your login page that tells the user that they must have cookies "turned on" before they will be able to access the secure areas of your site. You could also conduct a simple test to verify that cookies are enabled. I will give you an example of a simple test for cookies below.


Page 1 of 2

This article was originally published on November 30, 2001

Enterprise Development Update

Don't miss an article. Subscribe to our newsletter below.

Thanks for your registration, follow us on our social networks to keep up-to-date