Misc: j2ee

Showing posts with label j2ee. Show all posts

Wednesday, September 16, 2009

Character encoding in Web Development

If you have static HTML page, use the following tag in <head> section.

<meta http-equiv="Content-Type" content="text/html; charset=utf-8">

If you have a dynamic page (JSP or Servlet), use the following code

response.setCharacterEncoding("UTF-8");

If this method is called, web server will set the Content-Type HTTP header accordingly.

Content-Type: text/html; charset=UTF-8

Assume you have a page which accepts Russian characters.
Then according the standards you need to specify accept-charset="UTF-8" in form tag

<form accept-charset="UTF-8" >

However Internet explorer does not supports accept-charset. Nevertheless it is better to specify this attribute, howeve that is not sufficient.
However most of the browsers use the same encoding used for rendering the page (specified by Content-Type HTTP header), for encoding the forms submitted from the page. Hence specify the encoding for the page which contains the form (as mentioned above). This will force the browser to use the same encoding for form submission.
Browsers are supposed to send the Content-Type HTTP header along with HTTP reqeust for the form submission. however most of the browsers including IE and Firefox don't do so. Hence server side there is no way to acertain the encoding used by client.
Best work around is to use Content-Type (as mentined above) for the web pages containing forms and hence force the browser to use specific encoding scheme. Then specify the encoding at server while processing the reqeust by specifying

if(request.getCharacterEncoding() == null) request.setCharacterEncoding("UTF-8");

However there is another catch. If you want to submit a form with some other encoding scheme (for whateve reason - typically this can happen when you want to submit form to another website). Then it will be difficult from IE.
On the whole the best practice is to use always

response.setCharacterEncoding("UTF-8"); -- in JSP/Servlet
if(request.getCharacterEncoding() == null) request.setCharacterEncoding("UTF-8"); -- in JSP/Servlet
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"> -- in static pages
<form accept-charset="UTF-8" > -- all forms

Allways use "UTF-8" as the encoding which is much better scheme than all other available schemes.

Friday, September 04, 2009

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.

Thursday, September 18, 2008

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

Thursday, September 11, 2008

Session Tracking with SSL in WebLogic

When we are using SSL, there are two session ids and they are put in two separate cookies. _wl_authcookie_ is a secure cookie.
1) JSESSIONID
2) _wl_authcookie_
All SSL requests should contain both cookies otherwise the request will not be considered as authenticated. Non SSL (HTTP) requests needs to contain only the JSESSIONID cookie.
The sad thing is that WebLogic's implementation of URLConnection's 'getHeaderField("Set-Cookie")' returns only one cookie (whichever comes first). If you want to get both cookies you need to use 'getHeaderFields()' and look for the entry with key "Set-Cookie". To set cookie we need to use URLConnection.setRequestProperty("cookies") and we need to pass both cookies with semi colon (;) as separator.
If cookies are disabled then URL rewrite shall be used for session tracking. However you don't need to pass both cookies for SSL; only the JSESSIONID cookie will do. With SSL, URL rewrite will work only if either of the following is configured
1) EnableCookie=false in weblogic.xml
2) AuthCookieEnabled=false in config.xml

Monday, August 11, 2008

Database modularity in Enterprise Application Architecture

One of the toughest challenges I have faced in Enterprise Application Architecture is on achieving modularity in Database design.
Typically you need to retrieve data based on filter conditions depending on tables across the modules. You can write SQL queries joining tables from multiple modules.
You have three options now; (a) allow this; you end up compromise modularity and finding out dependencies become difficult. (b) prohibit this; data retrieval will become less efficient. (c) Yet another approach could be duplicating frequently used static data in both modules.
Probably combination (b) and (c) could be good approach! Allow some data duplication across the modules; Compromise some performance for the sake of modularity.
Here it is very critical to decide the boundaries of the modules very wisely. If you have too fine grained modules performance impact and data duplication will too much. If decide too course grained modules the maintainability will be reduced (impact analysis of change will be difficult)
In most of the applications you will have n number of functional modules and one master module (module which contain entities like users, departments, locations etc). You need to access data from master module in all functional modules. The interaction between master data and functional module will be too large to consider as separate modules. All functional modules will have such dependency with master data. (a) One approach could be to consider master data as part of all modules (disadvantage of this will be that any change in master data design will have impact across the application); (b) another approach is to consider master data as an independent module (disadvantage of this shall be the performance loss and data duplication). I would prefer approach (a)

Wednesday, August 06, 2008

Enterprise Application Architecture - Is the OR framework worth?

