IO Chokepoints: J2EE Filters

This is the first post in a series covering tactics for implementing input and output chokepoints in J2EE. My goal is to describe different techniques in separate posts and then summarize the tradeoffs (advantages, disadvantages, and corner cases) involved in putting them in place in a final post. In this first post, I’ll show you how to setup a J2EE servlet filter to perform HTML escaping on multiple servlet-related input sources. A lot of DEV teams out there do this in an attempt to prevent cross-site scripting vulnerabilities.

Continue Reading »

CWE/SANS Top 25 released today

Update: Read about Gary McGraw’s take on Top N lists.

MITRE and SANS released the CWE/SANS Top 25 Most Dangerous Programming Errors list today. This list is an attempt at being more code-centric than other similar lists, such as the OWASP Top 10.

Although these lists cover what is often considered “low-hanging” fruit vulnerabilities or the coding errors that lead to them, they are great conversation starters and act as a stepping-stone for organizations just getting started in improving the way they find and fix common issues. We cannot afford, however, to not think about, pay attention to, or invest resources in finding all the other kinds of vulnerabilities that don’t show up on these lists.

Consistency is important

With so many APIs and frameworks out there, there are many different ways to accomplish the same task. The problem is that each way (or method) usually exhibits different behavior in the face of maliciousness. The challenge for us is to (1) find bad behavior in the APIs/frameworks we use, (2) apply fixes consistently, and (3) remember all of the ways things can go wrong. (1) is difficult but doable, (2) is more challenging, and (3) is arguably impossible for a person to do alone. The fact that APIs change frequently, even if changed for the better, often exacerbates the problem because it’s costly to go back and consistently make changes across existing applications.

Continue Reading »

Mixing GET and POST request data

Are designs that mix GET and POST requests inherently flawed?

It’s common for J2EE developers to create designs that pass both GET and POST requests through a centralized processing pipe, as in the controller method below:

import javax.servlet.http.HttpServlet;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;

public class MyServlet extends HttpServlet {
	public void doGet(HttpServletRequest request, HttpServletResponse response) {
		controller(request, response);
	}

	public void doPost(HttpServletRequest request, HttpServletResponse response) {
		controller(request, response);
	}

	private void controller(HttpServletRequest request, HttpServletResponse response) {
		// process the request
	}
}

Continue Reading »