OWASP Podcast #2 Securing Webgoat with ModSecurity

I just finished publishing OWASP Podcast #2 - an interview with Stephen Craig Evans.

We discussed Stephen's OWASP Summer of Code Project, Securing Webgoat with Mod Security.

You can check out the show notes for OWASP Podcast #2, download the mp3 file directly, subscribe to the RSS feed, or subscribe directly to iTunes.

I found Stephen to be very interesting in his analysis of when WAF deployment is prudent. Although WAF deployment is something I personally think of as a last resort, intelligent discussion and arguments like I heard from Stephen make it tougher for me to dismiss WAF technology outright. Great job, Stephen!

HTTPOnly XMLHTTPRequest exposure update

The HTTPOnly crusade grows stronger.

I have victories to report on several fronts regarding the adoption of HTTPOnly, to the point of stopping XMLHTTPRequest.getAllResponseHeaders leakage of HTTPOnly cookies.

The HTTPOnly world was rocked in the Summer of 2007 when the famous HTTPOnly test url at http://ha.ckers.org/httponly.cgi demonstrated that HTTPOnly cookies could be exposed via the JavaScript XMLHTTPRequest (XHR) object through the getAllResponseHeaders function which includes HTTP headers that contain set-cookie headers - even for HTTPOnly cookies.

So even though HTTPOnly cookies stopped JavaScript calls like document.cookie, they did not stop advanced XSS techniques like http://insanesecurity.wordpress.com/2007/08/01/httponly-vs-xmlhttprequest/

The latest and greatest browsers and standards address this issue.

First out the gate, is Internet Explorer. My HTTPOnly hat's off to Microsoft for delivering the first browser to implement defense from the HTTPOnly exposure vector described above. http://www.microsoft.com/technet/security/bulletin/ms08-069.mspx

However, IE did NOT implement protection from set-cookie2 header exposure!! The horror!

I still declare the HTTPOnly browser war active!

Will FireFox deliver the first browser to truly implement complete HTTPOnly in a way that would make the HTTPOnly working group pleased? Could Opera, Safari or Chrome sneak in with a win?

As I mentioned in an earlier post, some of the recent editorial version of the XHR specification at w3c includes clear verbiage that prevents reading of ALL set-cookie/2 headers via getAllResponseHeaders() and getResponseHeader() in a case insensitive way. Nice!

It's the securing of these core RFC's that help make the applications and browsers of tomorrow more secure. Thanks Anne!

PS: As a HTTPOnly bonus, check out Ryan Barnett's blog post on how to add HTTPOnly protection using ModSecurity.

How to restart Tomcat properly

David: hmm, i get no cancel confirmation

James: update all code

then refresh

then project-clean

sacrifice 2 chickens

reload tomcat

sacrifice a goat

then you should be ok

David: ok, i forgot the goat

OWASP Podcast #1

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!

XMLHttpRequest will be more secure in the future

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!

Java and UTF-8 Shortest Form

Java 6 update 11 contained an interesting change to UTF-8 handling that I think is worth noting.

Here is the original JRE bug:
4486841 UTF-8 decoder should adhere to corrigendum to Unicode 3.0.1

Here is the impact of the problem
The UTF-8 (Unicode Transformation Format-8) decoder in the Java Runtime Environment (JRE) accepts encodings that are longer than the "shortest" form. This behavior is not a vulnerability in Java SE. However, it may be leveraged to exploit systems running software that relies on the JRE UTF-8 decoder to reject non-shortest form sequences. For example, non-shortest form sequences may be decoded into illegal URIs, which may then allow files that are not otherwise accessible to be read, if the URIs are not checked following UTF-8 decoding.

The solution is to flat out reject anything other than shortest-form UTF-8 per http://unicode.org/versions/corrigendum1.html which has been around since - March 2001??

• In UTF-8, <004d> is serialized as <4d>.
• The problematic "non-shortest form" byte sequences in UTF-8 were those where BMP characters could be represented in more than one way. These sequences are illegal...

HttpOnly in Tomcat, almost?

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.

Input Validation with ESAPI - Very Important

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");

Input Validation - Not That Important

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.

Getting Started with Java Web Application Security

Some in the WAF world have conjectured recently that web application security coding practices are difficult. I am starting to believe Jeff Williams - that secure coding practices - especially when using a toolkit like ESAPI - is actually a great deal CHEAPER and EASIER than not writing code securely in the first place.

