Manicode

I am very pleased to announce the inception of the OWASP Podcast series.

OWASP Podcast #1 was recorded on November 21, 2008. The guest panel includes Jeff Williams, Arshan Dabirsiaghi, Jeremiah Grossman and your host, Jim Manico.

You can download OWASP Podcast #1 here.

You can read the show notes here.

You can subscribe rss/itunes/feedburner here.

Thank you, very much, to all participants and listeners. Please pass the word!

This is only the beginning. My hope is that the OWASP podcast series serves the community well.

Enjoy!

Some of the most recent iterations of the XHR specification at w3c (edited by Anne van Kesteren) includes excellent security choices which will lock down the JavaScript HTTPOnly edge-case exposure vectors.

The latest editorial draft of the XHR w3c spec http://dev.w3.org/2006/webapi/XMLHttpRequest/

• prevents creating set-cookie/2 headers via setRequestHeader() in a case insensitive way. (but XHR is free to send Cookie/2 headers for any existing cookie (HTTPOnly or otherwise).
• prevents reading set-cookie/2 headers via getAllResponseHeaders() and getResponseHeader() in a case insensitive way.

Excerpts from the spec:

getAllResponseHeaders(), method….
Return all the HTTP headers, excluding headers that case-insensitively match Set-Cookie or Set-Cookie2, as a single string, with each header line separated by a U+000D CR U+000A LF pair excluding the status line, and with each header name and header value separated by a U+003A COLON U+0020 SPACE pair.

setRequestHeader(header, value), method
For security reasons, these steps should be terminated if the header argument case-insensitively matches one of the following headers:
• Accept-Charset
• Accept-Encoding
• Authorization
• Connection
• Content-Length
• Cookie
• Cookie2
• Content-Transfer-Encoding
• Date
• Expect
• Host
• Keep-Alive
• Referer
• TE
• Trailer
• Transfer-Encoding
• Upgrade
• User-Agent
• Via

I’m excited to see this key specification move in such a secure direction!

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.