Have an expert review network services such as e-mail programs or directory services to ensure that a malicious attacker cannot access the operating system or system-level commands. The way you do this depends on the operating system you use.

Sharing a file system with other machines in the enterprise network imposes risks of a remote attack on the file system. Be certain that the remote machines and the network are secure before sharing the file systems from the machine.

Set operating system file access permissions to restrict access to data stored on disk. This data includes, but is not limited to, the following:

The database files. GlassFish Server includes Apache Derby database, however, you can use any JDBC-compliant database.

The directory and filename location of a private keystore, such as keystore.jks

The directory and filename location of a Root Certificate Authority (CA) keystore, such as cacerts.jks.

For example, operating systems provide utilities such as umask and chmod to set the file access permissions. At a minimum, consider using "umask 066", which denies read and write permission to Group and Others.

The directory structure in which GlassFish Server is located, including all files, should be protected from access by unprivileged users.

Taking this step helps ensure that unprivileged users cannot insert code that can potentially be executed by GlassFish Server.

Avoid creating more user accounts than you need on host machines, and limit the file access privileges granted to each account. On operating systems that allow more than one system administrator user, the host machine should have two user accounts with system administrator privileges and one user with sufficient privileges to run GlassFish Server. Having two system administrator users provides a back up at all times. The GlassFish Server user should be a restricted user, not a system administrator user. One of the system administrator users can always create a new GlassFish Server user if needed.

Important: Domain and server configuration files should be accessible only by the operating system users who configure or execute GlassFish Server.

Review active user accounts regularly and when personnel leave.

Background Information: Configuration data and some URL (Web) resources, including Java Server Pages (JSPs) and HTML pages, are stored in clear text on the file system. A sophisticated user or intruder with read access to files and directories might be able to defeat any security mechanisms you establish with authentication and authorization schemes.

The passwords for user accounts on production machines should be difficult to guess and should be guarded carefully.

Set a policy to expire passwords periodically.

Never code passwords in client applications.

Do not deploy an application that can be accessed with the default username admin and no password.

The -passwordfile option of the asadmin command specifies the name of a file that contains password entries in a specific format. These password entries are stored in clear text in the password file, and rely on file system mechanisms for protection. Therefore, any password file created for use with the -passwordfile option should be protected with file system permissions. Additionally, any password file being used for a transient purpose, such as setting up SSH among nodes, should be deleted after it has served its purpose.

To provide additional security, create a password alias.

A password alias stores a password in encrypted form in the domain keystore, providing a clear-text alias name to use instead of the password.

To provide additional security, use the create-password-alias subcommand to create an alias for the password. The password for which the alias is created is stored in an encrypted form.

Then, specify the alias in the entry for the password in the password file as follows:

In password files and the domain configuration file, use the form $\{alias=alias-name} to refer to the encrypted password.

GlassFish Server should run only as an unprivileged user, never as root.

Taking this step helps ensure that code from other users cannot be executed by GlassFish Server.

The secure administration feature allows an administrator to secure all administrative communication between the domain administration server (DAS), any remote instances, and administration clients such as the asadmin utility, the administration console, and REST clients.

In addition, secure administration helps to prevent DAS-to-DAS and instance-to-instance traffic, and carefully restricts administration-client-to-instance traffic.

The secure administration feature provides a secure environment, in which you can be confident that rogue users or processes cannot intercept or corrupt administration traffic or impersonate legitimate GlassFish Server components.

See Managing Administrative Security.

If you create a domain with the --savelogin option, create-domain saves the administration user name and password in the .asadminpass file in the user’s home directory.

Make sure that this file remains protected. Information stored in this file will be used by asadmin commands to manage this domain.

The -passwordfile option of the asadmin command specifies the name of a file that contains password entries in a specific format. These password entries are stored in clear text in the password file, and rely on file system mechanisms for protection. Therefore, any password file created for use with the -passwordfile option should be protected with file system permissions. Additionally, any password file being used for a transient purpose, such as setting up SSH among nodes, should be deleted after it has served its purpose.

To provide additional security, create a password alias.

Java Authorization Contract for Containers (JACC) is the part of the Java EE specification that defines an interface for pluggable authorization providers. This enables you to set up third-party plug-in modules to perform authorization.

By default, the GlassFish Server provides a simple, file-based authorization engine that complies with the JACC specification. You can also specify additional third-party JACC providers.

If you have purchased or written your own security providers, make sure that you have deployed and configured them properly.

To prevent sensitive data from being compromised, secure data transfers by using HTTPS.

By default, GlassFish Server uses self-signed certificates. The self-signed certificates that GlassFish Server uses might not be trusted by clients by default because a certificate authority does not vouch for the authenticity of the certificate.

You can instead use your own certificates, as described in Using Your Own Certificates.

To prevent some Denial of Service (DoS) attacks, restrict the size of a message as well as the maximum time it takes a message to arrive.

The default setting for maximum post size is 2097152 bytes and 900 seconds for the request timeout.

Auditing is the process of recording key security events in your GlassFish Server environment. You use audit modules to develop an audit trail of all authentication and authorization decisions. To enable audit logging, two steps are required:

Review the auditing records periodically to detect security breaches and attempted breaches. Noting repeated failed logon attempts or a surprising pattern of security events can prevent serious problems.

Consider setting module log levels for table.javax.enterprise.system.ssl.security and javax.enterprise.system.core.security. You can set a level from Severe to Finest (the default is Info), but be aware that the finer logging levels may produce a large log file.

By default, GlassFish Server logging messages are recorded in the server log, and you can set the file rotation limit, as described in rotate-log(1)

Always keep source code off of the production machine. Getting access to your source code allows an intruder to find security holes.

Consider precompiling JSPs and installing only the compiled JSPs on the production machine. To do this, set the deploy subcommand -precompilejsp option to true for the component.

When set to true, the deploy and redeploy subcommands -precompilejsp option compiles JSPs during deploy time. If set to false (the default), JSPs are compiled during runtime.

There are instances where an application can lead to a security vulnerability.

Of particular concern is code that uses Java native interface (JNI) because Java positions native code outside of the scope of Java security. If Java native code behaves errantly, it is only constrained by the operating system. That is, the Java native code can do anything GlassFish Server itself can do. This potential vulnerability is further complicated by the fact that buffer overflow errors are common in native code and can be used to run arbitrary code.

The ability to return user-supplied data can present a security vulnerability called cross-site scripting, which can be exploited to steal a user’s security authorization. For a detailed description of cross-site scripting, refer to "Understanding Malicious Content Mitigation for Web Developers" (a CERT security advisory) at http://www.cert.org/tech_tips/malicious_code_mitigation.html.

To remove the security vulnerability, before you return data that a user has supplied, scan the data for HTML special characters. If you find any such characters, replace them with their HTML entity or character reference. Replacing the characters prevents the browser from executing the user-supplied data as HTML.