Here is my "hit list" of coding security practices that can be easily integrated into any agile software development process:
- 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
- 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.
- Look out for Session Fixation problems in Java http://www.owasp.org/index.php/Session_Fixation_in_Java
- 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();
- 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.
- 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
- Make sure the servlet container is hardened. Here is a decent guide to Tomcat hardening http://www.owasp.org/index.php/Securing_tomcat
- Remove all default, management or demo code that comes with any servlet container - it’s almost always insecure.