This document provides an overview of how JavaServer helps you to provide a secure web site, and discusses each of the key mechanisms provided in the current release.

• What Website Security Should Mean to You
• Current Release Features

NOTE: Please report any security problems you uncover to the support alias listed at the bottom of this page.

What Website Security Should Mean to You

Services shared by many people need to defend against a variety of problems. The solutions to these problems are often lumped together as "security". One of the most effective ways to understand what this "security "does for you is to describe the kinds of threats or attacks your website can defend against.

At a high level, JavaServer allows you to defend your website against these (and other) kinds of attacks:

• Theft or Alteration of Data ... By providing classic identity based access controls, and in conjunction with physical and operating system protections, JavaServer lets website administrators control who can get data (and who can't). The data which is protected includes both web pages and the website's administrative data.
• Malicious Code ... By restricting the servlet code which can run, and the "sandbox" environment in which it runs, JavaServer lets website administrators control the damage that malicious code can cause.
• Eavesdroppers ... Even when your website itself is secure, users of your site need to be concerned that their data (e.g. financial or other highly sensitive data) is not misappropriated when it is being sent to (or retrieved from) the server.

Your Site's Security Policy

Each website has a security policy which defines "how secure this site needs to be". (Sometimes it's not very well articulated!) A security policy talks about more than just "how to secure this website". It also talks about the kinds of risks that are acceptable, and those which are not. There will always be risks that you deem to be acceptable. Consider your home: just how determined must a burglar be to get access and steal your silverware? Many people don't defend against burglars willing to break windows to get in. Even among those which defend against such burglars, not everyone needs the same degree of paranoia. The same kind of "risk versus reward" tradeoffs need to be made on your website too.

Your Website Administrator

Your security policy is implemented by your website administrator. He (or she) uses the web server software and other tools such as operating system security, and physical security controlling access to the server and to its backup media. Your site (the service provider, and its users) needs to trust the administrator, host system, and the web server software to maintain your security policy. Un-trustworthy staff is the number one security risk in any organization. You can never trust only software mechanisms, since they can be overridden. Your staff also need to be trustworthy.

JavaServer can't help you find a website administrator that you can trust not to violate your security (or that of your clients). Nor can JavaServer help you keep users from being given more trust than they really deserve, or help you choose an operating system that's worthy of your trust. However, we do provide a number of mechanisms that a trusted administrator can use to secure your site against common website security threats.

Current Release Features

HTTP-Oriented Support

The HTTP protocol provides a number of security features which almost any web server will support in some manner.

• Basic Authentication ... Authentication involves a user entering a user name and a passphrase, for example into a login prompt or (in a graphical user interface) a dialog box. HTTP defines "Basic Authentication". To get access to a particular web page, you must authenticate and then pass an access control check. JavaServer supports this "Basic" authentication scheme, using Access Control Lists (described later) to control access. However, there are two well recognized problems with this standard HTTP mechanism:
  • "Basic" authentication sends the password over the network, effectively in "cleartext" so that any eavesdropper can determine the right password to use. (Both "Digest" authentication, described below, and SSL client authentication, protect against this attack.)
  • A closely related problem is that the server needs to store the passwords in cleartext; they are "shared secrets". This means that when (not if!) a server is broken into, the attacker gains the right to authenticate as each user. Since users frequently use the same passwords at many different sites, this is a threat against both those users and all those other sites. (SSL Client authentication is used to protect against this kind of attack.)
• Digest Authentication ... As noted above, there are two significant problems with "Basic Authentication" in HTTP. The "plaintext passwords on the network" problem is resolved with "Digest" authentication; although the password must be known to the server, it is not sent over the network. No eavesdropper can read passwords on their way to your web server. However, the server must still know the client's password. Although this is safer than sending the password over the network, the client, and other servers, are still at high risk when the server is successfully attacked.
• SSL Server Authentication ... Users need to have a way to trust that the server to which they send information -- such as a credit card -- is really the server they think it is. SSL always authenticates the server to the user of a browser; HTTPS URLs (which use SSL) let users know that the server they're talking to is who they think it is. This is usually done with the assistance of some third party Certificate Authority, which provides a clearly defined level of support for a guarantee that the server is who it says it is. It also requires support from your web browser (such as HotJava) to let users choose which web sites and certificate authorities they trust.
• SSL Privacy Protection ... Another feature of the HTTPS protocol is that, when allowed by both the web site administrator and by the client using a web browser, all data sent to or from the server can be encrypted to allow private communications. This means that an eavesdropper can't learn potentially sensitive information about your personal finances, or anything else you manage on-line.
• Realms with Users and Groups ... When you have many users, you need to group them for two reasons. Both are supported in JavaServer:
  • You need to create different realms for different sites, e.g. different virtual hosts, or parts of a given website serving different applications. Users named "dave" in two different realms are actually two different identities, and will be given two different sets of access privileges.
  • You need to create groups of different users (within a given realm) so that you can extend access privileges more efficiently than listing the users one by one. For example, you might want to define a group "admins", all of whom can access administrative web pages.
• ACLs Protect Web Pages ... JavaServer provides "Access Control Lists" (ACLs) to let your website's administrator control which users get access to individual web pages or trees of such pages. ACLs may also be used by servlets. To use Access Control Lists, you need to understand several concepts:
  • There are user accounts, each with a unique password (or passphrase). Users often have home directories.
  • Those users may be assigned to groups.
  • ACLs assign permissions to users and groups, such as the permission to GET a web page or to POST form data to a servlet. ACLs may also deny permissions.
  • Users, groups, and ACLs are all scoped within a realm. Users with the same name, but in different realms, normally have no relationship.

Java-Specific Server Features

JavaServer offers a number of features beyond those minimal ones supported by almost any web server:

• Simple Administration ... Although it is not always recognized, having good tools to handle administration tasks is an advantage in terms of security. The reason is that manual administration (for example, editing any kind of text files by hand) is extremely error prone, and errors invariably reduce security. JavaServer provides administrative tools which help avoid common administration errors.
• Secured Administration ... By default, the JavaServer administration pages are controlled through HTTP's new "Digest Authentication". In addition, these pages may be accessed through "HTTPS", so that the administrative operations are protected from certain "active wiretapper" attacks and may be kept private.
• Servlet Sandboxing ... Servlets are code modules used to extend your web server. They may be provided by your own site developers, or they may instead be acquired from third parties who you have less reason to trust. Servlets run inside of a "sandbox", where it's safe for them to do anything. There is a "Security Manager" which ensures that servlets are only allowed to perform potentially dangerous operations (such as opening files or accessing the network) in specific circumstances:
  • The servlet must be delivered in a Signed JAR file, which is a new JDK 1.1 feature.
  • Whoever signed that JAR file must be explicitly recognized through server administrative tools, and granted permission to perform those dangerous operations.
  • Alternatively, servlets which were not delivered in signed JAR files may be installed in a way which grants them arbitrary privileges. This is how internal servlets are currently given permissions to read files and databases.

UNIX-Specific Server Features

The JavaServer provides, through an optional native code module, several features which are commonly provided on UNIX based web servers. (The JavaServer works fine without that native code module, but it does not offer these features.) These features are important because UNIX is the most popular secure system platform for web servers, and system administrators for UNIX platforms have shown they want these features.

• Non-root UID/GID ... UNIX only allows "root" to bind to the default HTTP server TCP port (80). This means web servers often need to start up as root, just so they can bind to that port. However, letting complex programs run as "root" is generally perceived to be a big security risk, so most sites prefer not to allow this. JavaServer allows you to control which UNIX user ID to use after your server binds to that TCP port. This lets you run JavaServer as your default server, without worries that a malicious servlet can commit some of the mayhem that only "root" should be allowed to perform. In fact, JavaServer can be set up so that the "root" account is needed only when initially setting up JavaServer, and all normal administrative tasks can be done without needing "root" privileges.
• UNIX Account Support ... Any UNIX system already has a database of user accounts, which is administered by the system administrator. At many sites it is preferable to use that database, rather than one of the realms administered by the JavaServer, with ACLs. A "UNIX" realm is supported by the JavaServer. This allows UNIX user accounts to be used for access control, eliminating the need for "double administration". There are security advantages to this; for one example, UNIX passwords are not stored in plaintext. Also, home directories of UNIX users may contain web pages, which can be automatically exported through the JavaServer.

Top