Monday, April 20, 2009

Kanban: The Good Parts

Kanban Estimates

Struggling with those developer estimates? If you are, you may want to give Kanban's estimation practice a try. The Kanban methodology almost entirely eliminates the estimation process. Instead of using formal planning and estimation all features have approximately the same size. Hours that were previously burnt estimating are actually spent delivering software. When compared to the Scrum estimation model, this style of estimation is very lean.

  • Hours previously spent estimating are spent delivering software.
  • The focus is on delivering software more rapidly vs focusing on when the software will be delivered.
  • Does not invest heavily in a metric that is not scientific or always accurate.
  • High level estimates are still necessary for resource planning.

Kanban Stand ups

Unlike Scrum stand ups where each individual answers the three magical questions of: what did I do yesterday, what am I doing today, and what issues do I have. Kanban focuses exclusively on issues. For example, the global question now becomes: Does anyone have any issues?

  • Quicker stand ups.
  • The stand up scales better for larger teams.
  • Issues are the main focus.
  • May lose visibility of what each member is working on.


Monday, April 6, 2009

Secure Computing: Preventing Cross Site Scripting (XSS)

XSS prevention cheat sheet

The best strategies for preventing Cross Site Scripting can be found in OWASP's XSS prevention cheat sheet. Several important notes include:
  • You MUST use the escape syntax for the part of the HTML document you're putting untrusted data into. There is no single escape function that can be applied for all output contexts (HTML, CSS, JavaScript). ESAPI has an API that provides encoding rules for a particular output context. Refer to the OWASP's prevention rules for more details.
  • It is impossible to secure a JavaScript context with escaping. This is an important note because there is no defense to this scenario except to eliminate the output of dynamic content within your JavaScript context entirely.


JSTL used appropriately will protect you from an XSS attack within your HTML context. For example, this a valid JSTL solution:
<%-- XSS safe --%>
<c:out value="${untrusted_data}" escapeXml="true" />
By default, the excapeXml attribute is "true" within the out tag so you don't have to explicitly declare it.

The JSTL expression language alone will NOT protect you from an XSS attack. For example this is not safe and MUST be avoided for all untrusted data:
<%-- Not XSS safe --%>

XSS input validation

Validating input characters for malicious data should not be your only method of prevention. It is recommended to always escape untrusted data on the output side because you account for all data regardless of where the data originated from. Maybe the data was maliciously altered in the database or perhaps your third-party vendor sent harmful data outside HTTP. Input validation does not account for those scenarios and should not be used as your only defense. Output escaping with ESAPI or JSTL covers all bases regardless of where the data originated from. If you prefer to validate user input for XSS you may use regular expressions. A whitelist strategy of allowing positive characters is preferred. For example, the regular expression code below is a whitelist pattern that only allows certain characters as valid input:
public final class ValidationUtils {

/* Whitelist validation example. Only allow alphanumerics and special characters: -@&., */
public final static Pattern VALID_TEXT_FIELD_PATTERN = Pattern.compile("[A-Za-z0-9-@&\\.,\\s]*");

public static final boolean isValid(Pattern pattern, final String value) {
return pattern.matcher(value).matches();



If you are using JSON on the client-side make sure you also validate your JSON content for malicious data. Douglas Crockford, in his recent book JavaScript: The Good Parts recommends using JSON.parse() for all untrusted content. JSON.parse() will throw an exception if the text contains anything dangerous.