16.3 Protecting a Web Site Although Internet technology is fairly old, by computer standards, the options for securing a web site and protecting an Oracle database are relatively young and immature. There are several possible approaches you can implement to help protect your database, including: -
Cookies with the user 's IP address encrypted in a form only your web site can decrypt -
Firewalls both packet-filtering and application-level proxies -
A security server that issues digitally signed certificates of authority -
Access control at the operating system level -
Blind faith that there are so many packets "floating around" that yours won't be intercepted or targeted All these methods (except the last one) are valid approaches for implementing web security. Let's examine each one more closely. 16.3.1 Cookies As mentioned in the terminology section earlier in this chapter, cookies are usually small ASCII text files. Originally, cookies were used by the Netscape browser to help track a user's actions through several HTTP requests . The process of keeping track of a user's movements from one HTTP page to another is known as instantiation . The cookie keeps track of the user's movements forward. Then, when a user wants to return to a previous page, the cookie can be used to help guide the browser backwards through previous pages and URLs of interest. 16.3.1.1 Capturing an IP address Another potential use for cookies would be to have your web site capture and encrypt the user's Internet Protocol (IP) address the first time that user contacts your site. Each time a user re-enters your site and requests information from your database, the IP address your site's software encrypted would be decrypted and compared to the IP address of the user attempting to gain access to your database. Since your software should be the only code that can decrypt your encryption successfully, if the IP address of the user exactly matches the decrypted IP address in the cookie, you can be pretty confident that the user is who he claims to be and that access can be granted. Since the cookie stores the information, you do not have to code any special application to insert or retrieve information from your site's central database for user authentication. 16.3.1.2 A dual approach There is still the slim chance that a sniffer or spoofer could capture your user's IP address and masquerade as your user. Therefore, you might want to implement a dual approach. You could capture the user's IP address to your database the first time the user contacted your site. Each time the user re-entered the site, the visit would be noted in your database by incrementing the site visit column of your tracking table. You might also request and store a password as a column in the tracking table. Suppose that a user suddenly appeared at your site without your site's cookie in the appropriate place (as would be the case with a new user), but with an IP address that matches a known user. You would know and could code an action to take to prompt for the password stored in the tracking table. If the IP address matches the one stored in the database and the user can produce the correct password, access is granted and a new cookie with the correct IP address encryption is placed in the appropriate directory for the user's use. The assumption here would be that the user, or the user's system administrator, had removed the cookie your site's software placed in its known directory location. Obviously, in a corporate intranet, the users and systems administrator would be briefed on the use of the cookie so they would not disturb it. However, systems can be damaged accidentally , so your code would need to be written so that appropriate checks and actions could be taken to not preclude a user from obtaining necessary information from the web site. 16.3.2 Firewalls A firewall is a hardware and/or software system that enforces security on a network. With a common firewall implementation, software running on a router is used to determine, of the requests presented to the router, whether a request should be: -
Forwarded to a secure computer -
Routed to a less secure machine -
Refused and returned to the requester 16.3.2.1 Firewalls to protect privacy A doctor recently discussed her computing concerns with us. She has embraced the latest computer technology by purchasing personal computers for her office and installing software designed to enable her to place all of her patient information online. She is gearing up to make specific parts of her patients ' medical records available to some of the hospital staff to improve the turn -around time in getting her patients admitted to the hospital for tests and surgery. But she is concerned with the questions of how to: -
Enable selection from part of a patient's record without compromising the patient's privacy -
Ensure that only the specific people who should access her system actually access it -
Keep track of who has obtained information from her system and when the access occurred One potential approach the doctor might use to help secure her system would be to have more than one computer. She could compartmentalize her patient information to ensure that only the information she wants accessed will be available to the outside world. Likewise, she could establish a firewall to keep her patients' private information inaccessible to the outside world. The ease of giving access to the hospital employees via a web site is countered by the possibility that someone might compromise her patient records. Costs and benefits must be carefully weighed when dealing with such delicate situations. A firewall may be a good start towards securing the doctor's system while still accomplishing her goal of helping to ease the delays her patients might face when entering the hospital. 16.3.2.2 SQL*Net and firewalls We've looked at many ways of keeping people from gaining access to areas of your system and database from a web site. However, there is a situation we haven't yet examined the ability to allow someone to use SQL*Net (Net8 for Oracle8) to obtain information from your database through a firewall. Why would you want to allow this interaction? Let's say you have a group of sales personnel who travel extensively and need to be able to connect to your database from anywhere in the world. The easiest access to a central computer from around the world would be through the Internet and a company-provided web site. Obviously, you would not want any random person to get to your orders database or see the shipping information about your products. You would, however, like to provide your sales force with easy access to this information. By enabling your personnel to get through the firewall, you provide a means for them to do their jobs more effectively and efficiently . They also gain the ability to better support your customers while not compromising your higher security data. Oracle Corporation has been working with third-party vendors to help them provide ways in which you can enable the access of data from your database through a firewall. As yet, there is little information about the code Oracle has developed to enable users' access through a firewall. The vendor involved must sign an agreement to protect information about the code. You should be seeing this technology from several vendors in the near future. You may want to ask your vendor if this feature can be provided to you and your company. 16.3.3 Oracle Security Server The Oracle Security Server provides you with a method of authenticating users who access your system to ensure that the data you are releasing is really going to the right person. Chapter 15 contains an extensive explanation and evaluation of this free, Oracle-supplied product. 16.3.4 Controlling Access from the Operating System This section provides a brief overview of the options you can use to implement operating system access controls. A detailed discussion of operating system security is outside the scope of this book. There are many good books on operating system security; see Appendix A for a list of some suggested ones. Implementing access controls, either through the creation of directory structures or through the use of group assignments, provides, at best, only limited protection for the files on your system. The determined user who wants to gain access to your files may still be able to do so. As we mentioned, the better approach to securing your system is through the use of file encryption and decryption routines. While not 100% foolproof, encryption and decryption provide a much more imposing barrier to your system files. There are several options you can use from the operating system level to provide security on your system. You can use Java-based scripts, CGI scripts, or a web security server tool like CERN HTTPD or NCSA to enable or block access to your system by: -
Forcing users to have passwords to access areas of your web site or database -
Limiting access to your web site to known user IP addresses, host IP addresses, or host names -
Placing users in groups and allowing specific privileges to different groups The methods you might choose to implement any of these approaches can be scripted in HTML. Some very basic examples are presented here. 16.3.4.1 Using a password file You can create a password file and store it in a specific directory of your choice. As mentioned in the last section, there are several different web server software packages you can use to create a password file and add users to the file. Be sure the package you choose provides encryption and decryption so your users' password information cannot be easily compromised if someone gains access to the directory in which your file is stored. Once you have created the password file, you need to add the names and passwords of users you are allowing to access your web site and/or database. Depending on which web server software you are using, you need to modify your security configuration file to add information about the location of your password file. You might want to protect access to a specific directory or set of directories. You would put this information into the configuration file as well. When a request is presented to your site, the user is prompted to enter a username and password. The server software will verify the information presented by checking for the file in the directory that has been specified in the configuration file. If the information matches, the user is granted access to the directory or database which has been requested . Again, Java-based scripts, CGI scripts, or a web security server tool like CERN HTTPD or NCSA can be used to implement password-protected web site access. 16.3.4.2 Access by IP address or host In a manner similar to that used to implement password protection on your site, you can store a list of accepted IP addresses. When a user presents a request, the server software checks a file of valid user or host IP addresses and determines whether the requester is coming from a known computer. Access can then be granted or denied based on the results of the IP verification process. A potential problem with using IP address verification is that there are ways to enable a computer to masquerade as another machine and present a seemingly valid IP address. 16.3.4.3 Access by group As we saw in Chapter 7, you can set up operating system groups and control access to files by only permitting that access to specific groups. Don't confuse the reference used here to "group" with an operating system group like osoper or osdba . Just as Oracle roles are used to define privileges for many people both easily and centrally , the web server group access approach is a way to enable many people to access a directory or a database. A group, in this case, is merely an alias for a set of users and is used like an Oracle role. The difference is that the web server group is listed in a file and is identified in the server configuration file rather than in the database. To define a group, you create a file using your web server software in much the same way you did for usernames and passwords or IP addresses. You will also list the users who are members of the group. When a user attempts to access information on your site or from your database, the user's name will be checked against the list of people in the group who have access to the site area of interest. If the user's name is present in the appropriate group list, the user will be permitted access to the area.  | 
