guide security quick S3 Basic Session Protection

Table of Contents

• S3 Basic Session Protection
  • S3-1
  • S3-2
  • S3-3
  • S3-4
  • S3-5
  • S3-6
  • S3-7
  • S3-8
  • S3-9
  • S3-10

S3 Basic Session Protection

The session of the application users lies in the centre of the applications security and needs to be as tightly protected as the users credentials within the application.

NOTE

This chapter is about the session protection. Some modern approaches for web applications we see today use no session, are completely stateless and rely tokens like JWT. For those application the contents of this chapter are in big part irrelevant.

S3-1

Containers default session management control implementation is used by the application.

Purpose: Don’t design and implement session management yourself. We’ve seen it many times. People end up repeating same security issues over and over again. And proper session management is less trivial than it looks.

Solution: Secure by design. The devonfw platform and Spring Security relies on the JEEs default session management implementation (for all web applications and API that are not stateless/session-less).

S3-2

The session is invalidated when the user logs out.

Purpose: After the user logs out of the application, we want his session to be irrecoverably destroyed.

Solution: Secure default, if the Spring Security logout functionality is triggered correctly.

S3-3

The session times out after a specified period of inactivity.

Purpose: Infinite lasting session raises the attack surface of the application.

Solution: Secure default of the Tomcat container. The default definition of how long the session is active is configured under TOMCAT_HOME/conf/web.xml (can be overridden with the web.xml file under WebApplication/webapp/WEB-INF/web.xml) and looks like:

<!-- ==================== Default Session Configuration ================= -->
<!-- You can set the default session timeout (in minutes) for all newly   -->
<!-- created sessions by modifying the value below.                       -->
<session-config>
    <session-timeout>30</session-timeout>
</session-config>

The value can also be set over Spring Boots properties file with the property server.session.timeout.

The session timeout must always be set to a reasonable amount of time and never turned off. The 'remember me' functionality is considered less secure and shouldn’t be implemented without a good reason. In case the 'remember me' functionality is needed, the Spring Security remember me pattern should be used.

S3-4

All pages that require authentication to access them have logout links.

Purpose: We want the user to be able to close his session when he’s done with the work, so the attacker, who might gain physical access to the system, can not use his session any more.

Solution: Consider this requirement in the application design phase.

S3-5

The session id is never disclosed in URLs, error messages, or logs. This includes verifying that the application does not support URL rewriting of session cookies.

Purpose: Session ids are highly sensitive, as they allow to access the system in a similar fashion the credentials do. They must not be disclosed in URLs (sometimes the system administrators need to log them out), error messages (they land in logs) or logs themself.

Solution: This is a secure default of the devonfw platform, yet still this can be broken by the developers actions. The developer must ideally never access the sessions id (HttpSession.getId()) for any reason. In cases where the application stores all requests content in a log file, the logs must exclude the session cookie.

S3-6

Successful authentication and re-authentication generates a new session and session id.

Purpose: This is needed to prevent the threat of session fixation.

Solution: Secure default of Spring Security.

S3-7

Session ids stored in cookies have their path set to an appropriately restrictive value for the application, and authentication session tokens additionally set the “HttpOnly” and “secure” attributes.

Purpose: Session ids are set over Set-Cookie headers in HTTP responses like Set-Cookie: JSESSIONID=AVASMKLAJWJV34mlkjsadflKJMSLMKJ234MLKJFSALK; path=/app1; HttpOnly; secure.

The path attribute is important, if more than one application is running on the server. We don’t want our session cookies to be sent to applications different then ours. The flag HttpOnly prohibits JavaScript from accessing the cookies value (reduces the impact of XSS vulnerabilities). The flag secure allows the cookie to be sent only over TLS protected channels.

Solution: The fastest way for Spring Boot applications to change cookie parameters is through the application properties file:

server.session.cookie.domain= = Domain for the session cookie.
server.session.cookie.http-only= = "HttpOnly" flag for the session cookie. (true (default) / false)
server.session.cookie.max-age= = Maximum age of the session cookie in seconds.
server.session.cookie.name= = Session cookie name.
server.session.cookie.path= = Path of the session cookie.
server.session.cookie.secure= = "Secure" flag for the session cookie. (true / false)

S3-8

The application limits the number of active concurrent sessions.

Purpose: We want to prevent single user from being able to run a DOS attack on the session manager and exhaust its resources.

Solution: Spring security can limit the maximum amount of concurrent user sessions. Create a configuration class that inherits from WebSecurityConfigurerAdapter and overrides the configure(HttpSecurity) method. Following code allows only one user session to be opened and redirects the user to URL if he authenticates more than once: http.sessionManagement().maximumSessions(1).expiredUrl("URL").

S3-9

An active session list is displayed in the account profile or similar of each user. The user should be able to terminate any active session.

Purpose: You go to the library, log into your account on one of the machines there, but forgets to log out. You want to be able to close the session remotely when you return back home.

Solution:

TODO: A nice solution could result from the combination of these two articles. I don’t really like how the session ids are exposed in the second article. This kind of data should not be visible on the UI like this. But if we store a bit more metadata in the session (like in the first article), we might be able to identify the session with more human-like factors. This looks rather complicated though.

S3-10

User is prompted with the option to terminate all other active sessions after a successful change password process.

Purpose: If you suspect your account to be compromised, you want to have the ability to regain the ownership.

Solution: Same as above.