Manicode

Ah, I saw a post from one of the Tomcat leads hinting that we might see HttpOnly support in Tomcat soon....

https://issues.apache.org/bugzilla/show_bug.cgi?id=45632

It's been 5 months since my original Tomcat HttpOnly post and patch at https://issues.apache.org/bugzilla/show_bug.cgi?id=44382

No word on Webkit/Safari. https://bugs.webkit.org/show_bug.cgi?id=10957 Also no word from Opera about complete HttpOnly protection. I'll start making more noise soon.

The HttpOnly crusade, quietly, does continue.

I just committed a new concrete class into the ESAPI core called org.owasp.esapi.ValidationErrorList.

ValidationErrorList will allow you to attempt groups of validation checks in a non blocking way.

I also added a variant of many org.owasp.esapi.Validator functions that will accept a ValidationErrorList as an argument instead of throwing a ValidaitonException. These ValidationErrorList variants will populate the ValidationErrorList with the ValidationException, hashed by the context.

To actually submit and collect errors for an entire validation group, your controller code would look something like:

ValidationErrorList() errorList = new ValidationErrorList();.
String name = getValidInput("Name", form.getName(), "SomeESAPIRegExName1", 255, false, errorList);
String address = getValidInput("Address", form.getAddress(), "SomeESAPIRegExName2", 255, false, errorList);
Integer weight = getValidInteger("Weight", form.getWeight(), 1, 1000000000, false, errorList);
Integer sortOrder = getValidInteger("Sort Order", form.getSortOrder(), -100000, +100000, false, errorList);
request.setAttribute(errorList , "ERROR_LIST");

Then later in your view layer, you would be able to display all of error messages via a helper function like:

public static ValidationErrorList getErrors() {
HttpServletRequest request = ESAPI.httpUtilities().getCurrentRequest();
ValidationErrorList errors = new ValidationErrorList();
if (request.getAttribute(Constants.ERROR_LIST) != null) {
errors = (ValidationErrorList)request.getAttribute("ERROR_LIST");
}
return errors;
}


And even check if a specific UI component is in error via calls like:

errorList.getError("Name");

When I bring up almost any category of web application injection attacks, most folks in the field almost instinctively begin talking about "input validation". Sure, input validation is important when it comes to detecting certain attacks, but encoding of user-driven data (either before you present that data to another user, or before you use that data to access various services) is actually a great deal more important for truly stopping almost any class of web application injection attack.

The Java variant of ESAPI has a wide variety of encoding functions depending on the need (called easily via ESAPI.encoder()).

Some of these include:

//when user-driven data is used
//as a javascript variable
String encodeForJavascript(String input);

//used when presenting user-driven
//data inside of an HTML tag
String encodeForHTMLAttribute(String input);

//used for presenting user-driven
//data inside of an HTML body
String encodeForHTML(String input);

//used then presenting data
//as a vbscript variable
String encodeForVBScript(String input);

//used when accessing LDAP services
//with user-driven data
String encodeForLDAP(String input);
String encodeForDN(String input);

//XML centric encoding operations
String encodeForXPath(String input);
String encodeForXML(String input);
String encodeForXMLAttribute(String input);

//used when placing user-driven
//data within a url
String encodeForURL(String input) throws EncodingException;

While input validation is still crucial for a defense-in-depth application security coding practice; it's truly the encoding of user data that becomes your final and most important line of defense against XSS, SQL Injection (PreparedStements and binding of variables actually encoding user-driven data specific to each database vendor via the Java JDBC driver), LDAP injection, or any other class of injection attack.