Java

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.

Recently I was asked to configure a web application using client certificate authentication. I did this is using Weblogic Application Server version 10.3, however the concepts for this apply to most application servers. The following sections describe the configuration changes that must be applied to the environment for this to work.

Web application

The web application needs to be modified to restrict access to resources and require the use of a client certification. In order to do this modify the deployment descriptor of the application by adding a security constraint:

…

<security-constraint>

<display-name>Sec_Constraint_1</display-name>

As I've mentioned in previous blogs (Maven Release Woes with Flat Project Structures and Maven Release with Flat Structures Revisited), the support for custom SCM structures is spotty in the release plugin.  It is highly desirable to leverage the release plugin as it provides a lot of functionality we do not want to have to duplicate.  By using profiles and activations, we can still leverage the release plugin with only marginal manual intervention.

Eric Miles and I were working on different clients that were both utilizing the Weblogic application and the Spring framework.  Each of needed a way to expose some of the configuration items as JMX beans so that production support folks could change the values of these items at runtime without requiring server re-boots.  Because both of us were using Spring, exposing the beans was fairly straight forward, we just followed the Spring documentation for exporting JMX beans.

Welcome to the second post in my series on secure development issues. This week's topic is injection flaws, including SQL and command injection. The most common types of web application injection flaws include:

1. Database systems: SQL injection (e.g. 1=1)
2. Script languages such as Perl, Python, JavaScript
3. Shells for external commands (e.g. ; rm -rf /)
4. Calls to the operating system via system calls
5. Path traversal in file names (e.g. ../../etc/passwd)

Let's look at an example of a typical SQL injection attack: Let's say a developer writes the following Java code to build an SQL query to authenticate users.

var query = "SELECT * FROM users WHERE user = '" + username + "' AND password = '" + pwdHash + "'";

If an attacker enters the following into the input form, he can bypass authentication completely:

If you're like most developers, you probably have barely enough time to implement the never-ending list of requirements, much less worry about the security of your code. However, the vast majority of IT security incidents can be traced back to the development process: minor programming mistakes or design flaws can turn into big headaches when a skilled attacker discovers them. This blog is focused on discussing secure development practices. It will showcase common pitfalls and will provide practical solutions that can be easily integrated into your daily work.

This is the first in a series of regular posts about secure development. I will start by doing posts on some of the most common programming errors and their IT security implications, eventually moving into other aspects of secure development.