Application functions related to authentication and session management are often not implemented correctly, allowing attackers to compromise passwords, keys, or session tokens, or to exploit other implementation flaws to assume other users’ identities.
A.2.1. Consider implementing ESAPI Authenticator and User API
A.2.2. Configure Java EE authentication in Tomcat
A Realm is a "database" of usernames and passwords that identify valid users of a web application (or set of web applications), plus an enumeration of the list of roles associated with each valid user. You can think of roles as similar to groups in Unix-like operating systems, because access to specific web application resources is granted to all users possessing a particular role (rather than enumerating the list of associated usernames). A particular user can have any number of roles associated with their username.
Although the Servlet Specification describes a portable mechanism for applications to declare their security requirements (in the web.xml deployment descriptor), there is no portable API defining the interface between a servlet container and the associated user and role information. In many cases, however, it is desirable to "connect" a servlet container to some existing authentication database or mechanism that already exists in the production environment. Therefore, Tomcat defines a Java interface (org.apache.catalina.Realm) that can be implemented by "plug in" components to establish this connection. Six standard plug-ins are provided, supporting connections to various sources of authentication information:
- JDBCRealm - Accesses authentication information stored in a relational database, accessed via a JDBC driver.
Example Realm elements are included (commented out) in the default $CATALINA_BASE/conf/server.xml file. Here's an example for using a MySQL database called "authority", configured with the tables described above, and accessed with username "dbuser" and password "dbpass":<Realm
- DataSourceRealm - Accesses authentication information stored in a relational database, accessed via a named JNDI JDBC DataSource.
- JNDIRealm - Accesses authentication information stored in an LDAP based directory server, accessed via a JNDI provider.
- UserDatabaseRealm - Accesses authentication information stored in an UserDatabase JNDI resource, which is typically backed by an XML document (conf/tomcat-users.xml).
- MemoryRealm - Accesses authentication information stored in an in-memory object collection, which is initialized from an XML document (conf/tomcat-users.xml).
- JAASRealm - Accesses authentication information through the Java Authentication & Authorization Service (JAAS) framework.
Configure Java EE authentication in web.xml to use Confidential transport which will make use of SSL, any request to a resource over plaintext HTTP will be redirected to HTTPS.
Implement Client Certificates:
A 2.2.2. Implement Client Certificates:
One of the most powerful forms of authentication is client side certificates. Much like server-side certificates are used to establish the identity of a server over Secure Sockets Layer(SSL), Transport Layer Security (TLS) offers the ability for the server to identify a client with certificates.
- Create a Certificate Authority
- Tell Tomcat to trust the CA
- Create a client certificate
- Sign on with the client certificate
A 2.2.3 Spring Security Framework:
This configuration will require authentication for access to any of the application pages.
A 2.2.4 Secure Password Storage:
- Don’t store plaintext passwords
- Store password in hashes using an algorithm without known weakness like SHA-256 or higher such as Java Symplified Encryption (Jasypt). This library has a StrongPasswordEncryptor class that automatically performs 100000 iterations of the SHA-256 algorithm along with a random 16 byte salt value. In addition, Jasypt provides the ability to encrypt values in property files using password-based encryption (PBE).
- Use a salt to mitigate rainbow table attacks
- Use a technique to slow down hashing speed
2.2.5 Password Policies:
- Password length larger than 15 characters
- No dictionary words or common phrases
- Alpha, numeric and special characters
- Password age between 10 and 30 days
- Password not same as last 5 passwords
- Shorter password age for admin accounts
A 2.2.6 Session Fixation Protection:
Spring Security, enable session fixation protection:
A 2.2.7 Session tracking mode, JSESSIONID should only be stored in a cookie:
A 22.214.171.124 Configuration on the web.xml:
A 126.96.36.199 Programmatically:
Also, <tracking-mode> element also accepts the value for SSL which is to use SSL ids for session id.
A 2.2.8 Cookie flags:
A 188.8.131.52: Secure: ensures that the Cookie is only transmitted via SSL, configuration can be done via web.xml:
A 184.108.40.206: Implement Content Security Policy
- OWASP Authentication Cheat Sheet
- OWASP Forgot Password Cheat Sheet
- OWASP Session Management Cheat Sheet
- ESAPI Authenticator API and Tutorial
- ESAPI User API
- OWASP Forgot Password Cheat Sheet
- OWASP Development Guide: Chapter on Authentication
- OWASP Testing Guide: Chapter on Authentication
- Content Security Policy
- SANS/CWE CWE Entry 287 on Improper Authentication
- Reviewing Code for Session Integrity Issues
- Testing Session Management