Here is my "hit list" of coding security practices that can be easily integrated into any agile software development process:

1. Make sure ALL data that is user driven is run through output encoding to render (at least) XSS attacks inert – ESAPI.org has a version of that function that is good to use http://www.owasp.org/index.php/ESAPI - or just use this function http://www.owasp.org/index.php/How_to_perform_HTML_entity_encoding_in_Java
2. Make sure ALL user data is run through strong input validation, ESAPI.org also has a strong validation set of functions that handles double-encoding protection and canonicalization - in additional to configurable regular expressions.
3. Look out for Session Fixation problems in Java http://www.owasp.org/index.php/Session_Fixation_in_Java
4. Look out for SQL injection problems in Java (All database access must be through Hibernate, or the Java PreparedStatement class with proper binding of all variables. String selectStatement = "SELECT * FROM User WHERE userId = ? ";PreparedStatement prepStmt = con.prepareStatement(selectStatement);prepStmt.setString(1, userId);ResultSet rs = prepStmt.executeQuery();
5. Audit access control carefully across every page. Use an access control grid to document access control across all functions and have a manger sign off on that artifact.
6. JSP’s should never be accessible via a public directory like www.somesite.com/program.jsp - they should always be placed in a private non-accessible directory to be accessed and streamed to the user via a servlet. JSP parameter tampering is to easy. If your development team uses emacs to edit code, make sure files like www.somesite.com/program.jsp~ are not deployed - it will give an attacker easy access to the source code
7. Make sure the servlet container is hardened. Here is a decent guide to Tomcat hardening http://www.owasp.org/index.php/Securing_tomcat
8. Remove all default, management or demo code that comes with any servlet container - it’s almost always insecure.

Coding your application securely is ALWAYS better protection than depending on a WAF.

Opera 9.5 HttpOnly Read Prevention

Opera 9.50 is now available for download at http://www.opera.com.

Although the official release documentation did not mention it, Opera 9.50 does indeed include the most basic form of HttpOnly support - HttpOnly cookie read prevention. The following results are from Opera 9.50 on Vista Ultimate. I tested using the WebGoat v5.1 HttpOnly test page at /WebGoat/attack?Screen=176&menu=51.

And here are the official results:

Results:
* SUCCESS: Your browser enforced the HTTPOnly flag properly for the 'unique2u' cookie by preventing direct client side read access to this cookie.
* FAILURE: Your browser did not enforce the write protection property of the HTTPOnly flag for the 'unique2u' cookie.
* The unique2u cookie was successfully modified to se/M3Lw5Ia4cMyKIUAJrbz23Ibo= on the client side.
* FAILURE: Your browser does not prevent an XMLHTTPRequest read for the 'unique2u' cookie.

This is obviously not perfect support; we should at least see HttpOnly write prevention. Current versions of IE 6/7 and FireFox 2/3 all include both HttpOnly cookie read and write prevention per OWASP's HttpOnly browser support section.

However, this is still another victory for HttpOnly crusaders and Web Application Security. I'll be sure to post a bug on Opera's support site requesting complete support.

And don't forget to vote for the Firefox "XMLHttpRequest allows reading HTTPOnly cookies" bug at https://bugzilla.mozilla.org/show_bug.cgi?id=380418 so we can have at least one browser with complete HttpOnly support!

HttpOnly Crusade Update

I would like to report 2 exciting victories regarding the ongoing HttpOnly crusade!

1) The underlying network library used for Safari - the Qt C++ library - particularly the QNetworkCookie class - has finished adding HttpOnly support! See http://trolltech.com/developer/task-tracker/index_html?id=206125&method=entry for more information on the specific bug. My undercover Safari developer resource tells me that Safari is soon to follow with full HttpOnly support in both the Windows and OSX versions!

2) The latest version of the Servlet 3.0 specification (JSR 315) has added HttpOnly support to both the Cookie and SessionCookieConfig classes. You can download the JavaDoc here. Thank you to Rajiv Mordani @ Sun!

HttpOnly is not a cure-all. It's simply one defense-In-depth measure to assist in preventing XSS session hijacking attacks. HttpOnly can also be circumvented via triggering an AJAX request via the XMLHttpRequest object and reading cookie data out of the headers. Fellow HTTPOnly crusader, Eric Bing from Oracle, is also leading the charge communicating with the w3c regarding future specifications to prevent the XMLHTTPRequest JavaScript object from accessing HttpOnly cookies! Exciting!

In other HttpOnly news:

WebLogic is testing a HttpOnly flag and is currently reviewing the patch "for feasibility".

There is a FireFox bug already addressing the circumvention of HttpOnly via XMLHttpRequest headers as described above. Please consider adding you vote to help encourage the team to lock down this HttpOnly circumvention vector: https://bugzilla.mozilla.org/votes.cgi?action=show_user&bug_id=380418#vote_380418

And the Crusade Continues......

ShakaCon 2008 Hawaii

You now have a business-critical reason to encourage your boss to send you to Hawaii. ShakaCon 2008 (June 9th-13th) is Hawaii's only information security, IT audit, compliance and ethical hacking conference!

For the second year running, one of the most beautiful places on Earth will serve as the backdrop for this truly unique security conference experience.

ShakaCon will include a wide variety of security speakers, including an update on the OWASP ESAPI (Enterprise Security API) project on June 11th. ShakaCon will also host a 2-day Web Application Security Training course by the Aspect Security Hawaii office on June 12th and 13th.
For more information, please see http://www.shakacon.org/ or download the registration form here.

CSRF Solutions

The problem: CSRF.

Jeremiah Grossman's explanation of the problem at RSA 08 :
http://www.slideshare.net/guestdb261a/csrfrsa2008jeremiahgrossman-349028/

OWASP CSRF Overview:
http://www.owasp.org/index.php/CSRF

Testing for CSRF:
http://www.owasp.org/index.php/CSRFTester

Java Filter for CSRF Protection:
http://www.owasp.org/index.php/CSRF_Guard

Java ESAPI Defense:
org.owasp.esapi.HTTPUtilities.addCSRFToken(String href)

Plaform's with built-in CSRF defense:
Drupal.org

ha.ckers.org pwnd?

It's strange and disheartening to see ha.ckers.org "down" this evening. I hope it's only unscheduled maintenance. I would hate to see the pwnders get pwnd!

Another interesting note: ha.ckers.org uses Wordpress? Ewwwwwwwwwwwwwwwwwww

Plaintext PCI Compliance

One of the main flaws of PCI-DSS compliance requirement #4 is that it allows for plaintext transmission of credit card information within private networks. The most recent mass-credit-card heist involves my favorite east coast grocer, Hannaford. Hannaford passed a PCI audit. Even more interesting, Hannaford passed their PCI audit on Feb. 27, 2008 - 2 months after they were breached - and 3 weeks before public disclosure! Just how did this happen?

"But in Hannaford's case, the intruders were able to intercept the data at a point where it obviously was unencrypted"

- Heather Paquette, Hannaford Manager Midwest Information Risk Management

"At the time of this potential exposure, Hannaford was certified to be in compliance with the highest security standards required by the credit card industry."

- Ronald C. Hodge, Hannaford's CEO

Anytime you transmit or store credit card information - do so using industry standard strong encryption.

This seems like a no-brainer. We should have learned this lesson in InfoSec 101!

HttpOnly, Safari, Servlets and Tomcat

I'm a huge fan of the benefits provided by the HttpOnly cookie flag, especially as it pertains to enhancing the security of session cookies in web applications. As we can see by Andrew van der Stock's recent blog post on HttpOnly Browser Support, almost every browser supports or will soon support the HttpOnly flag except for Safari.

Safari uses the WebKit.org open source project. And there is indeed a bug submitted for HttpOnly support in WebKit. But this bug was posted back in September 06' - whats taking so long? Unfortunately the problem is Apple. Apple is blocking WebKit from supporting HttpOnly. The CFNetwork library is the closed source Apple library that converts HTTPHeaders into objects - and the CFNetwork library does not support the HttpOnly cookie flag. Please do not hesitate to email the Apple Product Security Team to nudge them along in the right direction!

Also, I have heard rumors that the JEE Servlet Expert Group will soon agree to support the HttpOnly flag in the Servlet 3.0 specification! I'm absolutely thrilled about this. I cannot provide proof of this yet, but I am a longtime Sun contractor and have authoritative sources. This is a very encouraging development.

I've run across much resistance on my HttpOnly cookie crusade. The Tomcat team is hesitant to support this cookie flag since HttpOnly is not a standard - but I'm working on the Tomcat HttpOnly bug and am likely to get it rolled live into Tomcat once it becomes part of the standard for Servlets.

Vive la HttpOnly!

Actual Photo of Arshan Dabirsiaghi

HTTPOnly support for Apache Tomcat

I've made specific suggestions to the Apache Tomcat core developer team to add HTTPOnly support to Tomcat 5.5 (for starters). The adoption is slow-going since it involves changes to three of the most core files of Tomcat.
Here is how you can get HTTPOnly support NOW while you wait for official adoption.

1) First download the Tomcat source code and be able to build the core server via ANT. See http://tomcat.apache.org/tomcat-5.5-doc/building.html for instructions. Although the link above points to Tomcat 5.5, the changes I'm suggesting below will work for any Tomcat build.

Once you have downloaded the Tomcat code and have set up your build environment, you will need to make the following changes to at least org.apache.catalina.connector.Request.java and org.apache.catalina.connector.Response.java. You could (should) also make changes to org.apache.tomcat.util.http.ServerCookie.java if you require a very scalable solution where every StringBuffer.append matters; but that addition is beyond the scope of this post.

2) org.apache.catalina.connector.Request.doGetSession(boolean create) is where the session cookie (JSESSIONID) is initially created. You are going to need to change this. This first change is at approximately loc 2321 of the file org.apache.catalina.connector.Request.java (for Tomcat 5.5).

//this is what needs to be changed
//response.addCookieInternal(cookie);

//this is whats new
response.addCookieInternal(cookie, true);
}

3) In order to support the new HTTPOnly version of Response.addCookieInternal, we need to modify the functionality of org.apache.catalina.connectorResponse.addCookieInternal. The following are my suggested backward-compatible changes:

public void addCookieInternal(final Cookie cookie) {
addCookieInternal(cookie, false);
}

public void addCookieInternal(final Cookie cookie, boolean HTTPOnly) {

if (isCommitted())
return;

final StringBuffer sb = new StringBuffer();
//web application code can receive a IllegalArgumentException
//from the appendCookieValue invokation
if (SecurityUtil.isPackageProtectionEnabled()) {
AccessController.doPrivileged(new PrivilegedAction() {
public Object run(){
ServerCookie.appendCookieValue
(sb, cookie.getVersion(), cookie.getName(),
cookie.getValue(), cookie.getPath(),
cookie.getDomain(), cookie.getComment(),
cookie.getMaxAge(), cookie.getSecure());
return null;
}
});
} else {
ServerCookie.appendCookieValue
(sb, cookie.getVersion(), cookie.getName(), cookie.getValue(),
cookie.getPath(), cookie.getDomain(), cookie.getComment(),
cookie.getMaxAge(), cookie.getSecure());
}
//of course, we really need to modify ServerCookie
//but this is the general idea
if (HTTPOnly) {
sb.append("; HttpOnly");
}

//if we reached here, no exception, cookie is valid
// the header name is Set-Cookie for both "old" and v.1 ( RFC2109 )
// RFC2965 is not supported by browsers and the Servlet spec
// asks for 2109.
addHeader("Set-Cookie", sb.toString());

cookies.add(cookie);
}

Any feedback is appreciated.

PS: For more on HTTPOnly and how it can be a part of your defense-in-depth web application security strategy, see http://msdn2.microsoft.com/en-us/library/ms533046.aspx

JQuery vs Prototype JS Libraries

Here are my thoughts on JQuery vs. Prototype - I do not think either is better. It's just a tradeoff based on your needs and team.

JSQuery positives:
Easier
Better Containment
Better Chaining
More Active Community
More Active/Verbal Maintainer
Designer-centric
More concise code

JSQuery Negatives:
Memory hog
Cross-browser support is not so great
Dom centric programming (not so easy for Java folks to wrap their heads around this)
No class support or inheritance (again, odd for Java folks to wrap their head around this)

Prototype positives:
Amazing cross browser support
Low memory footprint (compared to other frameworks)
Great Object Orientation/Functional based programming (easy for Java/back end developers to jump in the game)
OO Coder-centric
More readable code
Better security awareness/responsiveness for Ajax functionality

Prototype negatives:
sizable download file
not as concise as JQuery
community not as active (at times)

Summary: Most designers prefer JSQuery. Most Java Programmers prefer Prototype. But if you would like to have your cake and eat it to, then use both, together.

It's my Vista Party and I'll cry if I want to

You would cry too if it happened to you.

Last week I was handed a new Vista Ultimate(tm) machine as my primary Java development machine. Yes, I wept. I tossed and turned for nights wondering WHY WHY did this happen to me? But as a social experiment and respect for my new boss, I'm going to give it a good ol college try. So far, Java 1.5 and Eclipse installed just fine. I stripped almost every feature from Vista that I could using this very reasonable gamers tweak guide for speeding up Vista. http://www.extremetech.com/article2/0,1697,2247431,00.asp

But I hit my first wall when trying to install MySQL 5.0. MySQL MySQLInstanceConfig 5.0.51a simply does not work on any version of Vista due to some error with UAC configuration. Admittedly, it was the MySQL developers fault, not Vista. MySQL 5.0.45 is the latest version of MySQL to actually run properly on Vista as of this posting.

Charging forward with Vista laptop in hand....

Secure Agile Software Engineering with ESAPI

The principles of agile development are revolutionary and have only come to full fruition as computer languages, software engineering tools and software platform paradigms have matured to the depth that we have seen in recent years. But as anyone who works in Application Security well tell you, Software Development is a combat sport and we must continually march to the drumbeat of Better, Faster, Stronger. That new frontier is developing Secure Applications with lightning speed. We are not there yet. But the dawn of the age of secure agile software development is upon us, and the weapon of choice shall be ESAPI. But with such power comes great responsibility and we must continually learn skills anew. This brief article will debunk some of the theories of agile development, but will prepare you for the battle ahead.

Some of the core aspects behind agile development is placing working iterations of applications in front of the customer in a very rapid model similar to the spiral software engineering model. This rapid turnaround (and rapid desires from the customer for change) can allow software analysts to forgo much of the design process of an application. Pre-development design documentation no longer becomes an efficient process when you are iterating so frequently with the customer.

1) Design documentation in a secure agile development life cycle is more efficient when done after the primary live delivery.

Efficiency in the agile process is fundamental. We must be empowered to not only iterate fast, but to do so in a way that is of high quality. The chief architects code and the newest members of our team must be of similar quality, and a junior coder fresh out of school will not do. There are certain lessons that only the heat of battle and years of coding will teach you. For a new recruit, a support role to the team is more appropriate.

2) Junior Programmers do not belong in the core of secure agile development teams

Simplicity is no longer an option. K.I.S.S. died the day the first programmer completed an application that was a combination of J2EE, Hibernate XML mapping, ANT and Tomcat xml configuration, Javascript, SQL, XHTML/DHTML and CSS. The applications being
asked of us web-centric agile programmers are a mesh of 7 or more different programming languages with rich client cross-browser concerns that make even the most hardened C++ programmers weep.

3) We shall expect complexity as the norm and shall build such functionality in reusable well encapsulated abstractions

Our teams are now distributed. Face to face conversations are so - 1990's. We can expect our teams to be scattered all over the world. This new generation of agile warriors will use the free tools of new media to the fullest and will appear to be in the cubical next to yours from 6000 miles away in almost ninja like fashion. The Secure Agile Programmer is an extrovert who gains great satisfaction in clear and constant communication with the customer.

4) We shall expect our teams to be global and have the capacity to maximize Instant Message, Email, VOIP, Audio Chat Rooms and other forms of net communication in a very verbose yet clear way.

Our agile developers are not cowboys, they are elite soldiers with the right tools in hand. Before a agile coder can move fast, the application architecture must be well formed. We cannot build application infrastructure on the fly. That is where ESAPI comes in. ESAPI is the only enterprise Java API that covers all aspects of secure application development. It can be injected in to
any Java architecture. It will minimize the need for security testing when used appropriately. It will save you money, time and present you with a simple and effective way to build Java applications securely from the ground up, the first time.

5) We will have a secure robust architecture in place before we begin the agile process.

All areas of secure coding are covered in ESAPI:

1) Authentication
2) User Management
3) Access Control Abstraction
4) Secure Object Reference
5) Input Validation
6) Output Encoding
7) Encryption
8) Secure HTTPUtilities
9) Random Number Generation
10) Logging with proper Security Considerations
11) Intrusion Detection
12) Secure Configuration

Game on. Join us: ESAPI.org