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.

Denying A Program To Connect To A Network

Imagine that one day you download a free password manager on your windows machine, and use it to store all your passwords for online banking accounts, emails, etc.

Knowing that this same executable is capable of connecting to the internet and doing different things like connecting to a server and checking for updates...

Imagine that one day the guy developing the tool inserted some malicious code to forward password information in your password manager.

Paranoid thinking? But can we blame paranoids, I mean the world is full of negative surprises that only paranoids were able to predict.

Better than blaming, is protecting yourself without losing the privilege of the software you want to use. On windows 7, here's how:

1. Go to the Control Panel.
2. Click on the Windows Firewall icon.
3. Make sure that your windows firewall is turned on by clicking on Turn Windows Firewall on or off
4. When this is done, go back to the Windows Firewall and click on "Advanced Settings".
5. Click on "Outbound Rules"
6. On the right, click on "New Rule..."
7. Make sure Program is selected in the radio buttons and click Next.
8. Enter the path of the program exe then click Next.
9. Make sure "Should be Blocked" is selected then click Next.
10. Enter a display name for this rule.
11. Click Finish.
12. Open the desktop tool you want to protect against and select "Check for updates.." in your tool if available. The tool should crash or tell you that it is unable to connect to the internet. No connection available.

Capiche. You're done.

Role Based Security

Just a quick summary from the last security post...

A resource is what you need to protect. It could be a document, html page, folder, part of the system, etc.
A subject is the user, him or her who acts on the resource.
An action is what the subject performs on a resource.
An Access List is a table describing what 'action'(s) can a subject perform on a resource.

Lets say we have an admin application, with four sections. User Management, Reporting, Backup & Restore. These can be 3 resources that we want to protect. Remember, a 'resource' is any thing you want to restrict access to.

The subjects are the 10 users. For simplicity, the actions can be Allow, Deny. (ofcourse, some actions could apply to certain resources only specially when you have finer permissions).

The access list could contain:
User A --> Allow --> User Management
User A --> Allow --> Backup & Restore
User A --> Allow --> Reporting
User C --> Allow --> Reporting
User C --> Allow --> Backup & Restore
User C --> Deny --> User Management
User D --> Allow --> Reporting
...
For 10 users, the table grows, for 100 users the Access List becomes so big... and so administratively consuming. The poor administrator will have to assign the action for every and each user on the system.

Here comes the concept of the "Role". A role is simple a middle entity between the subject's (ie. users) and the actions that would greatly simplify maintaing the access list. The access list in role-based security is called a Role Based Access Control List (abbr. RBACL).

We can now create three Roles; Reporter, Full User, and Guest. The Role Based Access List will now hold Role --> Action --> Resource instead of User --> Action --> Resource.
And another table will hold the User --> Role mapping.

See how simple the Access List becomes:
Full User --> Allow --> User Management
Full User --> Allow --> Reporting
Full User --> Allow --> Backup & Recovery
Reporter --> Allow --> Reporting
Reporter --> Deny --> User Management
Reported --> Deny --> Backup & Recovery
Guest --> Deny --> Backup & Recovery
Guest --> Deny --> Reporting
Guest --> Deny --> User Management

Thats it! Now all you have to do is to add a column in the users table
to specify a Role.

for example, User --> Roles will be:
User A --> Full User
User D --> Guest
User E --> Reporter
User F --> Guest

See how simple it becomes, every new user will only need to assign him or her one Role instead of re-defining all the actions he can perform.

Next post, I'll introduce you to extending your design, and some guidelines to stick to.

Guidelines on Designing a Better Security Model

I've collected some quick notes that will be helpful to guide you in designing a better security model. And to make it simpler, I'll explain it in a step by step example.

Assume you designed/implemented a multi-user application and would like to implement some sort of manageable security for the login accounts on the system. Read the following scenario:

1. Your system is comprised from a set of documents and pages.
2. You have multiple users on your system that can login.
3. The different users can perform different actions on the different documents and pages.

Till here we need to take a break and define some standard terminology used all over.

When it comes to security, the documents and pages are termed "resources", the different users are termed "subjects" and the different actions performed from those "subjects" on these "resources" are termed "actions".

4. I'd like now to collect a list of all the resources, actions and users on my application before I step into any design issues.

5. The resources I have are "Documents" and "Pages"

6. The actions I have are "Read", "Read/Write", "Upload", "Delete", "Edit" as an example. Note that certain "actions" can apply to certain "resources", while have no significance for other "resources", for eg. I can "Upload" a "Document", but I cant "Upload" a "Page". This is okay.

7. A list of users, this is usually stored somewhere in a database table or wherever, the important thing here is that those "subjects" are known.

After preparing a list of "resouces", "subjects" and "actions", I'll assume that no security is applied at all in the first place.

This means that any "subject" can perform any "action" on any "resource" whatsoever. In such a system, freedom fighters will enjoy it the most, while the rest will feel very insecure. Serving the rest will need some better security constraints on the different actions and resources in the system (sounds a bit political :\)

Here comes the concept of the "Access List".

The "Access List" simply defines which subjects can perform which actions on which resources?
Database wise, consider it a problem to figure out, simply it could be a table with a user id, resource id and action(s) for each row. Remember, its your design, I'm just giving guidelines here.

Ofcourse, when talking about the resource document or the resource page, we are indicating the resource type, thus its more of a resource type, and not a specific resource. Again, its your design, some might choose a very fine grained security model in which every single document has its own security, others will be comfortable with a certain action applied or denied for all documents.

An example "Access List" will simply say:

Subject "Basil" can "Delete" resource "Documents"
Subject "Basil" can "Read/Write" resource "Pages"
Subject "Whoever" can "Read Only" resource "Documents"
... (and so on)

The problem here is that if I have 100 users on my system, with 8 types of actions and three types of resources, then this "Access List" can grow indefinitely when describing the different permissions and will be hard to maintain by an administrator on the system.

Next post I'll show you how to tackle this problem.

ps. Comments, anybody, please, starting to feel lonely here.

In search for a good security model

I'm currently researching for some good way of implementing a security model for an administrative application. See, this is one of the areas where you really need a good design. And if not well thought of, then the code can easily get dirty and strangled in one month's time.

In small applications, we used to implement such in a very simple way by using database columns with true/false values or by using a access mask stored in a string.

However, such methodology proves very weak when its times to scale and fine tune your apps security demands. A security model is something that doesn't stay the same since it will be affected by any extra functionalities added to the application in future versions, therefore, as i already said, it is one of the areas that need deep thought and a good design.

If you're not acquainted to the terms: Policy, Subject, Resource, Role Based Access List, Authenticator, Authorizer... then HANDS OFF the security architecture document and delegate it to someone else. I know you have the brain power to do it, but without the correct knowledge, it wont be easy.