Session Fixation in WebLogic and Tomcat

Session Fixation is a security vulnerability prevelant in Authentication framework available in most of the Web Servers (WebLogic Server 10.3, Tomcat 6.0.20, ASP.NET).
Session Fixation works as follows:
1) Alice (attacker) access a unprotected resource (http://vulnerableApp/unprotected.jsp). In most of the web servers a new session is created now, even if you are not logged in. A session cookie is set and sent with the response.
2) Alice notes down the session cookie sent by the web server. She can do that using some HTTP monitoring tool like LiveHttpHeader for FireFox. copy that cookie string to a different computer. Alice change the browser page to something else (www.google.com). Keep the browser window open. Leaves the computer.
3) Bob (victim) uses the computer to access a protected resource from the same web application (http://vulnerableApp/protected.jsp). He uses the same browser windows (which is kept open). He loges in using his username/password. WebServer now uses the same session cookie for logged in session. Bob continue using the application for next 30 minutes.
4) Alice access the protected resource from the application (http://vulnerableApp/protected.jsp) using the saved cookie from another machine. He can use some Java client to do so. Now she is able to access the protected resource with Bob's credentials. Alice will be able to access all protected resources until Bob logs out. If Bob leaves the computer by closing the browser (without explicit logout), then alice will be able to use the resource forever (or untill next server re-start).
This vulnerability is there if you are using most of the Web Servers (WebLogic, Tomcat not tested any other server heard ASP.NET is also having session fixation bug. )
Solution:
If you are using Form based authentication, call session.invalidate() in the login page. This will create new session cookie. See the sample login page below:

<%
session.invalidate();
%>
<form action="j_security_check" method="POST" name="login">
<input type="input" name="j_username" />
<input type="password" name="j_password" />
<input type="submit" name="submit" value="Log in" />
</form>

If you are BASIC authentication, you are at risk unless the web server handles it correctly (most web servers don't handle it). Ideally authentication framework in the web server should have called session.invalidate() before authentication.
Don't use BASIC authentication in your application.
Sample application to demonstrate the vulnerability
1) Download the SimpleWebApp1 ( http://rejeev.googlepages.com/SimpleWebApp1.war )
2) Configure a WebLogic or Tomcat server
3) Create a user called "user1" in weblogic
4) Create a user called "user1" and role called "user1" in Tomcat
5) Deploy the application in WebLogic or tomcat
6) Access test2.jsp (http://localhost:7001/SimpleWebApp1/test2.jsp)
7) Note the cookie (use LiveHttpHeaders with firefox)
8) Access test1.jsp (http://localhost:7001/SimpleWebApp1/test1.jsp). You will be asked to log in, log in.
9) Now try access the test1.jsp using the TestSessionFixation.java provide inside the war. Usage: java rejeev.sessionfixation.TestSessionFixation . You will be able to see test1.jsp without login.
Oracle has supposed to fix this issue in WebLogic Server 10.3. However I have observed that latest version of WebLogic Server (10.3) has this issue. I think they have mistaken this issue as an issue in thier admin console (admin cosole being a web application that is also vulnerable). However fundemental vulnerability is in the authentication framework.

Session Fixation

