This blog gives a brief overview of what session management is and how it is generally handled in a web application context. I will provide also some information on how to securely configure your SAP NetWeaver Java application server session management. I have structured this blog in different sections for easier navigation. The contained sections are:
- What is session management?
- How is session management done by SAP NetWeaver Java?
- Why is secure session management important?
- How to implement secure session management for SAP NetWeaver Java?
- How to verify that the secure session management is correctly implemented?
What is session management?
Web applications are accessed over the HTTP protocol. As it is a session-less stateless protocol, web applications should implement their own way of tracking user sessions. For example, we do not want to log-in to a page by typing our user account and password for each and every request our browser sends to the web application in order to prove our identity. Therefore, web application developers should consider either implementing their own web application management (generally a bad idea as there are too many pitfalls on the way to implementing a functional and secure session management) or use the session management capabilities of the underlying frameworks and application servers.
In most cases whenever you access a web application, a session is automatically created and assigned for you. The user session is tracked by setting a “session identifier” on the client side.
For example an online shop application can track the products, which you put in the basket as your shopping basket is assigned to the session ID which your browser would supply with each request to the server/application.
Typically, application session ids are either set as an URL parameter or a cookie.
The following screenshot shows an exemplary session ID cookie with the name “JSESSIONID” and a random value as a session value.
The session management maps server side session data (e.g. the products in a shopping basket or user profile) with the particular client side interacting with the application.
How is session management done by SAP NetWeaver Java?
When talking about session management of SAP NetWeaver, we should differentiate between the Java- and ABAP-based systems as the way sessions are managed is quite different. ABAP applications would use either the UI framework-specific session management (e.g. Webdynpro) or newer applications may use the session management services of ABAP.
A Java system makes use of session ids, which are set on the client side either as URL parameters (commonly known as bad practice) or as browser cookies. The application running on the SAP NetWeaver Java stack would then make use of the services provided by the application server – the handling of the user sessions would be done by the SAP Java AS.
When initially accessing a SAP NetWeaver Java -based application, JSESSIONID would be set on the client side (e.g.in a cookie):
This session identifier would be then used to reference the user state on the server side.
Why is secure session management important?
These temporary session identifiers seem to be random and more or less insignificant as they change after each and every browser session or log-in attempt. For anonymous or publicly available applications, which do not require authentication and the functionality and data is publicly available, session management is not that of a concern from a security point of view.
A greater concern are though authenticated sessions where users have supplied their credentials and on that basis a session identifier has been issued and maintained on the client and server side. A typical example would be online banking.
The session identifier set by the application after a successful log-in represents our identity for that application during that session. If a hacker steals our session identifier (JSESSIONID), he would be able to assume our identity, privileges and access rights to the particular application which issued it.
There are multiple attack vectors, which can be used to steal such identifiers – some examples are session hijacking over Cross-Site Scripting vulnerabilities, network sniffing, etc.
The attack surface on session identifiers can be drastically reduced by implementing appropriate configurations e.g.
- Session hijacking over Cross-Site Scripting (XSS) can be mitigated by using HttpOnly cookie attribute, which instructs the clients’ browsers not to grant any access to the cookie over JavaScript
- Sniffing attacks can be mitigated by using the “Secure” attribute, which instructs the clients’ browsers to send the cookie only over secure encrypted HTTPS connections
- The application server must not issue or accept session cookies as URL parameters – these can be then found in the browser history. Copy/pasting links to emails and chats may unwillingly grant access to other users. Furthermore, the GET HTTP requests may land on malicious HTTP proxies. URLs containing session identifiers may be stored on server or proxy logs.
- Reduce the risk of session hijacking by minimizing the time-frame of automatic inactivity session time-outs (a tradeoff between usability and security should be found depending on the application use case)
- Set appropriate cookie path and try not to use domain relaxation (see SAP note 791765) – e.g.
- a session cookie issued by an application “company.com/app1” and set for the domain “company.com” with a path “/” would also be sent to any other application under that domain – for example “company.com/evil_app”
- a session cookie set for the domain path “.company.com” would be submitted not only to our application server “sever.company.com”, but also to “xyz.company.com”.
How to implement secure session management for SAP NetWeaver Java?
To implement secure session management, different service properties should be modified. There are multiple administration tools, which can be used for that purpose, but the most convenient ones are the Visual Administrator (VA) tool and NetWeaver Administrator (NWA). Note that for newer releases, SAP NetWeaver 7.1 and onwards, the VA is not shipped any more as its functionality has been implemented in the unified NWA tool. The screenshots and configuration paths are based on SAP NetWeaver 7.30 – nevertheless configurations can be deduced and performed over Visual Administrator. Depending on the patch level, there might be some deviations, but in general up-to-date systems should be easily configurable by following the steps below.
- Go to NWA -> Configuration -> Infrastructure -> Java System Properties -> Services -> HTTP Provider Service
SystemCookiesDataProtection (set to “true”) – enable “HttpOnly” cookie attribute for the JSESSIONID to mitigate the risk of session hijacking over XSS.
SystemCookiesHTTPSProtection (set to “true”) – enable the “Secure” cookie attribute for the JSESSIONID to minimize the risks of session hijacking over network sniffing – the JSESSIONID cookie would be sent only over SSL encrypted HTTPS connections.
Note that this configuration may not be applicable for all scenarios – e.g. a web shop where anonymous users should be able to add items to a basket over HTTP. HTTP is also preferred for search engine optimization reasons.
- NWA -> Configuration -> Infrastructure -> Java System Properties -> Services -> Web Container (servlets_jsp) Service
SessionIdRegenerationEnabled (set to “true”) – in order to ensure that session identifiers are regenerated at log-in as well as mitigate further security risks. This parameter would generate a second session id which would be set as a cookie called “JSESSIONMARKID”. This new session id would be regenerated whenever the user authenticates or moves to another application on the same application server.
For scenarios where SystemCookiesHTTPSProtection cannot be used (e.g. web shop where HTTP and HTTPS connections should be possible), the latter “JSESSIONMARKID” can be used. In that way the anonymous session of the user can be traced by the JSESSIONID and transferred over insecure HTTP connections and whenever the user logs in and the connection is switched to “HTTPS”, the new “JSESSIONMARKID” is set on the client side. This new cookie can then be separately set with the “Secure” attribute and ensured that it is transferred over HTTPS connections only. In order to hijack the session in such cases, the malicious user should get hold of both JSESSIONID and JSESSIONMARKID. This configuration will mitigate session hijacking attacks over network sniffing.
- NWA -> Configuration -> Infrastructure -> Java System Properties -> Services -> HTTP Provider Service
SecuritySessionIDHTTPSProtection (set to “true”) – parameter would enable the “Secure” cookie attribute for the “JSESSIONMARKID” cookie.
- Dispatcher Instance –> HTTP Provider Service (for NetWeaver Java AS before 7.10)
DisableUrlSessionTracking (set to “true”) – disable URL session tracking so that JSESSIONIDs cannot be supplied as URL parameters.
System versions from 7.10 and above accept by default only cookie-based sessions.
How to verify that the secure session management is correctly activated in SAP NetWeaver Java?
In order to verify that the configuration is correctly done, you can analyze the end result of the reconfiguration by opening and logging on to your application. Use a browser plugin for viewing the cookie properties (I used in this case the FireCookie Add-On for Firefox) and validate that the new cookie JSESSIONMARKID is generated. Furthermore, ensure that both JSESSIONID and JSESSIONMARKID session identifiers are set with the HttpOnly and Secure cookie attributes:
I hope this blog helps you improve the security configuration of your SAP NetWeaver application server Java!
- SAP Managed Tags:
8 Comments
| User | Count |
|---|---|
| 3 | |
| 3 | |
| 3 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 |
