Security Considerations for Java Web Applications

1. Protecting against data awareness. 
   Problem: Users become "aware" of system processes and data (such as primary keys) by reading application URLs.  When this happens, users can start Copying and Pasting URLs to execute actions.
   Remedy: Avoid GET requests that include data on the URL.  Always use POST requests. Also, on every request, check is user has access to the requested page, action, data and mode (edit/view)
   
   
2. Prevent SQL Injection attacks. 
   Problem: Read here for an Overview of SQL injection attacks
   Remedy: Always use parameters when sending SQL commands from code. Never concatenate sql strings.
   
   
3. Ensure that Form submissions come from the current user (1).
   Problem: Read here for an Overview of CSRF attacks
   Remedy: Use CSRF tokens to ensure that form submissions come from the same session. At post of form data, check that CSRF token is the same that was specified when form was rendered for input. This can be done via a csrf token hidden variable.
   
   
4. Ensure that Form submissions come from the current user (2).
   Scenario:  User "A" logs in, and access a form input page.  He/She fills in the form, but does not submit it. Then user "B", on the same browser presses Ctrl+N, opens a new window and logs in.   Now both windows in browser have user "B" as the username.  If form that was filled in from user "A" is submitted, the system will log user B as the submitter.
   Remedy: On every page render, store the username in a javascript variable.  Add javascript call to the focus event of browser windows that reads the username stored in the username cookie and compares it with the the username in a javascript variable.  If the usernames do not match, it means that the username has changed from another window. Note: this method is possible since cookies update on the client (browser) when changed even if no server interaction takes place.
   
   
5. Protecting against Back/Forward buttons
   Scenario:  User "A" logs in, and access a high privileged page, then logs out. Then user "B", a limited user, logs in on same browser. If user "B" presses multiple times the back button of browser, he/she will be looking at the privileged page user "A" was looking before loging out.
   Remedy: The application's login process should set the current username in a cookie and the session. Then, on every page rendered by the application an onload javascript calls a servlet which checks that there is a current user in the session, and that the username of the session is the same as the username sent by the AJAX call. If the usernames don't match, or there is no username in the session, redirect page to login page of application.
   
   
6. Protecting against Session information spillover
   Problem: This refers to the possibility of session data from a previous session be present in the next session opened in the same browser window.
   Remedy: The application should have a log out process, and a link to execute this process clearly visible on every page.  Make sure that Logout servlet invalidates session, and starts a new one. In java, call request.getSession(true). Also any login cookies should be cleared.
   
   
7. Cross-site Scripting (XSS)
   Problem: Read here for Cross-site Scripting (XSS) attacks
   Remedy: In short: never trust user's input.  Input must be validated against strict rules.  Output should be html-escaped. More here: http://www.veracode.com/security/xss and at the OWASP related page.