Preface:

One of the traits of a well-designed application is the efficient handling of crosscutting concerns.  By efficient I mean the application architecture/framework to handle bulk of the crosscutting concerns (such as security, transaction management, logging etc.) and let the individual services concentrate on the business logic. In this blog entry, I discuss one such cross cutting concern and a way to handle it at the framework level.

Most Java developers have never needed to interact with the DNS directly; the most well-known job of DNS, that of resolving hostnames to IP addresses, is performed automatically every time a network operation involving a hostname is performed. Similarly, finding a server that is willing to accept email for a particular email address is performed transparently using DNS. How would a Java developer get access to such arcane, low-level information to do something as simple as validate that a particular email address has a server somewhere in the world willing to accept email for it? It all comes down to hierarchy.

It is very common to put a WebLogic Portal cluster behind a web server or load balancer.  Most implementations I have seen to date either use an F5, Apache Web Server, or a combination of the two to serve up the portal content.  If you are also trying to access the Portal Admin Console through the web server you most likely experienced some sort of session affinity issue.  I realize most IT shops will just access the Portal Admin Console through a specific combination of managed host and port.  However, if you have any desire to access the Portal Admin Console through a web server or load balancer (especially for CMS functions or just a friendly url), here is why the session affinity issue is presenting itself.

The Portal Admin Console was developed to use a non standard Cookie Name.  By default, weblogic applications will use the JSESSIONID Cookie Name to maintain the user session.  However, the WebLogic Portal Admin Console uses a differe

Most people are familiar with authentication, the process of proving who you are (usually with a username and password). Access control sounds very similar, but there is a subtle difference: access control refers to the permissions assigned to an authenticated person or entity. In other words, access control first requires successful authentication, and then it can use the identity of the logged-in user to determine to which resources he has access.

While unstaffed the last few weeks, a manager tapped me to help put together a BlackBerry proof of concep for one of our clients.  I have had experience working on a BlackBerry project from a previous employer's project, however I did not have hands on experience programming the device myself.  I was looking forward to this as I had been wanting to do some dabbling with mobile devices, I just had not had the time.

A few years ago Bruce Tate and Justin Gehtland wrote a book entitled Better, Faster, Lighter Java.  In this book they argue that sometimes a simpler solution is the right answer.   As developers we often become attached to our "Golden Hammer" and try to use it for every purpose.  Large Java EE containers such as Weblogic, JBoss and WebSphere have a place in our toolbox, but sometimes what you need is a simple container which starts quickly and has a small footprint. 

At first glance, error handling may seem more like a functionality issue than a security concern. However, when done improperly (or worse, not at all), error handling can lead to security holes in your application. The classic example of error handling working in favor of the bad guys are failed logins, where the system gives a different error message for an incorrect username vs. an incorrect password. This allows the attacker to first figure out a working username and then focus on brute-forcing the password for that user. This is much faster than than having to try an exponentially-higher number of all username-password combinations.

In general, good error handling is important because error messages can reveal implementation details and pinpoint flaws in your application if they are not used correctly. Here are some common examples of incorrect error handling:

Thanks to Andy Pemberton for helping me with this one.  It definitely had me confused for a couple days.  This issue is specific to IE and only presents itself when you are exposing your portal over HTTP, but are accessing through an HTTPS load balancer or web server.  The result is a mixed content popup from IE everytime you access a page.  This is caused by an iframe shim being inserted by WebLogic portal for the automatic menu navigation.  The fix is easy and straightforward, but finding the solution was not as easy.

To fix this issue, navigate in your Portal Web project to the Merged Project Content "virtual" directory in Eclipse which should be directly under the Portal Web project when viewing in the Portal perspective.  Under that directory, navigate to framework -> skins -> bighorn -> msie.  Right-

Last week, we talked about Cross-Site Scripting (XSS) and briefly touched on Cross-Site Request Forgery (CSRF). These two attacks are very common and dangerous, which explains why they consistently rank among the top five web application vulnerabilities in almost all recent studies. This week, we'll go into more detail on CSRF. First, a quick reminder about the difference between these two attacks: XSS involves injecting unauthorized code into web pages, while CSRF involves making unauthorized requests that appear to come from a legitimate, logged-in user. Another way to think about the difference is that XSS abuses the user's trust in the web application, while CSRF abuses the trust of the web application in the user.

Originally, this week's post was supposed to cover both Cross-Site Scripting (XSS) and Cross-Site Request Forgery (CSRF), but I quickly realized that each of these topics alone are more than enough to fill a blog entry. These two are some of the most common and dangerous web application attacks, and at first glance, it may be hard to tell the difference. Here is an easy way to distinguish them: XSS involves injecting content into an existing page, while CSRF involves taking unauthorized actions on behalf of a logged-on user. XSS can be used (and often is) to launch CSRF attacks, but they are two separate attack modes.