|
|
|
|
|
|
|
|
|
|
|
|
||||||
|
|
|
|
|||||
|
|
|||||||
|
|
|
|
|
|
|||
|
|
|||||||
|
2001
Conference Proceedings, June 11-14, 2001
|
 |
|
Computer
and information security considerations for installing and running Microsoft
Internet Information Server and Microsoft SQL Server Robin
Snyder Abstract
Computer
and information security is becoming an increasingly important problem
in a society that is becoming more and more dependent on information systems
and computer technology. In any system, security is only as good as the
weakest link, and most web-based systems have many weak links. And since
computer and information security is a continuing process rather than
a one and done product, one can never learn too much about the topic.
This paper/talk will discuss/present an introduction to computer and information
security with particular emphasis on security considerations for installing
and running Microsoft Internet Information Server and SQL Server in a
web environment. Introduction
As
computer and information security is becoming increasingly important,
it is no surprise that the area of computer and information security is
a huge field. There are many books on the subject. A good survey can be
found in [6] while an entertaining history of cryptography can be found
in [8]. For fairly current information in a cookbook format, the book
"Hacking Exposed" [4] is an invaluable and interesting reference. For
example, one is usually taught that it is easy to monitor traffic on a
unswitched Ethernet network as all messages are broadcast to any computer
that wants to listen while a switched Ethernet network only sends messages
to the intended recipient computers. Thus, a switched network is much
more secure than an unswitched network. But, the book provides detailed
instructions are provided for how to monitor traffic on a switched network
[4, p. 443-456]. Of course, you need access to at least one line or station
on that switched network, but if you are under the illusion that such
a network is inherently safe, you might be susceptible to such an attack.
Even more recent information can be found by doing a web search and/or getting on a mailing list. InfoWorld publishes free email newsletters on various subjects. See http://www.iwsubscribe.com/newsletters/
for more information. The "Security Watch" newsletter has current and
important information on security. As the InfoWorld site advertises, "If
your network's not secure, you're toast. Get practical advice on how to
run a tight ship with InfoWorld's security guru P.J. Connolly, in this
hands-on, technically oriented weekly column." (as of 4/10/2001).
There are also numerous web sites created and maintained by hackers for
hackers, to quickly disseminate the latest techniques. The problem is
made worse by the fact that the Internet crosses international boundaries.
Thus, even if there are applicable laws in your country, those laws may
not apply in other countries. And, one countries villain may be another
countries hero. In a global community, you can be attacked electronically
from anywhere. The
fundamental assumption in information systems and computer technology
security is that a potential adversary has access to all published information.
The logical consequence of using this assumption as basis for systems
design criteria is that everyone should only have access to information
that they need to do their job. This is much easier to do in a closed
system, such as an intranet, than it is in an open system, such as the
Internet. On the Internet, every adversary not only has access to your
system, but has access to a wealth of published information of which you
might not even be aware. Use
effective measures that are easy to do There
is no such thing as absolute security, as long as people have access to
the computers and/or information that needs to be secure. Think about
it. If the White House, FBI, NSA, etc., can't do it, can you? On the other
hand, you do want some security. And, since a system is only as secure
as its weakest link, and you often do not know what that weakest link
is, the cost of approaching maximum security can be prohibitive. The middle
ground is that you should get and use the security for which you are willing
to pay the cost. When
connected to the Internet, every hacker in the world has access to trying
to break your security. Many hackers, like thieves, go looking for easy
places to break into. So, as a minimum, you should do everything that
is easy to do from a security point of view. One
of the easiest things to do to avoid security problems is to always have
the most recent software fixes installed on your production servers and
client machines. For Windows platform client machines, one should check
the "Windows Update" site often for updates. One way to do this is as
follows.
I
prefer not to have the overhead and inconvenience of the "Windows Critical
Update Notification" update, so I do not install that feature, but I do
try to check it at least once a week or when I hear news of a security
problem involving Microsoft. The critical updates often involve some new
way that someone has found to compromise the security of Internet Explorer.
A
commonly used production web platform consists of Microsoft IIS (Internet
Information Server) as a web server and Microsoft SQL Server as a database
server, although it is possible to use them together as a development
system in addition to a production system [9]. It is fairly easy to install
and configure each into a usable web system. It is quite another matter
to make sure that the web system is secure. For servers, one should check
for updates to IIS, SQL Server, etc., especially those updates that relate
to security. Here are some relevant links.
Of
course, the Microsoft site seems to change often, so you might have to
hunt for what you want, but the search engine makes it fairly easy to
find things. Other platforms will have similar sites. An
example of something that is hard to do is to protect a web server from
a Dos (Denial of Service) attack whereby a hacker, or group of hackers,
makes a huge number of requests to a web server, thus keeping it busy
so that it can do little or no useful work. The
human factor In
1993, Bruce Schneier wrote the first edition of a best-selling book entitled
"Applied Cryptography" [5] in which described the mathematical basis for
cryptography and provided source code that many a programmer has used
to create secure systems. When he started consulting for companies, he
began to how woefully inadequate that book was in terms of the human factor
of security. One colleague told him that "the world was full of bad security
systems designed by people who had read Applied Cryptography.". [6, p.
xii]. Observing that cryptography is a branch of mathematics while security
involves people and digital security involves complex, buggy computers,
Schneier went on to write "Secrets & lies: digital security in a networked
world", a must-read for anyone interested in security as opposed to cryptography.
As he states, "If you think technology can solve your security problems,
then you don't understand the problems and you don't understand the technology.
... in order to understand the security of a system, you need to look
at the entire system - and not at any particular technology." [6, p. xii-xiii].
In
particular, "Security is a process, not a product." [6, p. 84]. Security
involves the human factor and is only as strong as the weakest link. A
common example is the use of password protected resources. The strongest
cryptography will not help if a user compromises their password. The term
human engineering is used, especially in the hacker community, to refer
to talking your way into getting the information you need from a human
rather than getting it through a computer. Posing as someone else on the
telephone, hackers can get password, configuration information, etc. For
example, what would you do if someone called you who sounded like they
knew what they were doing and said something like the following. "Hello.
This is name from the IT department help desk and we are having
problems with your account. If it is OK with you, all we need to fix it
is your password so that we can login to your account, fix the problem,
and then logoff. We'll let you know when we are done. It should only take
a few minutes.". In a large company you might not know who is calling.
Let
us now look at a few examples of aspects of system security for Internet-based
systems involving web server and database server. Firewalls
The
typical tiered information systems model of a web-based system consists
of the following layers.
Between
the presentation layer and the business logic layer is a firewall that
only allows certain TCP/IP messages to pass through the firewall. The
Internet is outside the firewall while the local intranet is inside the
firewall. Of course, there are more sophisticated configurations where
more than one firewall is used, but that is beyond the scope of this discussion.
A
free, for individual noncommercial use, firewall software program that
the author uses is ZoneAlarm (version 2.1.44) available at http://www.zonelabs.com
(as of April 11, 2001). Such software will not only help protect your
computer, it will make you more aware of what a firewall program does
and how it does it. For home users connected to the Internet via high-speed Cable Modem or DSL (Digital Subscriber Line) phone access, security can be a problem as computers left on are always connected to the Internet, even when no one is using them who might otherwise notice if something unusually is happening, such as a hacker attack. Installation of a Cable/DSL router, such as the LinkSys, at http://www.linksys.com, EtherFast 4-Port Cable/DSL Router provides a 4-port high speed 100Mbps switch (for client stations) and 10Mbps WAN connection to the cable/DSL connection and provides NAT (Network Address Translation) to isolate the internal home intranet from direct unsolicited access from the Internet. However, if you connect the Internet from the intranet, the connected site can communicate back to the site that initiated the communication. The standard IP intranet addresses are as follows.
Most
companies and academic institutions use NAT to isolate the intranet from
the Internet. In most cases, direct access to SQL Server is only allowed
from within the firewall (i.e., on the intranet). Thus, users outside
the firewall cannot directly access SQL Server. Instead, the firewall
allows traffic on the http: port (port 80) and the https: port (port 443)
to pass through the firewall in both directions. Often, some other ports
(e.g., email) may also allow messages to pass. Since the web server is
inside the firewall, it has direct access to SQL Server. Thus, the web
server acts as a intermediate control point between the user and the database.
Thus, if the ASP server-side processing code were written correctly, and
there were no software bugs in the system, then, the human factors of
cooperating users would be the primary security problem. But, since many
bugs exist in the systems software, and the programmer-written application-specific
software (e.g., ASP pages) is not written bug-free, an uncooperating-user
has many opportunities to break the security of the system. One
common problem is a hacker stuffing an input field with values that were
not anticipated by the programmer. Normally, when writing self-contained
software that will run on one computer at any one time, the programmer
assumes a cooperating-user model whereby if all code within the program
checks the validity of parameters passed to a procedure, that procedure
need not check those parameters for validity (Nicklaus Wirth, inventor
of the Pascal programming language used this model in his design of the
Oberon system, which never gained the popularity of the predecessor languages
Pascal and Modula). Although this approach can make for a more efficient
program, the assumptions do not hold in a distributed web environment.
In general, parameters should be validated at the client browser, must
be validated at the web server, and should be validated again at the database
server, just in case. One must also look at how the input data is used.
If
the input data is to be displayed as HTML, then a hacker could input code
that, when displayed as HTML, would, say, load an ActiveX control from
someplace on the Internet. If the ActiveX control gets loaded, and is
given access to the user's computer, as might easily happen, then the
ActiveX control could do anything it wants on the user's computer. This
is not good. One
way around this problem is not to display HTML directly. The Server.HTMLEncode
function will, for example, convert "<TAG>", which, depending on
the TAG, could do something bad, to "<TAG>", which will display
without any side-effects. Another
problem might be that if single-quotes are included in the input, and
that input is passed to SQL Server as an encoded SQL command, then the
single-quotes might mess up the query. One way around this problem is
to replace all single quotes in such text strings with two single quotes
so that the SQL command is interpreted properly. The
problem with such pages not working right might be a direct security problem.
In other cases, the page might just not work right. But, when a page does
not work properly, sometimes the error message might give useful information
to an attacker, besides just looking bad to the viewer. It
must be remembered that even if data validation is done at the client
web page, the knowledgeable hacker need not use that web page. All parameters
from an HTML page are sent to the web server in a well-known format. Anyone
can do a "View Source" and see how the parameters are sent. Thus, a hacker
can send the input directly circumventing any checks made at the client
web page (e.g., using built-in HTML limitations, JavaScript validation,
etc.). To see that this feature can often be used for good by users, consider
the following. The Winthrop library has a way that one can look up books
on-line through the web. It is somewhat cumbersome, but it works well.
The library uses URL-encoded parameters and it is easy to figure out how
it does it. So, the author has set up a page with references for certain
textbooks with the URL encoded to directly look up the books along with
the current status (e.g., on-the-shelf). This is a good use of a feature
that can be used for devious purposes by hackers in other contexts. Microsoft
Internet Information Server The
use of Microsoft IIS as a web server could easily fill several huge books
(see, for example, [1], [11]). The
most secure web servers only allow client browsers to request static HTML
pages without any server-side processing. However, to be useful, a web
server needs to provide some form of server-side processing. The
rights that a web page with server-side processing has on the web server
can be a combination of "Read", "Write", "Script", "Execute", and/or other
rights supported on that server. Usually, on a web server that supports
server-side processing, "Read" and "Script" are granted in most directories.
However, directory browsing should be turned off so that a client browser
can only access files that are linked, in a transitive manner, from the
main web page. Having "Read" access but not directory browsing access
means that one can read any file or subdirectory in the directory, but
one cannot see what is there. One must, instead, know what files and/or
subdirectories are there. "Script" access allows scripts, such as ASP
scripts, to execute on the server. To
be safe, one should turn off or not install options, such as FrontPage
Server extensions, which contain security problems, unless one has a good
reason use them. As a practical matter, a good way to do this is to get
the web server running with all options installed, and then remove them,
one by one, every few days, or weeks, so that if removing any one of them
causes any problems, it should be easy to detect what change caused what
problem. The worst way to do it is to make a lot of changes at one time
since if there are any problems, you will not know what caused the problem,
especially if care was not take to document the exact changes as they
are made. One
useful design is to create a front-end web server, outside the firewall,
perhaps hosted by at a site through an ISP, that serves only static HTML
pages. The front-end site has a link to a back-end web server that requires
that the user login. From the server point of view, each web page transaction
is separate from each other web page transaction. However, the use of
cookies allows the web server to track client behavior from client requests
to client request in what is called a session. Systems such as ASP make
tracking such sessions fairly easy and transparent. The user can be authenticated
once and then tracked in a session variable until it expires. Or, the
user can be authenticated on every access by passing the login parameters
(i.e., user name and password) from access to access, which obviates the
need for cookies or for the client browser to have cookies enabled. If
at any point a request is made that does not have the required user name
and password as parameters, the login box appears before anything else
can be done on that site. Better yet, use the session authentication and,
if cookies are not enabled, use the page to page authentication. There
are two primary ways to pass parameters from client machine to web server,
GET parameters or POST parameters. A GET parameter is a URL-encoded parameters.
However, GET parameters are not very secure as the URL is passed as plain
text, can be saved and/or bookmarked as a favorite, appears in the history
list, etc. Such parameters are nice for saving queries from search engines,
so that the exact page can be found again, but are not good from a security
point of view. Most secure pages use POST parameters whereby the parameters
are passed in the body of the http: message. However, this is only useful
only as long as eavesdropper cannot monitor and read the message. This
requires that the messages sent between client browser and web server
be encrypted which requires a brief overview of cryptography as it relates
to web systems. Cryptography
Communication
using cryptography involves the sender encrypting a plain text message
and transmitting it to a recipient so that it can be decrypted to the
original plain text message by the recipient while anyone else who has
access to the message should be unable to decrypt the message to the original
plain text. Efficient
symmetric cryptography methods such as DES (Data Encryption Standard)
exist to securely encrypt/decrypt messages by use of a symmetric key,
provided that both sides have the key. The primary problem is in key distribution
as encryption using the existing keys cannot be safely used to send the
new keys. Public
key cryptography, or asymmetric cryptography, partially solves the key
distribution problem and makes possible the concept of digital signatures.
The most popular public key cryptography method is the RSA (Rivest, Shamir,
and Adleman), the details of which are not important here. What is important
is that each user has a private key and a public key. Given the public
key, one can encrypt messages, but one needs the private key to decrypt
messages. Software can generate both private and public key pairs for
any user. As keys are public, the key distribution is partially solved.
But,
how does one know who the message came from? Since one can encrypt or
decrypt plain text, user A can decrypt a plain text message first, then
encrypt it with user B's public key and send it to B. Now, only user B
can decrypt the message and then encrypt it using A's public key to make
sure that it only came from user A, as only A can decrypt the message.
This concept is the basis for what is called a digital signature. In
general, asymmetric cryptography is much less efficient than symmetric
cryptography. So, in practice, messages consist of two parts. One part
uses asymmetric cryptography to form the digital signature and exchange
symmetric session keys, good for only that message or session. The rest
of the message uses the more efficient symmetric cryptography. This method
was made popular by the email program PGP (Pretty Good Privacy). Secure
sockets layer security The
web incarnation of public key cryptography is called SSL (Secure Sockets
Layer) security. If enabled on a web server, it uses, by default, port
443, for a service called https:, as opposed to the standard http: service
on port 80. SSL is easy to enable on a web server, if supported (as it
is on IIS). The more bits used, the more secure is the communication.
However, decisions involving how to use SSL are sometimes complicated.
There is just one setting in one dialog box in IIS on the web server that
sets the encryption strength security required to access the web server,
and it is easily changed. In
general, the web server owner must make the final decision based on how
much risk of information compromise they are willing to tolerate in relation
to the configuration problems that clients with older browsers might have
upgrading their older browsers to the required encryption strength. Since
even 128-bit encryption is not absolutely safe, there is always some risk
of information compromise, so that is not the question. The question is
how much risk of information compromise is tolerable. A reasonable compromise
would be to set the required encryption strength to 40-bit encryption,
which would handle most browsers, and strongly recommend to clients that
they use 128-bit encryption strength (which would still be supported by
the server). Any client doing any transaction on the Internet that involves
personal information that might be compromised should never use less than
128-bit security, but that is a decision that clients should make on their
own and not be forced unless the server owner is not willing to tolerate
the risk of a less secure transmission method. The
encryption strength, measured in bits, must be one that is agreed on by
everyone in the industry. You cannot use an arbitrary number. Some current
standards are 40-bit, 56-bit, and 128-bit. Ignoring some mathematical
points, adding one bit essentially doubles the security of the encryption.
So, 56-bit encryption is about 65,000 times more secure than 40-bit encryption.
And, 128-bit encryption is a million-million-million times more secure
than 56-bit encryption. It is believed that only agencies such as the
NSA have the resources to break 128-bit encryption. On the other hand,
breaking 40-bit encryption can be done by motivated college students without
too much difficulty and without requiring too much time. The
guideline for the client is that the client should use the strongest encryption
available and that is supported by the server. The server can be set to
always accept 128-bit encryption even if it is set to accept a lower level
of encryption. The guideline for the server is less clear, as it involves
making a business-technical tradeoff that can not be made based only on
technical decisions. The decision depends on how much risk the server
owner is willing to tolerate. For
example, in banking, if the server owner (the bank) decides to use lower
encryption, and someone breaks it and steals money, the bank is taking
the risk. So, the bank would typically require 128-bit security. The same
reasoning applies for credit card transactions over the Internet. Due
to U.S. law, the merchant and/or bank would be liable in most cases, so
they are taking the risk and would usually require 128-bit security. As
a client, I do not want to take a chance on the risk and the time and
effort to make things right, so I would opt for 128-bit security. From
a security point of view, one wants the strongest encryption possible.
One drawback is that it requires more processing on both client (not very
important) and server (could be important with very high volumes of sessions
using encryption). The
primary practical problem with requiring 128-bit security is that clients
with older browsers would have to upgrade those browsers to use a higher
encryption strength. This could present significant problems if the users
in question have older browsers and are not computer savvy about performing
the rather simple (for computer savvy users) upgrade themselves. Due to
changes in the U.S. export restriction laws, all new browsers (e.g., I.E.
5.0 and above) come with 128-bit encryption, so this problem should become
less and less important in the future. There
have been bugs in software that has crippled the use of SSL. An early
version of Netscape had a predictable way of generating private keys.
Later, it was demonstrated how to patch an executable version of Netscape
so that it would always use the same private key. So, using SSL is only
as good as the system in which it is operating, which changes every time
that a client browser or web server is modified. User
authentication Usually,
some form of user identification along with a password is used to authenticate
the user to the system so that the system is fairly confident that the
user is who the user claims to be, the definition of authentication. NTLM
(NT LAN Manager) authentication is used by NT/2000 for authenticating
users. Without getting into details, it works using a form of public key
cryptography whereby the server can authenticate the client without the
password every passing over the wire. This is achieved by passing information
back and forth so that the server, but not an eavesdropper, can authenticate
the client. Since every process on NT must run by impersonating some valid
user account, and since NTLM does not provide NT with a userid and password,
and since NT security does not support delegation, access to the hard
drive and other resources (e.g., SQL Server) can be a problem under NT.
One is left compromising security to some extent. On
IIS, one can use no authentication (the default for most users browsing
web sites), or other forms of authentication. NTLM is sometimes used,
mostly in an intranet environment. Client-side certificate authentication
can also be used (see certificate-based security below). Unfortunately,
NTLM authentication authenticates only the client to the server, not the
server to the client. Microsoft has adopted a form of Kerberos security
for Windows 2000. The primary importance of Kerberos security is that
it authenticates the server to the client. In a multi-server environment,
such as a web server and database server, each server can be authenticated
to the other as trusted so that client login credentials can be used to
safely impersonate that client by one server in requesting services from
the other server using the rights of the client, thus solving the delegation
problem. Thus, one can use Windows login authentication on the web server
and pass that authentication on to SQL Server. Server
authentication The
purpose of the encryption security is to establish a secure connection
between the client and the server so that an eavesdropper cannot listen
in on the conversation (e.g., to get login names and passwords, to get
information, etc.). The login name and password is used to authenticate
the client to the server, but how does the user know that the server is
who the server claims to be. For example, when the URL http://www.company.com is typed and Enter is pressed, how do you know that you have reached the company who owns that URL. The DNS (Domain Name System) is a distributed database system that is responsible for converting domain names, as used in web URL's, into IP addresses. It is possible, and it has happened, that a hacker could do the following.
So,
again, how does the user and/or client browser authenticate the server?
To partially solve this problem, certificate-based security was developed
to authenticate the server to the client. The system works by creating
a hierarchy of certificates that involve cryptography and trusted company
verification that the certificates are valid. Although full of loopholes,
this is the current state of the art in server-based authentication. In
particular, one weak point is that how does one know whether to trust
a certificate. Most trusted certificates are issued by companies such
as VeriSign (a spin-off from RSA Systems). But those certificates can
be costly ($100 to $1000 or more per year). And, if you have multiple
web servers and/or IP addresses, change domain names, change IP addresses,
or lose your certificate or password, you will need to get a new one.
Of course, you can get a certificate from a less-trusted source. Or, to
avoid all costs, you can become issue your own certificates to yourself
using Microsoft Certificate Server, included with IIS. But, even if you
get a certificate from a trusted source, such as VeriSign, that is no
guarantee as the checks on requests for certificates are minimal, in most
cases, and although there is a provision for revoking certificates (in
a way that is similar to the expiration date on a credit card), most software
does not support such revocation. In early 2001, a hacker posing as a
Microsoft employee used human engineering to talk someone at VeriSign
into issuing two digital certificates to the person with Microsoft as
the trusted source as verified by VeriSign. Shortly after it was discovered,
Microsoft started working on patches and VeriSign revoked the certificates,
but the existing system for checking for revoked certificates is not really
reliable or even used in most cases. Such a certificate would allow a
hacker to have complete control over a client computer if that client
computer downloaded an ActiveX control and trusted Microsoft the download.
This would happen automatically if the user had checked the box to "Always
trust Microsoft". The Microsoft fix would, presumably, check for that
particular certificate, but there could still be problems. Returning to
the user authentication using parameters passed from client browser to
web server, the web server should have SSL turned on and require secure
https: to the pages that are to be secure. In addition, the web server
should install the necessary certificates to reasonably prove to the client
that the web server is who the web server claims to be. Microsoft
SQL Server The
use of Microsoft SQL Server as a database server could easily fill several
huge books (see, for example, [3], [7]). SQL Server installation is fairly
straightforward. SQL Server is normally behind the firewall and is only
directly accessible from the web server and from client computers within
the intranet. SQL
Server has an extensive security model consisting of users, logins, roles
(i.e., groups), and permissions for users, tables, views, stored procedures,
etc., much of which is beyond the scope of this paper. One users, logins,
groups, roles, etc., are set up, security access to SQL Server can be
via integrated security using Windows login (e.g., NT authentication),
or mixed security, which uses SQL Server standard login using userid and
password (not as secure over the wire, so you want traffic to and from
SQL Server hidden from the outside world). Since integrated security cannot
be used in an NT environment from the Internet point of view, the userid
and password for standard security appears in each ASP web page that does
database access, so you do not want anyone to be able to view the source
code of ASP web pages. Hackers are always looking for bugs that would
allow them to view the source code of ASP web pages in order to obtain
such information. There are known bugs that allow them to do this, so
make sure that you have the most recent updates to your web server. From
a web system point of view, each ASP page, which by default impersonates
the IUSR_MACHINENAME user, must have a user login and password to access
the SQL Server database. Prior to Windows 2000, standard login was the
approved way to access SQL Server as even though the web server might
use Windows authentication, there was no way to delegate to SQL Server
the same authentication rights. Since NT authentication for IUSR_MACHINENAME
does not match any client authentication using NT authentication, and
that authentication cannot be delegated, one is left with standard SQL
Server login. A
VPN (Virtual Private Network), as supported by Windows, provides a way
for a client computer to connect to an intranet by tunneling through a
firewall using an existing Internet connection. Once connected, it is
as if the client computer were actually on that intranet. This is important
if one need, say, to access SQL Server from the Internet as the firewall
will not permit direct access. VPN's provide a convenient way to connect
to an intranet without using a dial-up connection with a modem, which
can be even more of a security problem. Anyone using Microsoft VPN software
should update to the latest version (1.3 or higher) to avoid certain well-known
security problems with earlier versions. Summary
This
paper has covered just a few of the many important computer security aspects
of installing and running Microsoft Internet Information Server as a web
server and Microsoft SQL Server as a database server. References
[1]
Braginski, L., & Powell, M. (1998). Running Microsoft Internet
Information Server. Redmond, WA: Microsoft Press. [2]
Howard, M., Levy, M., & Waymire, R. (2000). Designing secure web-based
applications using Microsoft Windows 2000. Redmond, WA: Microsoft
Press. [3]
Petkovic, D. (2000). SQL Sever 2000: A beginner's guide. Berkeley,
CA: Osborne/McGraw-Hill [4]
Scambray, J., McClure, S., & Kurtz, G. (2001). Hacking exposed:
network security secrets and solutions, 2nd ed. Berkeley, CA: Osborne/McGraw-Hill.
[5]
Schneier, B. (1995). Applied cryptography : protocols, algorithms,
and source code in C, 2nd ed. New York: John Wiley & Sons, Inc.
[6]
Schneier, B. (2000). Secrets & lies: digital security in a networked
world. New York: John Wiley & Sons, Inc. [7]
Shepker, M. (2000). Sams teach yourself SQL Server 7 in 24 hours.
Indianapolis, IN: Sams. [8]
Singh, S. The code book. New York: Anchor Books. [9]
Snyder, R. (2001). Creating a fully-functional stand-alone web development
system that includes web and database servers. Proceedings of the 34th
Annual Conference of the Association of Small Computer Users in Education.
Myrtle Beach, SC. [10]
Stein, L. Web security: a step-by-step reference guide. Reading,
MA: Addison-Wesley. [11]
Stewart, J., & Chandak, R. (1999). A guide to Microsoft Internet
Information Server 4.0. Cambridge, MA: Course Technology. |
 |
||
| ©2001-2002 ASCUE, Inc. |
email:
clsmith@depauw.edu
http://www.ascue.org |
Latest
update: 3-nov-01
|