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.