Most of the Literature (http://www.martinfowler.com/books.html#eaa) describes following as the main architecture patterns for Domain Logic
Transaction Script
Domain Model
Table Module
Domain Model is considered to be the pure Object Oriented Design pattern
Most of the enterprise applications are data intensive and data retrieval (select query in SQL) will be very ineffective unless we use appropriate SQL query joining multiple tables with appropriate filter conditions. This is the compelling reason or using RDBMS for persisting enterprise data (along with transactional capabilities and data recovery).
If we use pure Object Oriented model (as described in most of the literature) we need to map one Entity per table (table in RDBMS). This will limit the usage of appropriate SQL queries for data retrieval.
One strategy adopted in many cases are bypassing Entities for data retrieval and using Entities only for Create, Update and Delete. Data retrieval will be directly from Service Layer (http://www.martinfowler.com/eaaCatalog/serviceLayer.html) through Data Source Layer (SQLDAO).
If we decide to adopt this strategy then Is it really worth using the Entity Layer for create, modify and delete? What are the advantages of using Entity layer?
In my option the main advantage of using Entity layer is elimination of SQL query writing for update by using some OR mapping frameworks. Writing SQL for update is complex. You may have a table with 50 columns and you have a screen where all 49 (excluding primary key) columns are editable and user may be modifying only one or two. Hence you need to dynamically generate the update statement based on the columns modified. If you are using a OR framework, framework will do this for you!
If you have small utility for SQL query generation based on the modified values (eg: http://ws.apache.org/jaxme/js/sql.html#Creating+an+UPDATE+statement) this problem can be easily solved.

Tuesday, April 29, 2008

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.

Friday, April 11, 2008

Messaging based transactions and Weblogic JMS Distributed queues

Assume you have system where you have implement asynchronous processing as below
The client send the request to Session bean, which after some processing sends a message (with some correlation id) to a queue for further asynchronous processing. Another MDB process the message and sends the result back to another queue (with same correlation id). The client listen on the second queue (with selector for this particular correlation id) and updates it's state.
This will work on Normal single JMS Server. However it will break on WebLogic Distributed JMS queues. When you establish a connection with Distributed queue, you establish connection with a member JMS and you will receive messages only from that queue, similarly when you send a message, that will be sent to only the member JMS where you are connected.
That means you will not receive messages reached into the other member JMS server. For some of your requests you will never get responses because that requests reached the other Server.
Solution: User topic and ignore messages with other correlation ids.
Problem with Distributed topic
When u send message to distributed topic that will be forwarded to other member JMS servers (to deliver message to the subscribers connected to other JMS servers). If one JMS server is down messages will be persisted and will be forwarded when the server comes up. The Topic subscriber was originally connected to first JMS server and received the topic. and now he got reconnected to second JMS server. Now the client will receive the message again from the second JMS server.

Friday, March 07, 2008

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

Thursday, March 06, 2008

Transaction Management with Spring and Hibernate

Spring and Hibernate have features supporting Transaction Management. However Neither of them has a Transaction Manager and hence it on it's own cannot support XA Transactions (Global Transactions). If you like to use XA Transactions you need to use JTA service along with Spring or Hibernate. That means you have to run your application on a J2EE Application Server. There are some stand alone JTA implementations are available though (eg: JOTM, Atomikos).Without JTA Spring and Hibernate can support only local transactions. That means you have only one resource manager. Even though it looks very reasonable that may not be the case. Most of the enterprise applications shall be using one database and JMS (JMS is a resource manager). If you are having database and JMS you require XA Transaction (of course if you are using JMS for transactional purpose)
References:
http://www.hibernate.org/42.html
http://static.springframework.org/spring/docs/2.5.x/reference/transaction.html

Friday, October 26, 2007

Switching between HTTP and HTTPS protocols HTML

In HTML when we provide link to internal pages using href (same is valid for other tags like img, form etc) we use relative/absolute path in the form of 'abc.jsp' or '/abc.jsp'
However we may want to switch the protocol (from HTTPS to HTTP for example) for the new link.
This is not possible without using complete URL ('http://mydomain/abc.jsp'). Using complete URL is not a good thing to do as the domain mane may vary and presence of proxies.
Now you have to generate the complete URL on the fly either at server side (if you are using Servlet/JSP) or at client side using javascript.
It is strange that HTML doesn't have a syntax for specifying the protocol for relative paths

Thursday, October 25, 2007

Concurrency Levels - WebLogic and Oracle

Oracle supports only 'Read-Committed' and 'Serializable' Concurrency levels.
Most of the applications require 'Repeatable-Read' concurrency level (consider the banking fund transfer transaction - you read the balance, reduce the balance and then update the reduced balance to database). (I don't know why Oracle doesn't support 'Repeatable-Read'!!!)
WebLogic Server has the following isolation-level for Oracle to support 'Repeatable-Read' semantics - '

READ_COMMITTED_FOR_UPDATE'.
However there is one issue; It supports only CMP entity beans (obviously - what WebLogic does it it uses 'select for update' for all select queries to get row lock which it can do only for container generated queries). Currently for direct SQLs and BMP entity beans has to hard code 'select for update' in its code.

You may want one entity bean 'Repeatable-read' in one transaction and 'Read-Committed' in another transaction. How will you achieve this?
You have to specify the isolation-level for session bean (where actual transaction starts) than for the entity bean.
However in a business transaction there may be many entity beans involved however you may want only one entity bean to have 'Repeatable-Read', all other to use 'read-committed'. How to achieve this?
You are asking too much! There is no way to achieve that currently. You have to either specify isolation level for entity bean and lock the bean whenever it participate in a transaction OR specify isolation level at session bean level and lock all the entity beans participated.
You have a (better?) third choice! Not using entity beans (for that matter any OM mapping solutions)!!!

READ_COMMITTED_FOR_UPDATE' is supposed to be supported only for CMP entity beans however I have observed that it works for session beans as well (if you specify this for session beans, then all the entity beans involved in that transaction will be using

READ_COMMITTED_FOR_UPDATE'.
if a request propagate from on method with one isolation level to another method with another isolation level, does the isolation level changes when it enter the new method? Don't know!!! I should, but I am not sure if it does so now!

Thursday, October 18, 2007

log4j and j2ee applications

If you use log4j (for that matter java.util.logging package) in J2EE applications?
log4j starts a separate thread for writing log entries (if you use asynchronous Handlers?)
It is important to stop this thread during undeployment of the application. You can stop the thread by calling LogManager.shutdown().
Note: It is not recommended to start thread in J2EE application, then is it recommended to use log4j in j2ee application?
Also it is not recommended to use File IO in J2EE application.
Then how do you do logging for your application? Use logging framework provided by your app server. However logging framework is not yet standard and you will be having vendor specific code. Hope logging framework be part of J2EE specification in near future.

Monday, October 15, 2007

XA Transactions and order of commit

Consider the following scenario;

XA Transaction begin
insert a row into a database table
send a message to JMS Queue with pk of inserted row
XA Transaction commits

An MDB listens on the Queue and process the message. MDB selects the row and updates it.

Here comes the catch. As there is no order for committing it may happen that JMS message may get committed first and hence when MDB processing the message it may occur that database is not yet committed and hence the row is not yet available!
This occurs because there is no ordering mentioned in JTA spec.
In WebLogic (not sure if it is documented supported feature) there is an order for commit. It commits in the same order as the resources getting enlisted.
Bottom line: Make sure to enlist database resource first in similar scenarios.

Thursday, September 27, 2007

EJBs and proxies with WebLogic

If you have EJB based application with think clients, Then probably you will encounter this issue.
Most of the cases you will have a firewall/proxy in between the Client and Application server. That means clients will not have direct access to application server. All requests are routed through the proxy. If you have cluster configured, Application server will include the ip addresses of all nodes in the EJB stub. EJB client uses this ip address list for load balancing. As client doesn't have direct access this invocation will fail.
WebLogic has a solution via external address. However my experience is that it is buggy and not working properly. It is not well documented in WebLogic documentation. Do they think such usages are rare?
Note: Similar condition exist for web application also when you use sendRedirect to another resource using absolute path

Wednesday, September 26, 2007

Issues with CMP Entity beans

Most of the complex enterprise applications have entity beans and modifying data through direct SQL (either from SQLDAO or through database functions/procedures).
When we access the same table through entity bean and through direct SQL you have problems.
Case 1: data modified through entity bean and subsequently read/modify the same data through SQL - This will fail in most app servers as most of the app servers delay the entity bean SQL untill the end of transaction.
You can work around this in WebLogic via the following tag in weblogic-ejb-jar.xml

[delay-updates-until-end-of-tx]false[/delay-updates-until-end-of-tx]

Then you will loose most of the caching advantage.
Another work around (again for weblogic) is to call a non PK finder before doing a direct SQL. Non PK finder by default (make sure you have not disabled this) flushes all modifications to database before finder is called.
Case 2: data modified through direct SQL and subsequently read through entity bean. If the same entity bean is accessed before the direct SQL (see the sequence below)
Employee.getName();
directSQL - change Name
Employee.getName()
Entity bean access after the direct SQL will not reflect the modifications done by direct SQL.
This is because entity bean loads the data only once at the beginning of the transaction.
There is no easy solution for this.
I heard that if you load the entity bean again using a non PK finder it loads again - not sure; and it is unlikely. Also if you have already modified the entity bean, then you are lost.
Bottom line is never access the same table though entity bean and direct SQL.

Tuesday, July 31, 2007

Java EE 6

Interesting article. My views on that later.

Monday, July 02, 2007

Glassfish

I was playing around glassfish (JEE 5 compliant open source application server (for those who are not familiar with)). I found it pretty cool. Some of the features I found useful are:
Memory settings and other JVM configuration options are also configurable from admin console (For most of the leading app servers this has to be done in the startup script and the configuration information is spread in two files startup script and configuration xml file). For glassfish all configuration information is stored in domain.xml. Flassfish achieves this by using launcher Java program.
Log levels can be configurable at sub system level (for example you can enable "finest" logging for security sub system to debug some security issues)
Admin console looks pretty neat and clean. No applets (which has heavy dependency on Java plug in and can be big pain)
JSR 196 implimentation. Even though it is part of JEE 5, glassfish impments JSR 196 (Java Authentication Service Provider Interface for Containers). which is a much awaited feature I would say.