Recently I come to know about a new security vulnerability (new to me) - Session Fixation ( http://www.owasp.org/index.php/Session_Fixation ). Somebody could already start a session (may be by accessing a non-secure/less previleged resource) and trick you to login to the application and use it. Then you are vulnerable. He could have saved the sessionid before handing over to you and use it from another machine. If you close the browser after your usage (without loggint out - which many people do), he could use it infinitely long. If you logout after use he could use only as long as you are logged in.
You could prevent this by calling session.invalidate before authentication, in the authentication method. If you are using your application server's authentication framework (that is what we are lold - not to write our own security code), then you need to verify that your application server does that.
In ASP.NET platform it is very difficult to prevent as ASP.NET reuses the same sessionid even if you create new session by calling session.invalidate. There are some known solutions available ( http://www.owasp.org/index.php/Session_Fixation_Protection )

OWASP Enterprise Security API (ESAPI)

OWASP has a Web Application Security framework called Enterprise Security API (ESAPI) ( http://www.owasp.org/index.php/ESAPI ). It is a security framework cum security utilities library.
You can do authentication, authorization, CSRF protection, XSS protection etc (besided many other things). A sample application and API doc is available at the site. However there is no other detailed documentation on the usage. I will write another blog on the usage in detail.
Following is few Key classes and API

package org.owasp.esapi
For authentication
class Authenticator
   login()
   logout()
For authorization
class AccessController
   assertAuthorizedForURL(string url)
For XSS protection
class Validator
   assertValidHTTPRequestParameterSet(string context, Request request, Set requied, Set optional)
   isValidString(string input)
class Encoder
   encodeForHTML(string input)
For CSRF protection
class HTTPUtilities
   addCSRFToken(string href)
   verifyCSRFToken()

I will write a detailed blog later.

HttpOnly Cookies and Java EE Application servers (WebLogic, WebSphere etc)

Most of the application servers (WebLogic, WebSPhere) are not supporting HttpOnly Cookies
If you are not familiar with HttpOnly Cookies please see the posting of Jef http://www.codinghorror.com/blog/archives/001167.html

Currenlty there is no way to specify the session cookie as HttpOnly in most of the application servers.
However you can work aroud this weekness by implemeting a custome cookie which is HttpOnly and the same can be set and tracked by a Servlet Filter. First time when the session is established this (httpOnly) cookie also set and subsequent request will be rejected if it not submitted with this httpOnly cookie along with session cookie.
A sample Filter is available here -  http://rejeev.googlepages.com/HttpOnlyCookieFilter.java 

Information Card

Probably the new Buzzword in Security realm is going to be Information Card (InfoCard, CardSpace etc), This time from Microsoft!
Basically information Card is using Public key/private key for authentication (kind of Client_CERT authentication). Your key combination (is called card; you can have n number of cards) are stored in Identity Selector (Control Panel > Windows CardSpace; You need to install it in Windows XP as part of .NET Framework 3.0). When you sign up a account in a website, you will send this card first time to the website. In subsequent sign in you need to send the card for authentication. You can use either self signed cards (personal card) or cards signed by CAs (managed cards). You can optionally secure your cards in the machine using a PIN.
However roaming (using the card from some other machine) with Information Card is still not a viable option (you need to export and import)

J2EE Security and JAAS

What is the authentication technology used in J2EE?
There is a widespread mis-understanding that JAAS is the underlying security mechanism used in J2EE.
J2EE spec requires Form, basic and cert authentication for Web Applications. However it doesn't specify any particular authentication technique for Application client (EJB, JMS clients).
JAAS is not a supported authentication technique for Application clients. JAAS is a J2SE feature. It's scope is limited to single JVM. JAAS is supported in J2EE as a J2SE feature.
If you have a Application client you need to use Vendor specific code for authentication. It is not going to change in Java EE 5 or Java EE 6.
I am really puzzled why it (an API for authentication) is not included in J2EE spec.
If you consider WebLogic, WebLogic authentication mechanism (UsenamePasswordLoginModule) is something similar to JAAS (but not JAAS).
J2EE security talks only about
a) declarative authorization(via security constraint tag in deployment descriptors)
b) programmatic authorization(via API - isCallerInRole, getCallerPrincipal, isUserInRole, getUserPrincipal)
c) Authentication for web applications (basic, form, SSL mutual authentication)
d) transport security (SSL - via transport-guarantee tag).
Given below are few quotes from J2EE and EJB spec
J2EE.3.4.2 Required Login Mechanisms
All J2EE products are required to support three login mechanisms: HTTP basic authentication, SSL mutual authentication, and form-based login.
J2EE.3.4.4 Application Client User Authentication
The application client container must provide authentication of application users to satisfy the authentication and authorization constraints enforced by the enterprise bean containers and web containers. The techniques used may vary with the implementation of the application client container, and are beyond the control of the application.
21.6.3 Security Mechanisms (EJB 2.1 spec)
The EJB Container Provider must provide the security mechanisms necessary to enforce the security policies set by the Deployer. The EJB specification does not specify the exact mechanisms that must be implemented and supported by the EJB server.

J2EE Application Security

Digital Certificate based SSL for network security and Authentication/Authorization based on the security-constraints tag in deployment descriptors for Access Control is quite standard for J2EE Application.However that is not the end of protecting your J2EE Application.If yours is a Web Application, there are a number of application vulnerabilities which a attacker can make use of and get into your application. Please refer to OWASP Top Ten (http://www.owasp.org/index.php/OWASP_Top_Ten_Project)for list of most important Web Application vulnerabilities.Following are 3 most important (according to me) vulnerabilities for J2EE Web Application.
1) Cross Site Scripting (XSS) - Assume you a Web page where user can enter some text data and another page where these use entered data is displayed (Some thing like 'add comment' and 'moderate comments' pages). An attacker may enter a script instead of text data in the input text area (eg: '[script]echo 'this is a sample attack'[/script]). When the somebody else (say administrator) opens the second page instead of the text being displayed the script shall be executed. This is called XSS.The solution for this kind of attach is:a) Validate all user inputs - in this case we should not allow patterns like [script]b) Encode all output content (not formatting metadata). If output is encoded even if [script] is present in the text, that will be displayed as [script] instead of executing.For practical purpose you need to validate input as well as encode output content.
2) SQL Injection - Assume you have a authentication servlet. You store the username password in database use the following SQL for authentication. "select 1 from user_table where username = '" + username + "' and password = '" + password + "'"; An attacker may enter the following text as username and passwords
Username = "abc' OR 1 = 1; --
Password = xyz
NOw the SQL becomes "select 1 from user_table where username = 'abc' OR 1 = 1; -- password = 'zyz'; which is all ways trueSolution for this kind of attack is Using PreparedStatement instead of Statement.
3) Cross Site Request Forgery (CSRF) - Assume you are using FireFox and in one tab you have opened your web application. Now get a email (from attacker) with some links to some fancy pictures. Actually the link is to your application with query string indicating to do some operation. Since you are already logged in to the application it will not ask for authentication again. It will silently execute the operation. Solution for this kind of attack is to use a unique string (other than session id) to identify each session/request (It identifier could be per session or per request; per session is sufficient for most purposes). You need to attach this identifier to each form and link in your application. Validate all request for a valid identifier.
Vulnerabilities in Swing clients
1) SQL injection is equally valid in Thick clients. Solution is same - using Prepared statements
2) Un protected JNDI objects - There is no standard way for protecting JNDI objects in J2EE. If an attacker can get hold of a DataSource or JMS Queue or topic he could access the application. or invoke SQL queries directly. Solution is to protect all JNDI resources in App server vendor specific way
3) Unprotected EJBs - Some times In swing client you first log in and then navigate other screens to do operations hence even if the subsequent EJBs are not protected you may not notice it. However a attacker can write own EJB client which can directly invoke the un protected EJB Solution is to protect all the EJBs