== Project Plan ==

OK, step backwards. Not being familiar with spring or spring rich client I've had to spend time getting up to speed before making any real progress.

* Familiarise myself with spring and spring rich client frameworks.
* Port spider functionality from webscarab as a familiarisation exercise and because it's feature will be useful for automated testing.
* Design regression testing UIs for review
* Research and testing of BSF (Bean Scripting Framework) as a way to write custom tests

2007-01-09T09:30:15Z

Dledmonds: /* UNIX */

== Introduction ==

Most weaknesses in [http://tomcat.apache.org/ Apache Tomcat] come from incorrect or inappropiate configuration. It is nearly always possible to make Tomcat more secure than the default out of the box installation. What follows documents best practices and recommendations on securing a production Tomcat server, whether it be hosted on a Windows or Unix based operating system. ''Please note that the section ordering is not a representation of the section importance.''

== Software Versions ==

The first step is to make sure you are running the latest stable releases of software;
* Java Runtime Environment (JRE) or SDK
* Tomcat
* Third party libraries
This does not mean you have to upgrade all your production servers to a new (and potentially buggy) release which has just been made available to the public. What you must do is download the latest stable bugfix release that has continual support. For the JRE and Tomcat you should be looking at the last digits in the version number (5.5.'''X''') as it represents the bugfix information. The bugs fixed in these releases are publicly available so if you don't upgrade you could be providing attackers with a very easy route to compromise your server.

== Installation of Apache Tomcat 5.5 ==

=== UNIX ===

* Create a tomcat user/group
* Download and unpack the core distribution (referenced as '''CATALINA_HOME''' from now on)
* Change '''CATALINA_HOME''' ownership to tomcat user and tomcat group
* Change files in '''CATALINA_HOME'''/conf to be readonly (400)
* Make sure tomcat user has read/write access to /tmp and write (300 - yes, only write/execute) access to '''CATALINA_HOME'''/logs

=== Windows ===

* Download the core windows service installer
* Start the installation, click ''Next'' and ''Agree'' to the licence
* Untick ''native'', ''documentation'', ''examples'' and ''webapps'' then click ''Next''
* Choose an installation directory (referenced as '''CATALINA_HOME''' from now on), preferably on a different drive to the OS.
* Choose an administrator username (NOT admin) and a secure password that complies with your organisations password policy.
* Complete tomcat installation, but do not start service.

=== Common ===

* Remove everything from '''CATALINA_HOME'''/webapps (ROOT, balancer, jsp-examples, servlet-examples, tomcat-docs, webdav)

* Remove everything from '''CATALINA_HOME'''/server/webapps (host-manager, manager). Note that it can be useful to keep the manager webapp installed if you need the ability to redeploy without restarting Tomcat. If you choose to keep it please read the section on Securing the Manager WebApp.

* Remove '''CATALINA_HOME'''/conf/Catalina/localhost/host-manager.xml and '''CATALINA_HOME'''/conf/Catalina/localhost/manager.xml (again, if you are keeping the manager application, do not remove this).

* Make sure the default servlet is configured '''not''' to serve index pages when a welcome file is not present. In '''CATALINA_HOME'''/conf/web.xml
<servlet>
<servlet-name>default</servlet-name>
<servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>listings</param-name>
<param-value>'''false'''</param-value> 
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>

* Remove version string from HTTP error messages by repacking '''CATALINA_HOME'''/server/lib/catalina.jar with an updated ServerInfo.properties file.
:unpack catalina.jar
cd CATALINA_HOME/server/lib
jar xf catalina.jar org/apache/catalina/util/ServerInfo.properties
:update ServerInfo.properties by changing server.info line to server.info=Apache Tomcat
:repackage catalina.jar
jar uf catalina.jar org/apache/catalina/util/ServerInfo.properties
:remove CATALINA_HOME/server/lib/org (created when extracting the ServerInfo.properties file)

* Replace default error page (default is stacktrace) by adding the following into '''CATALINA_HOME'''/conf/web.xml. The default error page shows a full stacktrace which is a disclosure of sensitive information. ''The following solution is not ideal as it produces a blank page because Tomcat cannot find the file specified, but without a better solution this, at least, achieves the desired result. A well configured web application will override this default in CATALINA_HOME/webapps/APP_NAME/WEB-INF/web.xml so it won't cause problems.''
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.jsp</location>
</error-page>
* Consider replacing '''CATALINA_HOME'''/conf/server.xml with '''CATALINA_HOME'''/conf/server-minimal.xml - ''work out what we lose''

* Replace the server version string from HTTP headers in server responses, by adding the server keyword in your Connectors in '''CATALINA_HOME'''/conf/server.xml
<Connector port="8080" ...
server="Apache" /> 

* Start Tomcat, deploy your applications into '''CATALINA_HOME'''/webapps and hope it works!

== Protecting the Shutdown Port ==
Tomcat uses a port (defaults to 8005) as a shutdown port. What this means is that to stop all webapps and stop Tomcat cleanly the shutdown scripts make a connection to this port and send the ''shutdown'' command. This is not as huge a security problem as it may sound considering the connection to the port must be made from the machine running tomcat and the ''shutdown'' command can be changed to something other than the string ''SHUTDOWN''. However, it's wise to take the following precautions;
* if you are running a publicly accessible server make sure you prevent external access to the shutdown port by using a suitable firewall.
* change the shutdown command in '''CATALINA_HOME'''/conf/server.xml and make sure that file is only readable by the tomcat user.
<Server port="8005" shutdown="ReallyComplexWord">
* if this is still a big problem for you then check [http://marc.theaimsgroup.com/?l=tomcat-user&m=104400608619118&w=2 this thread], from the Tomcat mailing list, for alternatives (they all involve code customisation though).

== Securing Manager WebApp ==

* By default there are no users with the manager role. To make use of the manager webapp you need to add a new user into the '''CATALINA_HOME'''/conf/tomcat-users.xml file.
<user username="darren" password="ReallyComplexPassword" roles="manager"/>

* Using a [http://tomcat.apache.org/tomcat-5.5-doc/config/valve.html valve] to filter by IP or hostname to only allow a subset of machines to connect (i.e. LAN machines). Add one of the following within the Context tag in '''CATALINA_HOME'''/conf/Catalina/localhost/manager.xml



<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="192.168.1.*" />




<Valve className="org.apache.catalina.valves.RemoteHostValve"
allow="*.localdomain.com" />

* You can rename the manager webapp to something else, e.g. ''foobar''
** Move '''CATALINA_HOME'''/conf/Catalina/localhost/'''manager.xml''' to '''CATALINA_HOME'''/conf/Catalina/localhost/'''foobar.xml'''
** Update the '''docBase''' attribute within '''CATALINA_HOME'''/conf/Catalina/localhost/'''foobar.xml''' to ${catalina.home}/server/webapps/foobar
** Move '''CATALINA_HOME'''/server/webapps/'''manager''' to '''CATALINA_HOME'''/server/webapps/'''foobar'''

== Logging ==

* TODO: Audit trails

== Encryption ==

* SSL for password or other sensitive data exchange (''bordering on application security, not specific to tomcat'')
* SSL for connections (JDBC, LDAP, etc ..)
* The Tomcat documentation clearly explains how to [http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html enable SSL.]

== Java Security ==

=== Running Tomcat with a Security Manager===
The default Tomcat configuration provides good protection for most requirements, but does not prevent a malicious application from compromising the security of other applications running in the same instance. To prevent this sort of attack, Tomcat can be run with a Security Manager enabled which strictly controls access to server resources.
Tomcat documentation has a good section on [http://tomcat.apache.org/tomcat-5.5-doc/security-manager-howto.html enabling the Security Manager.]

== Miscellaneous ==

* [http://tomcat.apache.org/faq/security.html Tomcat Security FAQ]

=== Using Port 80 ===

If you are on a Windows machine you will be able to change the port attribute of the connector within the ''Catalina'' service from 8080 to 80. This allows you to use tomcat directly to serve all requests. Depending on your requirements it may not be good enough to serve directly from Tomcat so you may like to consider;
* Use IIS / Apache running on port 80 and mod_jk to proxy requests to Tomcat

On a UNIX machine only root is allowed to run services on ports below 1024 (kernel recompilation can overcome this). It is a very bad idea to run Tomcat as root, so the options are;
* Use Apache running on port 80 and mod_jk (or mod_proxy_ajp) to proxy requests to Tomcat
* Run Tomcat as root, but in a chroot jail
* Use a tool like authbind to enable a non root user to bind to ports below 1024
* Use a port forwarder such as [http://www.netfilter.org/projects/iptables/index.html Iptables] to redirect incoming requests from 8080 to 80. This has the disadvantage that internal redirects still need to use 8080.
* Run [http://www.squid-cache.org/ Squid] as a web accelerator in front of Tomcat
* Use JSVC/procrun

=== Cleartext Passwords in CATALINA_HOME/conf/server.xml ===

When configuring a resource, such as a JDBC pool, it is necessary to include clear text username and password in CATALINA_HOME/conf/server.xml Best practices advice us never to store clear text passwords, but the following paragraphs highlight it is very difficult to avoid.

If one way encryption was used on the password it must be possible for a database connection to be established using a username and encrypted password - so the encrypted password is just as valuable as the clear text one to an attacker.

If two way encryption was used a keyfile is needed which must also live on the filesystem. To make it more secure a passphase is added to the keyfile which then has to be stored in the configuration as clear text - no improvement.

Encoding is security by obscurity and offers no form of protection (algorithms can be reverse engineered). What encoding does do is make huge amounts of overhead work - you need to customise Tomcat and the commons digester it uses to parse the config files. You'd also need a way to create encoded passwords.

In the case of a JDBC pool what you can do is;
* make sure the database user only has access to the databases and tables they need (also limit rights as necessary).
* make sure the raw database files are only accessible to the user running the database services (e.g. mysql/postgresql user)
* make sure the Tomcat configuration files are only accessible to the tomcat user

[[Category:OWASP Java Project]]
[[Category:Java]]

Talk:Securing tomcat

2006-11-17T11:45:51Z

Dledmonds:

Securing tomcat

2006-11-10T17:43:24Z

Dledmonds:

== Introduction ==

Most weaknesses in [http://tomcat.apache.org/ Apache Tomcat] come from incorrect or inappropiate configuration. It is nearly always possible to make Tomcat more secure than the default out of the box installation. What follows documents best practices and recommendations on securing a production Tomcat server, whether it be hosted on a Windows or Unix based operating system. ''Please note that the section ordering is not a representation of the section importance.''

== Software Versions ==

The first step is to make sure you are running the latest stable releases of software;
* Java Runtime Environment (JRE) or SDK
* Tomcat
* Third party libraries
This does not mean you have to upgrade all your production servers to a new (and potentially buggy) release which has just been made available to the public. What you must do is download the latest stable bugfix release that has continual support. For the JRE and Tomcat you should be looking at the last digits in the version number (5.5.'''X''') as it represents the bugfix information. The bugs fixed in these releases are publicly available so if you don't upgrade you could be providing attackers with a very easy route to compromise your server.

== Installation of Apache Tomcat 5.5 ==

=== UNIX ===

* Create a tomcat user/group
* Download and unpack the core distribution (referenced as '''CATALINA_HOME''' from now on)
* Change '''CATALINA_HOME''' ownership to tomcat user and tomcat group
* Change files in '''CATALINA_HOME'''/conf to be readonly (440)
* Make sure tomcat user has read/write access (660) to /tmp and write (220 - yes, only write) access to '''CATALINA_HOME'''/log

=== Windows ===

* Download the core windows service installer
* Start the installation, click ''Next'' and ''Agree'' to the licence
* Untick ''native'', ''documentation'', ''examples'' and ''webapps'' then click ''Next''
* Choose an installation directory (referenced as '''CATALINA_HOME''' from now on), preferably on a different drive to the OS.
* Choose an administrator username (NOT admin) and a secure password that complies with your organisations password policy.
* Complete tomcat installation, but do not start service.

=== Common ===

* Remove everything from '''CATALINA_HOME'''/webapps (ROOT, balancer, jsp-examples, servlet-examples, tomcat-docs, webdav)

* Remove everything from '''CATALINA_HOME'''/server/webapps (host-manager, manager). Note that it can be useful to keep the manager webapp installed if you need the ability to redeploy without restarting Tomcat. If you choose to keep it please read the section on Securing the Manager WebApp.

* Remove '''CATALINA_HOME'''/conf/Catalina/localhost/host-manager.xml and '''CATALINA_HOME'''/conf/Catalina/localhost/manager.xml (again, if you are keeping the manager application, do not remove this).

* Make sure the default servlet is configured '''not''' to serve index pages when a welcome file is not present. In '''CATALINA_HOME'''/conf/web.xml
<servlet>
<servlet-name>default</servlet-name>
<servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>listings</param-name>
<param-value>'''false'''</param-value> 
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>

* Remove version string from HTTP error messages by repacking '''CATALINA_HOME'''/server/lib/catalina.jar with an updated ServerInfo.properties file.
:unpack catalina.jar
cd CATALINA_HOME/server/lib
jar xf catalina.jar org/apache/catalina/util/ServerInfo.properties
:update ServerInfo.properties by changing server.info line to server.info=Apache Tomcat
:repackage catalina.jar
jar uf catalina.jar org/apache/catalina/util/ServerInfo.properties
:remove CATALINA_HOME/server/lib/org (created when extracting the ServerInfo.properties file)

* Replace default error page (default is stacktrace) by adding the following into '''CATALINA_HOME'''/conf/web.xml. The default error page shows a full stacktrace which is a disclosure of sensitive information. ''The following solution is not ideal as it produces a blank page because Tomcat cannot find the file specified, but without a better solution this, at least, achieves the desired result. A well configured web application will override this default in CATALINA_HOME/webapps/APP_NAME/WEB-INF/web.xml so it won't cause problems.''
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.jsp</location>
</error-page>
* Consider replacing '''CATALINA_HOME'''/conf/server.xml with '''CATALINA_HOME'''/conf/server-minimal.xml - ''work out what we lose''

* Replace the server version string from HTTP headers in server responses, by adding the server keyword in your Connectors in '''CATALINA_HOME'''/conf/server.xml
<Connector port="8080" ...
server="Apache" /> 

* Start Tomcat, deploy your applications into '''CATALINA_HOME'''/webapps and hope it works!

== Protecting the Shutdown Port ==
Tomcat uses a port (defaults to 8005) as a shutdown port. What this means is that to stop all webapps and stop Tomcat cleanly the shutdown scripts make a connection to this port and send the ''shutdown'' command. This is not as huge a security problem as it may sound considering the connection to the port must be made from the machine running tomcat and the ''shutdown'' command can be changed to something other than the string ''SHUTDOWN''. However, it's wise to take the following precautions;
* if you are running a publicly accessible server make sure you prevent external access to the shutdown port by using a suitable firewall.
* change the shutdown command in '''CATALINA_HOME'''/conf/server.xml and make sure that file is only readable by the tomcat user.
<Server port="8005" shutdown="ReallyComplexWord">
* if this is still a big problem for you then check [http://marc.theaimsgroup.com/?l=tomcat-user&m=104400608619118&w=2 this thread], from the Tomcat mailing list, for alternatives (they all involve code customisation though).

== Securing Manager WebApp ==

* By default there are no users with the manager role. To make use of the manager webapp you need to add a new user into the '''CATALINA_HOME'''/conf/tomcat-users.xml file.
<user username="darren" password="ReallyComplexPassword" roles="manager"/>

* Using a [http://tomcat.apache.org/tomcat-5.5-doc/config/valve.html valve] to filter by IP or hostname to only allow a subset of machines to connect (i.e. LAN machines). Add one of the following within the Context tag in '''CATALINA_HOME'''/conf/Catalina/localhost/manager.xml



<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="192.168.1.*" />




<Valve className="org.apache.catalina.valves.RemoteHostValve"
allow="*.localdomain.com" />

* You can rename the manager webapp to something else, e.g. ''foobar''
** Move '''CATALINA_HOME'''/conf/Catalina/localhost/'''manager.xml''' to '''CATALINA_HOME'''/conf/Catalina/localhost/'''foobar.xml'''
** Update the '''docBase''' attribute within '''CATALINA_HOME'''/conf/Catalina/localhost/'''foobar.xml''' to ${catalina.home}/server/webapps/foobar
** Move '''CATALINA_HOME'''/server/webapps/'''manager''' to '''CATALINA_HOME'''/server/webapps/'''foobar'''

== Logging ==

* TODO: Audit trails

== Encryption ==

* SSL for password or other sensitive data exchange (''bordering on application security, not specific to tomcat'')
* SSL for connections (JDBC, LDAP, etc ..)
* The Tomcat documentation clearly explains how to [http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html enable SSL.]

== Java Security ==

=== Running Tomcat with a Security Manager===
The default Tomcat configuration provides good protection for most requirements, but does not prevent a malicious application from compromising the security of other applications running in the same instance. To prevent this sort of attack, Tomcat can be run with a Security Manager enabled which strictly controls access to server resources.
Tomcat documentation has a good section on [http://tomcat.apache.org/tomcat-5.5-doc/security-manager-howto.html enabling the Security Manager.]

== Miscellaneous ==

* [http://tomcat.apache.org/faq/security.html Tomcat Security FAQ]

=== Using Port 80 ===

If you are on a Windows machine you will be able to change the port attribute of the connector within the ''Catalina'' service from 8080 to 80. This allows you to use tomcat directly to serve all requests. Depending on your requirements it may not be good enough to serve directly from Tomcat so you may like to consider;
* Use IIS / Apache running on port 80 and mod_jk to proxy requests to Tomcat

On a UNIX machine only root is allowed to run services on ports below 1024 (kernel recompilation can overcome this). It is a very bad idea to run Tomcat as root, so the options are;
* Use Apache running on port 80 and mod_jk (or mod_proxy_ajp) to proxy requests to Tomcat
* Run Tomcat as root, but in a chroot jail
* Use a tool like authbind to enable a non root user to bind to ports below 1024
* Use a port forwarder such as [http://www.netfilter.org/projects/iptables/index.html Iptables] to redirect incoming requests from 8080 to 80. This has the disadvantage that internal redirects still need to use 8080.
* Run [http://www.squid-cache.org/ Squid] as a web accelerator in front of Tomcat
* Use JSVC/procrun

=== Cleartext Passwords in CATALINA_HOME/conf/server.xml ===

When configuring a resource, such as a JDBC pool, it is necessary to include clear text username and password in CATALINA_HOME/conf/server.xml Best practices advice us never to store clear text passwords, but the following paragraphs highlight it is very difficult to avoid.

If one way encryption was used on the password it must be possible for a database connection to be established using a username and encrypted password - so the encrypted password is just as valuable as the clear text one to an attacker.

If two way encryption was used a keyfile is needed which must also live on the filesystem. To make it more secure a passphase is added to the keyfile which then has to be stored in the configuration as clear text - no improvement.

Encoding is security by obscurity and offers no form of protection (algorithms can be reverse engineered). What encoding does do is make huge amounts of overhead work - you need to customise Tomcat and the commons digester it uses to parse the config files. You'd also need a way to create encoded passwords.

In the case of a JDBC pool what you can do is;
* make sure the database user only has access to the databases and tables they need (also limit rights as necessary).
* make sure the raw database files are only accessible to the user running the database services (e.g. mysql/postgresql user)
* make sure the Tomcat configuration files are only accessible to the tomcat user

[[Category:OWASP Java Project]]
[[Category:Java]]

2006-10-24T13:40:37Z

Dledmonds:

Securing tomcat

2006-10-24T13:38:54Z

Dledmonds:

== Introduction ==

Most weaknesses in [http://tomcat.apache.org/ Apache Tomcat] come from incorrect or inappropiate configuration. It is nearly always possible to make Tomcat more secure than the default out of the box installation. What follows documents best practices and recommendations on securing a production Tomcat server, whether it be hosted on a Windows or Unix based operating system. ''Please note that the section ordering is not a representation of the section importance.''

== Software Versions ==

The first step is to make sure you are running the latest stable releases of software;
* Java Runtime Environment (JRE) or SDK
* Tomcat
* Third party libraries
This does not mean you have to upgrade all your production servers to a new (and potentially buggy) release which has just been made available to the public. What you must do is download the latest stable bugfix release that has continual support. For the JRE and Tomcat you should be looking at the last digits in the version number (5.5.'''X''') as it represents the bugfix information. The bugs fixed in these releases are publicly available so if you don't upgrade you could be providing attackers with a very easy route to compromise your server.

== Installation of Apache Tomcat 5.5 ==

=== UNIX ===

* Create a tomcat user/group
* Download and unpack the core distribution (referenced as '''CATALINA_HOME''' from now on)
* Change '''CATALINA_HOME''' ownership to tomcat user and tomcat group
* Change files in '''CATALINA_HOME'''/conf to be readonly
* Make sure tomcat user has read/write access to /tmp and write (yes, only write) access to '''CATALINA_HOME'''/log

=== Windows ===

* Download the core windows service installer
* Start the installation, click ''Next'' and ''Agree'' to the licence
* Untick ''native'', ''documentation'', ''examples'' and ''webapps'' then click ''Next''
* Choose an installation directory (referenced as '''CATALINA_HOME''' from now on), preferably on a different drive to the OS.
* Choose an administrator username (NOT admin) and a secure password that complies with your organisations password policy.
* Complete tomcat installation, but do not start service.
* TODO: ''filesystem security''

=== Common ===

* Remove everything from '''CATALINA_HOME'''/webapps (ROOT, balancer, jsp-examples, servlet-examples, tomcat-docs, webdav)
* Remove everything from '''CATALINA_HOME'''/server/webapps (host-manager, manager). Note that it can be useful to keep the manager webapp installed if you need the ability to redeploy without restarting Tomcat. If you choose to keep it please read the section on Securing the Manager WebApp.
* Make sure the default servlet is configured '''not''' to serve index pages when a welcome file is not present. In '''CATALINA_HOME'''/conf/web.xml
<servlet>
<servlet-name>default</servlet-name>
<servlet-class>org.apache.catalina.servlets.DefaultServlet</servlet-class>
<init-param>
<param-name>debug</param-name>
<param-value>0</param-value>
</init-param>
<init-param>
<param-name>listings</param-name>
<param-value>'''false'''</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
* Replace default HTTP error pages (i.e. 404) by adding the following into '''CATALINA_HOME'''/conf/web.xml. The default HTTP error pages show the full Tomcat version which is unnecessary information disclosure. ''The following solution is not ideal as it produces a blank page because Tomcat cannot find the file specified, but without a better solution this, at least, achieves the desired result. A well configured web application will override this default in CATALINA_HOME/webapps/APP_NAME/WEB-INF/web.xml so it won't cause problems.''
<error-page>
<error-code>404</error-code>
<location>/404.jsp</location>
</error-page>
* Replace default error page (default is stacktrace) by adding the following into '''CATALINA_HOME'''/conf/web.xml. The default error page shows a full stacktrace which is a disclosure of sensitive information. ''The following solution is not ideal as it produces a blank page because Tomcat cannot find the file specified, but without a better solution this, at least, achieves the desired result. A well configured web application will override this default in CATALINA_HOME/webapps/APP_NAME/WEB-INF/web.xml so it won't cause problems.''
<error-page>
<exception-type>java.lang.Exception</exception-type>
<location>/error.jsp</location>
</error-page>
* Consider replacing '''CATALINA_HOME'''/conf/server.xml with '''CATALINA_HOME'''/conf/server-minimal.xml - ''work out what we lose''
* ''is it easy to remove the version string from the server HTTP header (Apache-Coyote/1.1) ?''
* Start Tomcat, deploy your applications into '''CATALINA_HOME'''/webapps and hope it works!

== Securing Manager WebApp ==

* By default there are no users with the manager role. To make use of the manager webapp you need to add a new user into the '''CATALINA_HOME'''/conf/tomcat-users.xml file.
<user username="darren" password="ReallyComplexPassword" roles="manager"/>

* Using a [http://tomcat.apache.org/tomcat-5.5-doc/config/valve.html valve] to filter by IP or hostname to only allow a subset of machines to connect (i.e. LAN machines). Add one of the following within the Context tag in '''CATALINA_HOME'''/conf/Catalina/localhost/manager.xml



<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="192.168.1.*" />




<Valve className="org.apache.catalina.valves.RemoteHostValve"
allow="*.localdomain.com" />

* You can rename the manager webapp to something else, e.g. ''foobar''
** Move '''CATALINA_HOME'''/conf/Catalina/localhost/'''manager.xml''' to '''CATALINA_HOME'''/conf/Catalina/localhost/'''foobar.xml'''
** Update the '''docBase''' attribute within '''CATALINA_HOME'''/conf/Catalina/localhost/'''foobar.xml''' to ${catalina.home}/server/webapps/foobar
** Move '''CATALINA_HOME'''/server/webapps/'''manager''' to '''CATALINA_HOME'''/server/webapps/'''foobar'''

== Logging ==

* TODO: Audit trails

== Encryption ==

* SSL for password or other sensitive data exchange (''bordering on application security, not specific to tomcat'')
* SSL for connections (JDBC, LDAP, etc ..)
* The Tomcat documentation clearly explains how to [http://tomcat.apache.org/tomcat-5.5-doc/ssl-howto.html enable SSL.]

== Java Security ==

=== Running Tomcat with a Security Manager===
The default Tomcat configuration provides good protection for most requirements, but does not prevent a malicious application from compromising the security of other applications running in the same instance. To prevent this sort of attack, Tomcat can be run with a Security Manager enabled which strictly controls access to server resources.
Tomcat documentation has a good section on [http://tomcat.apache.org/tomcat-5.5-doc/security-manager-howto.html enabling the Security Manager.]

== Miscellaneous ==

* [http://tomcat.apache.org/faq/security.html Tomcat Security FAQ]

=== Using Port 80 ===

If you are on a Windows machine you will be able to change the port attribute of the connector within the ''Catalina'' service from 8080 to 80. This allows you to use tomcat directly to serve all requests. Depending on your requirements it may not be good enough to serve directly from Tomcat so you may like to consider;
* Use IIS / Apache running on port 80 and mod_jk to proxy requests to Tomcat

On a UNIX machine only root is allowed to run services on ports below 1024 (kernel recompilation can overcome this). It is a very bad idea to run Tomcat as root, so the options are;
* Use Apache running on port 80 and mod_jk (or mod_proxy_ajp) to proxy requests to Tomcat
* Run Tomcat as root, but in a chroot jail
* Use a tool like authbind to enable a non root user to bind to ports below 1024
* Use a port forwarder such as [http://www.netfilter.org/projects/iptables/index.html Iptables] to redirect incoming requests from 8080 to 80. This has the disadvantage that internal redirects still need to use 8080.
* Run [http://www.squid-cache.org/ Squid] as a web accelerator in front of Tomcat
* Use JSVC/procrun

=== Cleartext Passwords in CATALINA_HOME/conf/server.xml ===

When configuring a resource, such as a JDBC pool, it is necessary to include clear text username and password in CATALINA_HOME/conf/server.xml Best practices advice us never to store clear text passwords, but the following paragraphs highlight it is very difficult to avoid.

If one way encryption was used on the password it must be possible for a database connection to be established using a username and encrypted password - so the encrypted password is just as valuable as the clear text one to an attacker.

If two way encryption was used a keyfile is needed which must also live on the filesystem. To make it more secure a passphase is added to the keyfile which then has to be stored in the configuration as clear text - no improvement.

Encoding is security by obscurity and offers no form of protection (algorithms can be reverse engineered). What encoding does do is make huge amounts of overhead work - you need to customise Tomcat and the commons digester it uses to parse the config files. You'd also need a way to create encoded passwords.

In the case of a JDBC pool what you can do is;
* make sure the database user only has access to the databases and tables they need (also limit rights as necessary).
* make sure the raw database files are only accessible to the user running the database services (e.g. mysql/postgresql user)
* make sure the Tomcat configuration files are only accessible to the tomcat user

[[Category:OWASP Java Project]]

Talk:Securing tomcat

2006-10-20T15:36:38Z

Dledmonds: /* Securing Manager WebApp */

== Installation ==
* Choose an installation directory (referenced as '''TOMCAT_DIR''' from now on), preferably on a different drive to the OS.

:do we get many advantages separating application and webapps? - Darren Edmonds
::it could prevent path traversal under windows, but not unix. Separating apps from OS is common good practice anyway. [[User:Stephendv|Stephendv]] 02:32, 9 October 2006 (EDT)

== Network Security ==

Generic advice common to all server security (link).

:Not sure what information should go here? [[User:Stephendv|Stephendv]] 04:21, 16 October 2006 (EDT)
:I was thinking of a firewall discussion in relation to protecting the server. Perhaps this should be changed to only mention the shutdown port needs protecting in tomcat [[User:dledmonds|dledmonds]]

== User Input ==

User data, whether it be HTTP headers or parameters, should '"never"' be trusted. It is usually the responsibility of the application to validate data, but it is important that one poorly written application doesn't compromise Tomcat as a whole.

* global filters
* global error pages (see above)
* permission lockdown (see below)

:I think this section would be more appropriate for apps themselves, rather than applying to the server as a whole. [[User:Stephendv|Stephendv]] 04:24, 16 October 2006 (EDT)
:Agree the section doesn't seem relevant to Tomcat as it is, but I wanted to focus on preventing one webapp ruining it for everyone. Perhaps a full rundown on java security is out of scope, but how could we prevent a poorly written download webapp from using path traversal exploits to download files of other webapps? [[User:dledmonds|dledmonds]]

== Securing Manager WebApp ==

* By default there are no users with the manager role. To make use of the manager webapp you need to add a new user into the '''CATALINA_HOME'''/conf/tomcat-users.xml file.
<user username="darren" password="ReallyComplexPassword" roles="manager"/>

* Using a [http://tomcat.apache.org/tomcat-5.5-doc/config/valve.html valve] to filter by IP or hostname to only allow a subset of machines to connect (i.e. LAN machines). Add one of the following within the Context tag in '''CATALINA_HOME'''/conf/Catalina/localhost/manager.xml



<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="192.168.1.*" />




<Valve className="org.apache.catalina.valves.RemoteHostValve"
allow="*.localdomain.com" />

* You can rename the manager webapp to something else, e.g. ''foobar'' (''confirm nothing breaks in this move'')
** Move '''CATALINA_HOME'''/conf/Catalina/localhost/'''manager.xml''' to '''CATALINA_HOME'''/conf/Catalina/localhost/'''foobar.xml'''
** Update the '''docBase''' attribute within '''CATALINA_HOME'''/conf/Catalina/localhost/'''foobar.xml''' to ${catalina.home}/server/webapps/foobar
** Move '''CATALINA_HOME'''/server/webapps/'''manager''' to '''CATALINA_HOME'''/server/webapps/'''foobar'''

== Miscellaneous ==

* [http://tomcat.apache.org/faq/security.html Tomcat Security FAQ]

=== Using Port 80 ===

If you are on a Windows machine you will be able to change the port attribute of the connector within the ''Catalina'' service from 8080 to 80. This allows you to use tomcat directly to serve all requests. Depending on your requirements it may not be good enough to serve directly from Tomcat so you may like to consider;
* Use IIS / Apache running on port 80 and mod_jk to proxy requests to Tomcat

On a UNIX machine only root is allowed to run services on ports below 1024 (kernel recompilation can overcome this). It is a very bad idea to run Tomcat as root, so the options are;
* Use Apache running on port 80 and mod_jk to proxy requests to Tomcat (''is mod_jk the correct version?'')
* Run Tomcat as root, but in a chroot jail
* Use a tool like authbind to enable a non root user to bind to ports below 1024
* Use a port forwarder such as [http://www.netfilter.org/projects/iptables/index.html Iptables] to redirect incoming requests from 8080 to 80. This has the disadvantage that internal redirects still need to use 8080.
* Run [http://www.squid-cache.org/ Squid] as a web accelerator in front of Tomcat
* Use JSVC/procrun

=== Cleartext Passwords in CATALINA_HOME/conf/server.xml ===

When configuring a resource, such as a JDBC pool, it is necessary to include clear text username and password in CATALINA_HOME/conf/server.xml Best practices advice us never to store clear text passwords, but the following paragraphs highlight it is very difficult to avoid.

If one way encryption was used on the password it must be possible for a database connection to be established using a username and encrypted password - so the encrypted password is just as valuable as the clear text one to an attacker.

If two way encryption was used a keyfile is needed which must also live on the filesystem. To make it more secure a passphase is added to the keyfile which then has to be stored in the configuration as clear text - no improvement.

Encoding is security by obscurity and offers no form of protection (algorithms can be reverse engineered). What encoding does do is make huge amounts of overhead work - you need to customise Tomcat and the commons digester it uses to parse the config files. You'd also need a way to create encoded passwords.

In the case of a JDBC pool what you can do is;
* make sure the database user only has access to the databases and tables they need (also limit rights as necessary).
* make sure the raw database files are only accessible to the user running the database services (e.g. mysql/postgresql user)
* make sure the Tomcat configuration files are only accessible to the tomcat user

Talk:Securing tomcat

2006-10-20T14:28:44Z

Dledmonds: /* Securing Manager WebApp */

== Installation ==
* Choose an installation directory (referenced as '''TOMCAT_DIR''' from now on), preferably on a different drive to the OS.

:do we get many advantages separating application and webapps? - Darren Edmonds
::it could prevent path traversal under windows, but not unix. Separating apps from OS is common good practice anyway. [[User:Stephendv|Stephendv]] 02:32, 9 October 2006 (EDT)

== Network Security ==

Generic advice common to all server security (link).

:Not sure what information should go here? [[User:Stephendv|Stephendv]] 04:21, 16 October 2006 (EDT)
:I was thinking of a firewall discussion in relation to protecting the server. Perhaps this should be changed to only mention the shutdown port needs protecting in tomcat [[User:dledmonds|dledmonds]]

== User Input ==

User data, whether it be HTTP headers or parameters, should '"never"' be trusted. It is usually the responsibility of the application to validate data, but it is important that one poorly written application doesn't compromise Tomcat as a whole.

* global filters
* global error pages (see above)
* permission lockdown (see below)

:I think this section would be more appropriate for apps themselves, rather than applying to the server as a whole. [[User:Stephendv|Stephendv]] 04:24, 16 October 2006 (EDT)
:Agree the section doesn't seem relevant to Tomcat as it is, but I wanted to focus on preventing one webapp ruining it for everyone. Perhaps a full rundown on java security is out of scope, but how could we prevent a poorly written download webapp from using path traversal exploits to download files of other webapps? [[User:dledmonds|dledmonds]]

== Securing Manager WebApp ==

* Brief description of how to create a valid manager capable user

* Using a [http://tomcat.apache.org/tomcat-5.5-doc/config/valve.html valve] to filtering by IP or hostname to only allow a subset of machine to connect (i.e. LAN machines). Add one of the following within the Context tag in '''CATALINA_HOME'''/conf/Catalina/localhost/manager.xml



<Valve className="org.apache.catalina.valves.RemoteAddrValve"
allow="192.168.1.*" />




<Valve className="org.apache.catalina.valves.RemoteHostValve"
allow="*.localdomain.com" />

* Renaming the manager webapp

== Miscellaneous ==

* [http://tomcat.apache.org/faq/security.html Tomcat Security FAQ]

=== Using Port 80 ===

If you are on a Windows machine you will be able to change the port attribute of the connector within the ''Catalina'' service from 8080 to 80. This allows you to use tomcat directly to serve all requests. Depending on your requirements it may not be good enough to serve directly from Tomcat so you may like to consider;
* Use IIS / Apache running on port 80 and mod_jk to proxy requests to Tomcat

On a UNIX machine only root is allowed to run services on ports below 1024 (kernel recompilation can overcome this). It is a very bad idea to run Tomcat as root, so the options are;
* Use Apache running on port 80 and mod_jk to proxy requests to Tomcat (''is mod_jk the correct version?'')
* Run Tomcat as root, but in a chroot jail
* Use a tool like authbind to enable a non root user to bind to ports below 1024
* Use a port forwarder such as [http://www.netfilter.org/projects/iptables/index.html Iptables] to redirect incoming requests from 8080 to 80. This has the disadvantage that internal redirects still need to use 8080.
* Run [http://www.squid-cache.org/ Squid] as a web accelerator in front of Tomcat
* Use JSVC/procrun

=== Cleartext Passwords in CATALINA_HOME/conf/server.xml ===

When configuring a resource, such as a JDBC pool, it is necessary to include clear text username and password in CATALINA_HOME/conf/server.xml Best practices advice us never to store clear text passwords, but the following paragraphs highlight it is very difficult to avoid.

If one way encryption was used on the password it must be possible for a database connection to be established using a username and encrypted password - so the encrypted password is just as valuable as the clear text one to an attacker.

If two way encryption was used a keyfile is needed which must also live on the filesystem. To make it more secure a passphase is added to the keyfile which then has to be stored in the configuration as clear text - no improvement.

Encoding is security by obscurity and offers no form of protection (algorithms can be reverse engineered). What encoding does do is make huge amounts of overhead work - you need to customise Tomcat and the commons digester it uses to parse the config files. You'd also need a way to create encoded passwords.

In the case of a JDBC pool what you can do is;
* make sure the database user only has access to the databases and tables they need (also limit rights as necessary).
* make sure the raw database files are only accessible to the user running the database services (e.g. mysql/postgresql user)
* make sure the Tomcat configuration files are only accessible to the tomcat user

Talk:Securing tomcat

2006-10-20T12:14:21Z

2006-10-06T17:17:12Z

Dledmonds: /* Securing Popular J2EE Servers */

==Goals==

The OWASP Java Project's overall goal is to...

Produce materials that show J2EE architects, developers, and
deployers how to deal with most common application security
problems throughout the lifecycle.

In the near term, we are focused on the following tactical goals:

# Provide examples of how to prevent Cross Site Scripting attacks in popular web frameworks
# Provide examples of how to prevent SQL Injection in popular data access frameworks
# Provide examples of how to prevent LDAP injection in Java
# A practical guide to implementing a security policy for a Java web application
# Secure configuration guides for popular application servers

==Current Tasks==
* Call for volunteers - Join the [http://lists.owasp.org/mailman/listinfo/java-project mailing list], read the [[Tutorial]] and get started!
* Refine this roadmap in the [http://www.owasp.org/index.php/Talk:OWASP_Java_Project_Roadmap discussion].

==Ideas==

Please submit your ideas for the OWASP Java Project here (you can sign your ideas by adding four tilde characters like this <nowiki>~~~~</nowiki>)
* It would be useful to have a library of J2EE security resources on the web. In addition to URLs, I think these should have short summaries that explain what the resource is about. I've clicked on far too many "J2EE Security" links only to find that the article is about implementing access control in Tomcat.
* A tool that automatically generates a security policy for a given application could be useful. The tool is first run in learning mode where it maps all the accesses that the application attempts and then generates a policy based on those access attempts. Status: tool sent to Stephen.

==[[J2EE Security for Architects]]==

===Design considerations===
<table border=1 cellpadding=5>
<tr><td valign="top"><b>Objective:</b></td><td>Discuss the security implications of common J2EE architectures. This could be discussed in terms of: Authentication, Authorisation, Data Validation, Cross Site Scripting protection. Other architecture concerns such as scalability, performance and maintainability can also be mentioned, but the focus on security should not be lost.

Any other security concerns that should be addressed during the design phase should also be mentioned here.</td></tr>
<tr><td valign="top"><b>Status:</b></td><td>Call for volunteers</td></tr>
<tr><td valign="top"><b>Contributors:</b></td><td></td></tr>
<tr><td><b>Reviewers:</b></td><td></td></tr>
</table>
* Architectural considerations
** EJB Middle tier
** Web Services Middle tier
** Spring Middle tier

===Noteworthy Frameworks===
<table border=1 cellpadding=5>
<tr><td valign="top"><b>Objective:</b></td><td>Discuss important and relevant Java security frameworks that would be useful to architects. The information should be at a suitably high level, for example, by discussing the advantages and features as well as the associated costs (direct and indirect) of using the frameworks.</td></tr>
<tr><td valign="top"><b>Status:</b></td><td>Comparison of Frameworks in progress</td></tr>
<tr><td valign="top"><b>Contributors: </b></td><td>Claire McDonough, Ranjita Shankar Iyer</td></tr>
<tr><td><b>Reviewers: </b></td><td>Rohyt Belani, Stephen De Vries</td></tr>
</table>
1. Struts
2. Turbine
3. JFS (MyFaces)
4. Tapestry
5. Webwork
6. Cocoon
7. Tiles
8. SiteMesh
9. Spring

==[[J2EE Security for Developers]]==

===Java Security Basics===
<table border=1 cellpadding=5>
<tr><td valign="top"><b>Objective:</b></td><td>Provide an introduction into the basic security services provided by the Java language and environment. Remember to keep this relevant for web developers for the initial release - there may be a potential to expand this to thick clients in subsequent releases.</td></tr>
<tr><td valign="top"><b>Status:</b></td><td>Outline development</td></tr>
<tr><td valign="top"><b>Contributors:</b></td><td>Shyaam Sundhar</td></tr>
<tr><td><b>Reviewers:</b></td><td>Rohyt Belani, Stephen De Vries</td></tr>
</table>
* Class Loading
* Bytecode verifier
* The Security Manager and security.policy file

===Input Validation===
* Overview
* Dangerous calls (BufferedReader.readLine(), ServletRequest.getParameter(), etc...)

==== SQL Injection====
<table border=1 cellpadding=5>
<tr><td valign="top"><b>Objective:</b></td><td>Provide cursory background information on SQL injection and refer to the Guide for more indepth coverage (no need to duplicate info in the Guide). This section should provide practical advise and real-world code examples for developers. If you feel that a popular persistence framework is not covered, please add it!</td></tr>
<tr><td valign="top"><b>Status:</b></td><td>Work is underway</td></tr>
<tr><td valign="top"><b>Contributors:</b></td><td>[[User:Stephendv|Stephendv]], Joe Kumar</td></tr>
<tr><td><b>Reviewers:</b></td><td></td></tr>
</table>
* Overview
* Prevention
** White Listing
** Prepared Statements
** Stored Procedures
** Hibernate
** Ibatis
** Spring JDBC
** EJB 3.0
** JDO

====Cross Site Scripting (XSS)====
<table border=1 cellpadding=5>
<tr><td valign="top"><b>Objective:</b></td><td>Provide cursory background information on XSS and refer to the Guide for more indepth coverage. This section should provide practical advise and real-world code examples for developers. If you would like to see coverage of a web framework that's not listed, please add it!</td></tr>
<tr><td valign="top"><b>Status:</b></td><td>Call for volunteers</td></tr>
<tr><td valign="top"><b>Contributors:</b></td><td></td></tr>
<tr><td><b>Reviewers:</b></td><td></td></tr>
</table>
* Overview
* Prevention
** White Listing
** Manual HTML Encoding
** Preventing XSS in popular Web Frameworks
*** JSP/JSTL
*** Struts
*** Spring MVC
*** Java Server Faces
*** WebWork
*** Wicket
*** Tapestry
* CSRF attack

==== LDAP Injection ====
<table border=1 cellpadding=5>
<tr><td valign="top"><b>Objective:</b></td><td>As with the other Injection sections, only provide cursory information on the general case. Should contain practical real-world advise and code examples for preventing LDAP injection.</td></tr>
<tr><td valign="top"><b>Status:</b></td><td>Call for volunteers</td></tr>
<tr><td valign="top"><b>Contributors:</b></td><td>[[User:Stephendv|Stephendv]]</td></tr>
<tr><td><b>Reviewers:</b></td><td></td></tr>
</table>
* Overview
* Prevention

==== XPATH Injection ====
<table border=1 cellpadding=5>
<tr><td valign="top"><b>Objective:</b></td><td>As with the other Injection sections, only provide cursory information on the general case. Should contain practical real-world advise and code examples for preventing XPATH injection.</td></tr>
<tr><td valign="top"><b>Status:</b></td><td>Call for volunteers</td></tr>
<tr><td valign="top"><b>Contributors:</b></td><td></td></tr>
<tr><td><b>Reviewers:</b></td><td></td></tr>
</table>
* Overview
* Prevention

==== Miscellaneous Injection Attacks ====
<table border=1 cellpadding=5>
<tr><td valign="top"><b>Objective:</b></td><td>Should contain practical real-world advise and code examples.</td></tr>
<tr><td valign="top"><b>Status:</b></td><td>Call for volunteers</td></tr>
<tr><td valign="top"><b>Contributors:</b></td><td></td></tr>
<tr><td><b>Reviewers:</b></td><td></td></tr>
</table>
* HTTP Response splitting
* Command injection - Runtime.getRuntime().exec()

=== Authentication===
<table border=1 cellpadding=5>
<tr><td valign="top"><b>Objective:</b></td><td>Discuss authentication for Java and J2EE apps under the suggested headings below. Examples for container managed authentication of specific application servers are also welcome.</td></tr>
<tr><td valign="top"><b>Status:</b></td><td>Call for volunteers</td></tr>
<tr><td valign="top"><b>Contributors:</b></td><td>Dave Ferguson, Michel Prunet, Adrian San Juan, Philippe Curmin</td></tr>
<tr><td><b>Reviewers:</b></td><td></td></tr>
</table>
* Storing credentials - Adrian San Juan
* [[Hashing Java|Hashing]] - Michel Prunet
* SSL Best Practices - Philippe Curmin is working on it. This topic shall include the following points:
**What is SSL
**How SSL is implemented in J2EE
**HTTPS best practices in general
**HTTPS best practices in J2EE
**Examples with Tomcat
**Examples with JBoss.
* [[Using JCaptcha]]
* Container-managed authentication with Realms
** [[Declarative Access Control in Java]]
* JAAS Authentication
* Password length & complexity - Adrian San Juan

===Session Management===
<table border=1 cellpadding=5>
<tr><td valign="top"><b>Objective:</b></td><td>The generic problems and solutions for session management are covered in the Guide. This section should focus on Java specific examples. </td></tr>
<tr><td valign="top"><b>Status:</b></td><td>Call for volunteers</td></tr>
<tr><td valign="top"><b>Contributors:</b></td><td></td></tr>
<tr><td><b>Reviewers:</b></td><td></td></tr>
</table>
* Logout
* Session Timeout
* Absolute Timeout
* Session Fixation
* Terminating sessions
** Terminating sessions when the browser window is closed

===Authorization===
<table border=1 cellpadding=5>
<tr><td valign="top"><b>Objective:</b></td><td>Java and J2EE specific discussion and examples.</td></tr>
<tr><td valign="top"><b>Status:</b></td><td>Call for volunteers</td></tr>
<tr><td valign="top"><b>Contributors:</b></td><td></td></tr>
<tr><td><b>Reviewers:</b></td><td></td></tr>
</table>
* In presentation layer
* In business logic
* In data layer
* Declarative v/s Programmatic
* web.xml configuration - [[Declarative Access Control in Java]]
* [[Forced browsing]]
* JAAS
* EJB Authorization
* Acegi
* JACC
* Check horizontal privilege

=== Encryption===
<table border=1 cellpadding=5>
<tr><td valign="top"><b>Objective:</b></td><td>Java and J2EE specific discussion and examples.</td></tr>
<tr><td valign="top"><b>Status:</b></td><td>Call for volunteers</td></tr>
<tr><td valign="top"><b>Contributors:</b></td><td></td></tr>
<tr><td><b>Reviewers:</b></td><td></td></tr>
</table>
* JCE
* Storing db secrets
* Encrypting JDBC connections
* JSSE
* Random number generation

=== Error Handling & Logging===
<table border=1 cellpadding=5>
<tr><td valign="top"><b>Objective:</b></td><td>Java and J2EE specific discussion and examples.</td></tr>
<tr><td valign="top"><b>Status:</b></td><td>Call for volunteers</td></tr>
<tr><td valign="top"><b>Contributors:</b></td><td></td></tr>
<tr><td><b>Reviewers:</b></td><td></td></tr>
</table>
* Output Validation
* Custom Errors
* Logging - why log? what to log? log4j, etc.
* Exception handling techniques
** fail-open/fail-closed
** resource cleanup
** finally block
** swallowing exceptions
* Exception handling frameworks
** Servlet spec - web.xml
** JSP errorPage
* Web application forensics

=== Web Services Security ===
<table border=1 cellpadding=5>
<tr><td valign="top"><b>Objective:</b></td><td>Discuss securely implementing Web Services using Java technologies. Examples using specific frameworks are welcome. The topic list is a bit light at the moment, please add more topics if they're relevant.</td></tr>
<tr><td valign="top"><b>Status:</b></td><td>Call for volunteers</td></tr>
<tr><td valign="top"><b>Contributors:</b></td><td></td></tr>
<tr><td><b>Reviewers:</b></td><td></td></tr>
</table>
* SAML
* (X)WS-Security
* SunJWSDP
* XML Signature (JSR 105)
* XML Encryption (JSR 106)

=== Code Analysis Tools ===
<table border=1 cellpadding=5>
<tr><td valign="top"><b>Objective:</b></td><td>The introduction should cover the advantages and short comings of code analysis tools. An overview of the current state of the art and the available tools would go well here. As a start, only open source tools are listed, but if vendors of commercial tools adhere to the [[Tutorial]] guidelines, these submissions will be gladly received.</td></tr>
<tr><td valign="top"><b>Status:</b></td><td>Call for volunteers</td></tr>
<tr><td valign="top"><b>Contributors:</b></td><td></td></tr>
<tr><td><b>Reviewers:</b></td><td></td></tr>
</table>
* Introduction
* FindBugs
** Creating custom rules
* PMD
** Creating custom rules
* JLint
* Jmetrics

== [[J2EE Security For Deployers]] ==

=== Securing Popular J2EE Servers ===
<table border=1 cellpadding=5>
<tr><td valign="top"><b>Objective:</b></td><td>Practical step-by-step guides to securing various J2EE servers. Examples of secure configurations can also be provided for download. If configurations are provided, they should be properly commented so that the rationale for configuration settings is clearly explained. Users of the configurations should be provided with enough information to make their own risk decisions.</td></tr>
<tr><td valign="top"><b>Status:</b></td><td>Call for volunteers</td></tr>
<tr><td valign="top"><b>Contributors:</b></td><td>Darren Edmonds</td></tr>
<tr><td><b>Reviewers:</b></td><td></td></tr>
</table>
* [https://www.owasp.org/index.php/securing_tomcat Securing Tomcat] - Darren Edmonds
* Securing JBoss
* Securing WebLogic
* Securing WebSphere
* Others...

=== Defining a Java Security Policy ===
<table border=1 cellpadding=5>
<tr><td valign="top"><b>Objective:</b></td><td>Practical information on creating a Java security policies for J2EE servers.</td></tr>
<tr><td valign="top"><b>Status:</b></td><td>Call for volunteers</td></tr>
<tr><td valign="top"><b>Contributors:</b></td><td></td></tr>
<tr><td><b>Reviewers:</b></td><td></td></tr>
</table>
* PolicyTool
* jChains (www.jchains.org)

=== Protecting Binaries ===
<table border=1 cellpadding=5>
<tr><td valign="top"><b>Objective:</b></td><td>This should be focussed on web applications, so examples should include applets and web start apps.</td></tr>
<tr><td valign="top"><b>Status:</b></td><td>Outline development</td></tr>
<tr><td valign="top"><b>Contributors:</b></td><td>Richard Seiersen</td></tr>
<tr><td><b>Reviewers:</b></td><td>Rohyt Belani</td></tr>
</table>
* Bytecode manipulation tools and techniques
* Bytecode obfuscation (proguard)
* Convert bytecode to native machine code
* Signing jar files with jarsigner

==[[J2EE Security for Security Analysts and Testers]]==

This is a proposed section that seems to be a good place to put articles that don't fit into some of the other categories. [[User:Jeff Williams|Jeff Williams]] 17:41, 30 June 2006 (EDT)

* Using Eclipse to verify Java applications
* Using Findbugs, PMD, Metrics, NCSS, jLint to find flaws and bugs
* Using [[:Category:OWASP WebScarab Project|WebScarab]] to find vulnerabilities in J2EE applications - is there anything that would be specific to J2EE apps here? Wouldn't using webscarab apply to all web apps? [[User:Stephendv|Stephendv]] 07:14, 17 July 2006 (EDT)
* Decompiling Java bytecode

== [[Java Resources]] ==
<table border=1 cellpadding=5>
<tr><td valign="top"><b>Objective:</b></td><td>Define other Java security resources, links, papers and books that would be useful to the community.</td></tr>
</table>

[[Category:OWASP Java Project]]

Talk:Hashing Java

2006-10-02T11:47:28Z

Dledmonds:

I use a very similar scheme in my applications, but 2 points that came to mind whilst reading.
#Iterations of at least 1000 times seemed a bit excessive, but it is in the standard and I'm in no way qualified to critise.
#Instead of storing salt in it's own field I usually include it amongst the password (i.e characters 2, 4, 7, 13, 17, 19) to make it that bit harder to even find the salt value. I generally hex encode the hashes as well to make them a bit easier to work with. Assuming decompiled code is available (as an attacker has gained access to the password hashes) this extra salt hiding may not serve any useless purpose.