A2 Broken Authentication and Session Management

Owned by Former user (Deleted)
Last updated: Feb 01, 2018 by Former user (Deleted)

A2 Broken Authentication and Session Management

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

className="org.apache.catalina.realm.JDBCRealm"

driverName="org.gjt.mm.mysql.Driver"

connectionURL="jdbc:mysql://localhost/authority?user=dbuser&password=dbpass"

userTable="users" userNameCol="user_name" userCredCol="user_pass"

userRoleTable="user_roles" roleNameCol="role_name"/>


  • 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.

<user-data-constraint>
     <transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>

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.

  1. Create a Certificate Authority
  2. Tell Tomcat to trust the CA
  3. Create a client certificate
  4. Sign on with the client certificate

A 2.2.3 Spring Security Framework:   

<intercept-url pattern="/**" access=isAuthenticated()" />      

This configuration will require authentication for access to any of the application pages.

A 2.2.4 Secure Password Storage:

  1. Don’t store plaintext passwords
  2. 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).
  3. Use a salt to mitigate rainbow table attacks
  4. Use a technique to slow down hashing speed
StrongPasswordEncryptor bpe= new StrongPasswordEncryptor(); 
bpe.encryptPassword("example");

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:

<http session-fixation-protection="newSession">

A 2.2.7 Session tracking mode, JSESSIONID should only be stored in a cookie:

A 2.2.7.1 Configuration on the web.xml:

<http session-fixation-protection="newSession">

A 2.2.7.2 Programmatically:

servletContext.setSessionTrackingModes(EnumSet.of(SessionTrackingMode.COOKIE));

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 2.2.8.1: Secure: ensures that the Cookie is only transmitted via SSL, configuration can be done via web.xml:

<session-config>
<cookie-config>
<secure>true</secure>
</cookie-config>
</session-config>

Or programmatically:

Cookie cookie = new Cookie("mycookie", "test");
Cookie.setSecure(true);

A 2.2.8.2: HttpOnly: ensures that the Cookie cannot be accessed via client side scripts (i.e. JavaScript). Configuration can be done via web.xml:

<session-config>
<cookie-config>
<http-only>true</http-only>
</cookie-config>
</session-config>

Or programmatically:

Cookie cookie = new Cookie("mycookie", "test");
Cookie.setHttpOnly(true);

A 2.2.8.3: Implement Content Security Policy

It's a browser side mechanism which allows you to create source whitelists for client side resources of your web application, e.g. JavaScript, CSS, images, etc. CSP via special HTTP header instructs the browser to only execute or render resources from those sources.

Content-Security-Policy: default-src: 'self'; script-src: 'self' static.domain.tld

Learn More: