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!