Securing Applications
Although much of the responsibility for securing the GlassFish Server resources in a
domain fall within the scope of the server, some security responsibilities lie within
the scope of individual applications. For some security options, GlassFish Server enables you
to determine whether the server or individual applications are responsible. For each application
that you deploy in a production environment, review the items in the following
table to verify that you have secured its resources.
Table 6-3 Securing Applications
|
|
Use JSP comment
tags instead of HTML comment tags. |
Comments in JSP files that might contain
sensitive data and or other comments that are not intended for the end
user should use the JSP syntax of <%/* xxx */%> instead of the
HTML syntax <!-- xxx -->. The JSP comments, unlike the HTML comments, are
deleted when the JSP is compiled and therefore cannot be viewed in the
browser. |
Do not install uncompiled JSPs and other source code on the production machine. |
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. |
Configure your
applications to use SSL. |
Set the transport-guarantee to CONFIDENTIAL in the user-data-constraint element of
the web.xml file whenever appropriate. |
Examine applications for security. |
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. |
If your applications contain untrusted code, enable
the Java security manager. |
|
Replace HTML special
characters when servlets or JSPs return user-supplied data. |
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. |
|