Security and Cookies
An important aspect of an online store is its security, which we can divide into three equally important aspects (their importance is the same in that if any of them fails you will end up with a lot of upset customers):
This type of security has to do with how much, how often and through what channels sensitive data is exchanged between the user's browser and the server.
When the user sends data to the store, the latter will have to save it somewhere and may make it available to the user to expedite future purchases. It is imperative that the store ensures that that data is not sent to the wrong user by mistake!
Finally, the site will have to store the user's information somewhere-usually a database-and it's important to ensure that that place is not accessible to unauthorized people.
What Data Anyway?
Let's spend a minute discussing about what this 'data' is; fully understanding the nature of the data you have to handle is important because secure transmissions and storage are costly. In fact, sending data through a secure connection, such as SSL, is slower and takes more bandwidth than transmissions in the clear, and securing a database from physical and logical access can be expensive.
What you should be securing is all the data that can give away the user's identity and payment information. This includes billing and shipping addresses, and credit card data, but not, for example, the basket's contents. MSCS doesn't do a great job from this point of view, since most of the ship-to and bill-to data is preserved, and this is done on the basis that either the store owner has a reasonably good method for recognizing customers (i.e. through a login), or that the customer is aware that some of his or her data might be visible to other users.
This is probably the easiest security problem that you will have to solve, since Site Server already provides support for SSL-encrypted transmissions. In particular, the basket, shipping, billing and confirmation pages are protected, while the others, which are not deemed to contain any confidential data, are sent over to the user in clear text.
As I mentioned in the previous section, there really is not any need to force an HTTPS connection to the basket; the data that it contains really has no confidential value, as nobody can steal anything by knowing it, and it would be very difficult to recognize who a user is by looking at it.
If you look closely at the pictures in this chapter, you will notice that none of them uses an SSL-encrypted connection. Although this may seem to contradict the previous paragraph, you should keep in mind that the store was running in a test environment, in which using HTTPS will just bring additional headaches (not to mention the need of an additional digital certificate). MSCS provides several functions that allow the creation of links that can be made secure by changing a setting in the store configuration, thus allowing the developer to use clear-text communications during the development phase, and then switching easily to SSL once the site goes live.
This is a much more difficult problem to address, and it has to do with the way that MSCS recognizes users. In spite of the fact that they ship together, the various components of Site Server 3 do not integrate that easily. Thus, by default, MSCS doesn't use the functionality provided by Personalization and Membership to recognize users, but rather its own internal engine. (Of course, this can also be thought as a good thing, since you don't need P&M; to run an online store).
As a result, users are tracked in one of two ways. In the first scenario, cookies are used to determine who a user is. Please keep in mind that, as we shall see later on in the chapter, MSCS turns off IIS support for Session objects by default, and forces the use of its own internal tracking system (which is still based on cookies) instead. The reason why this takes place is that sessions are unique to each web server, whereas MSCS's system works by storing all the information in the database, which can be shared across several web servers. As a result, sessions do not work well in a server farm, in which a user can be redirected to any server at any moment, while MSCS works well across any number of servers and is fully scaleable.
There are two main problems with cookies. The first one is that some browsers do not support them, and a lot of users turn them off even if their browser does. The second is that they do not guarantee recognition of a user, but only of a browser. Thus, if more than one person uses the browser, as is often the case in offices or Internet cafes, there is a risk that whatever data is persisted for one user may be visible to the next.
Alternatively, MSCS tracks users by means of a token, called Shopper ID, that is passed on as an HTML parameter in the URL query string. The use of this parameter guarantees that the shopper is recognized throughout the session even though he or she doesn't allow cookies to be employed. However, there is no way to persist the data across sessions, and, since all the information is stored in a database, the store will end up with a lot of wasted storage space. In addition, because users will not be recognized across more than one session, they will have to re-enter all their information every time they need to make a purchase, something that can make shopping at your site less than convenient.
If you are going to need your customers to log in, they should be required to do so only when strictly necessary, such as when accessing their personal information and/or making a purchase. In this case, integrating your store with Personalization & Membership is really a good idea, since you can maintain all the user data, including basket information, in a single place.
All this brings us to the store's database. Many people think that putting a firewall in front of the database server, or even only connecting it to a private network whose only point of access is the web server, is a sufficient measure to keep the data secure.
There are two holes in this way of reasoning. First, many hacking attempts are done from within an organization. There is no simpler way to steal data than entering the server room, logging onto the database server and dumping the tables that hold the user's information onto a floppy disk. Easy and, because most of the time auditing will be off (and even worse, somebody else will have already logged onto the machine, forgetting to lock it when they left), clean.
Second, even if the server is on a network that is not accessible from the outside world, don't forget that the web server must have access to it and, on reflection, anybody who has access to the web server also has access to the database. In fact, users normally have access to it, albeit only to that part of the data that concerns them. If somebody were to somehow hack into the web server and change the ASP scripts so that they return information about any user, that somebody would have successfully hacked into your database server as well, no matter how well protected it is.
Thus, protecting the data storage means making sure that the web server is bulletproof as well. You can do this with a firewall, even though it can turn into a single point of failure. In fact, if you are running a server farm, in which multiple computers provide service redundancy, if the firewall alone goes down, your customers won't be able to view any of the web servers anyway.
There is another way of protecting your data storage. It probably isn't as functional or even as secure as using a firewall, but it's definitely cheaper (firewalls run at about $15,000 apiece). All you need to do is take advantage of NT's built-in security features. They can be accessed through the Control Panel/Network interface (or, alternately, by right clicking on the My Neighborhood icon on the desktop and selecting Properties). The next screenshot shows the Protocols pane of the resulting dialogue box, from which you can access the TCP/IP properties by double-clicking the TCP/IP protocol.
Once you are into the TCP/IP protocol properties, just select Enable Security, then click on Advanced and add the TCP/IP ports that you want to allow access on. In most cases, you will only need port 80 (HTTP) and 443 (HTTPS), while everything else should not be allowed-including the NetBEUI ports that are a hacker's heaven. This configuration will make accessing data on the server through normal NetBIOS sharing impossible, even for authorized persons, but will help in protecting your site from outside attacks. In this case, you can use a staging server for making changes to your site, and then replicate the changes by temporarily restoring access to the server.