Web Session Management White Paper

PDF Link:
http://www.isecpartners.com/files/web-session-management.pdf


Developing an application with secure session management requires developers to understand a few crucial subtleties of cookies — their attributes, their values, and how to keep them confidential — and to understand how real-world attackers are abusing weak session management in real applications today.

Enabling SSL in Apache Tomcat 6 The Easy Way

NOTE: This article does not use the APR tomcat module but rather the default Tomcat 6 deployment.

To enable SSL for Apache Tomcat 6, perform the following:

1. Create an SSL certificate using the java supplied keytool:

$JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA

NOTE: If you get the error:
keytool error: java.lang.Exception: Key pair not generated, alias <tomcat> already exists
Then most probably you have a key file already in your user directory. If you are root, this will be /root/.keystore

2. You will be requested for data that will show on your user browser's certificate, fill them all in.
Notice that the bold font is my input. No problem if you stick to the password "changeit" as it is the default password used by tomcat.

Enter keystore password: changeit
Re-enter new password: changeit
What is your first and last name: Jeremy Atkins
What is your organizational unit: OU
What is the name of your organization: NOYO
What is the name of your city or your locality: MyCity
What is the name of your state or province: Saudi Arabia
What is the two-letter country code for this unit:  uk
Is the entered data correct: yes

Enter key password for <tomcat>
        (RETURN if same as keystore password): PRESS RETURN KEY

It is important to have the keystore password and the key password the same. This is done by pressing the RETURN KEY in the last step. This is necessary since Tomcat doesn't support having different passwords in the keystore and key.

3. When you're done with the previous step, a keystore file gets created in the user directory named keystore. Since I'm the root user, I will find it in /root/.keystore.
Check that the file /root/.keystore got created.

4. Next, open the tomcat server.xml for editing:
vi ${tomcat_installation_dir}/conf/server.xml

And uncomment the following section by removing the <!-- and the --> surrounding them from top and bottom:

   <Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
               maxThreads="150" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS"
               />

5. Change the port number from 8443 to 443 which is the default SSL port known to all browsers.
Switch to 8443 while in development if needed.

   <Connector port="443" protocol="HTTP/1.1" SSLEnabled="true"
               maxThreads="150" scheme="https" secure="true"
               clientAuth="false" sslProtocol="TLS"
               />

6. Now add the following line in between to tell tomcat where to locate the keystore and specify the password you specified:

<Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true"
   maxThreads="150" scheme="https" secure="true"
   clientAuth="false" sslProtocol="TLS"
   keystoreFile="${user.home}/.keystore" keystorePass="changeit"
               />

Tomcat will automatically replace ${user.home} with the path of the home directory for the user tomcat is running under. Which in my case is "/root"

7. Restart apache tomcat using:

<tomcat_installation_dir>/bin/catalina.sh stop

<tomcat_installation_dir>/bin/catalina.sh start

Reference: http://tomcat.apache.org/tomcat-6.0-doc/ssl-howto.html

Disabling WebDAV DELETE, PUT, OPTIONS in Apache Tomcat 6

It really took me more than two hours searching over the internet just to understand how to do this simple configuration of disabled the WebDAV methods in apache tomcat 6 for all applications.

Here is how to do it:

In your apache tomcat 6 installation, simply open the file <installation_directory>/conf/web.xml for editing. Note that this web.xml file acts as a global file for all web applications and is processed before the web.xml's web application file.

At the end of the global web.xml file and just before the closing tag place the following text:

<security-constraint>
<web-resource-collection>
<web-resource-name>restricted methods</web-resource-name>
<url-pattern>/*</url-pattern>
<http-method>PUT</http-method>
<http-method>DELETE</http-method>
<http-method>OPTIONS</http-method>
<http-method>TRACE</http-method>
</web-resource-collection>
<auth-constraint />
</security-constraint>

The above security-constraint simply denies the above WebDAV methods to be processed by tomcat and returns a forbidden message.

The <auth-constraint /> simply means: "For any user, deny access to PUT, DELETE, OPTIONS, and TRACE methods".

After that, restart apache tomcat 6 using:

<installation_directory>/bin/catalina.sh stop

<installation_directory>/bin/catalina.sh start

To be able to verify that these methods are now forbidden, I used some javascript jquery code:

1. Open firefox with the firebug plugin installed

2. Open a webapplication that has jquery javascript file included within it.

3. Open firebug and select the "Console" tab from firebug

4. Write the following javascript code:

$.ajax({

  type: 'DELETE',

  url: "http://212.138.70.94",

  data: {},

  error: function() {alert('ERROR');},

  success: function() {alert('SUCCESS');},

});

5. Click the Run button.

6. You should see an alert dialog with the message ERROR and a response in firebug with the following message:

"NetworkError: 403 Forbidden - http://212.138.70.94/"

7. Repeat the above for the OPTIONS, TRACE and PUT methods.

I'm sure there's a simpler way to verify it other than javascript. But I don't know how.

Ten Ideas for Making Sys Admins Life Easier

http://queue.acm.org/detail.cfm?id=1921361

A message from administrators to application vendors:
1. DO have a "silent install" option.
2. DON'T make the administrative interface a GUI.
3. DO create an API so that the system can be remotely administered.
4. DO have a configuration file that is an ASCII file, not a binary blob.
5. DO include a clearly defined method to restore all user data, a single user's data, and individual items
6. DO instrument the system so that we can monitor more than just, "Is it up or down?"
7. DO tell us about security issues.
8. DO use the built-in system logging mechanism 
9. DON'T scribble all over the disk.
10. DO publish documentation electronically on your Web site.

Three Common Application Problems Developers Should Watch Out For

Read this: http://www.theserverside.com/news/thread.tss?thread_id=61566

Then this:http://java.dzone.com/articles/three-common-application

In summary:

- ORMs can really be dangerous on your application if you don't understand whats happening internally.

- Very few developers (a fringe of a fringe) really understand threading and can write multithreaded applications.

- Memory leaks take place in java by not closing and freeing resources and could become a real performance problem if not tracked correctly.