Карточка уязвимости
Характеристики уязвимости
Уровень опасности
Оценка CVSS
Производитель ПО
Наименование ПО
SAP Notes
(1417679-2)
SAP Support Packages
(ENGINEAPI_710_SP009_000008, ENGINEAPI_710_SP010_000006, ENGINEAPI_710_SP999999_999999, ENGINEAPI_711_SP003_000010, ENGINEAPI_711_SP004_000011, ENGINEAPI_711_SP999999_999999, ENGINEAPI_720_SP001_000007, ENGINEAPI_720_SP002_000009, ENGINEAPI_720_SP999999_999999, J2EE_ENGINE_SERVERCORE_710_SP009_000021, J2EE_ENGINE_SERVERCORE_710_SP010_000015, J2EE_ENGINE_SERVERCORE_710_SP011_000000, J2EE_ENGINE_SERVERCORE_710_SP999999_999999, J2EE_ENGINE_SERVERCORE_711_SP003_000024, J2EE_ENGINE_SERVERCORE_711_SP004_000019, J2EE_ENGINE_SERVERCORE_711_SP005_000000, J2EE_ENGINE_SERVERCORE_711_SP999999_999999, J2EE_ENGINE_SERVERCORE_720_SP001_000011, J2EE_ENGINE_SERVERCORE_720_SP002_000013, J2EE_ENGINE_SERVERCORE_720_SP003_000000, J2EE_ENGINE_SERVERCORE_720_SP999999_999999, LM_NWA_BASIC_APPS_710_SP009_000003, LM_NWA_BASIC_APPS_710_SP010_000002, LM_NWA_BASIC_APPS_710_SP999999_999999, LM_NWA_BASIC_APPS_711_SP003_000003, LM_NWA_BASIC_APPS_711_SP004_000004, LM_NWA_BASIC_APPS_711_SP005_000001, LM_NWA_BASIC_APPS_711_SP999999_999999, LM_NWA_BASIC_APPS_720_SP001_000004, LM_NWA_BASIC_APPS_720_SP002_000004, LM_NWA_BASIC_APPS_720_SP003_000002, LM_NWA_BASIC_APPS_720_SP004_000001, LM_NWA_BASIC_APPS_720_SP999999_999999)
Описание
This note is relevant only for systems on which SAP Note 1310561 has been applied; servlet_jsp service property 'SessionIdRegenerationEnabled' is set to true; and the error described in the Symptom section appears.
There are two situations in which this error can appear:
Case 1:
The system has detected a real session fixation attack from an untrusted HTTP client.
Details:
Two clients are using identical session identifying tokens (session cookies), being able to access the same session. When one of the clients obtains access to additional protected resources (triggering user re-authentication), the other client is no longer able to access the session with the old cookies and receives a response code 403 Forbidden.
Case 2:
There is an application scenario with parallel requests where at least one of them performs authentication.
Although for the server this scenario looks identical with Case 1, the expected behavior is the user to receive no error message.
Details:
"Parallel requests" here stands for requests that are sent to the server before the request performing authentication is returned and the session cookies in the browser are updated.
For instance multiple HTML iFrame tags in an HTML page are loaded through parallel requests to the server. If the requested resource is protected the requests will trigger authentication.
Another example is a Portal scenario where one click can trigger several parallel requests to different iViews, some of which may require user authentication.
The session fixation protection mechanism of the server works as described for Case 1. The first request that authenticates the user changes the authentication state of the client session. As a result the rest of the parallel requests are already with outdated session cookies, and are treated by the server as potential malicious requests.
To avoid forbidding these subsequent requests, and make the server accept them, the application can be customized so that the server accepts such parallel requests with outdated cookies within a short grace period after each successful authentication.
There are two situations in which this error can appear:
Case 1:
The system has detected a real session fixation attack from an untrusted HTTP client.
Details:
Two clients are using identical session identifying tokens (session cookies), being able to access the same session. When one of the clients obtains access to additional protected resources (triggering user re-authentication), the other client is no longer able to access the session with the old cookies and receives a response code 403 Forbidden.
Case 2:
There is an application scenario with parallel requests where at least one of them performs authentication.
Although for the server this scenario looks identical with Case 1, the expected behavior is the user to receive no error message.
Details:
"Parallel requests" here stands for requests that are sent to the server before the request performing authentication is returned and the session cookies in the browser are updated.
For instance multiple HTML iFrame tags in an HTML page are loaded through parallel requests to the server. If the requested resource is protected the requests will trigger authentication.
Another example is a Portal scenario where one click can trigger several parallel requests to different iViews, some of which may require user authentication.
The session fixation protection mechanism of the server works as described for Case 1. The first request that authenticates the user changes the authentication state of the client session. As a result the rest of the parallel requests are already with outdated session cookies, and are treated by the server as potential malicious requests.
To avoid forbidding these subsequent requests, and make the server accept them, the application can be customized so that the server accepts such parallel requests with outdated cookies within a short grace period after each successful authentication.
Как исправить
Case 1:
If a session fixation attack is in place the error message is returned to the client with the outdated cookies (the attacker), while the client that has obtained access to the protected resource is able to continue their work.
Case 2:
Disclaimer: The following recommendations must be applied only when the scenario is well investigated and certainly matches case 2.
An easy way to determine that case 2 occurred is to reproduce the scenario with a single web client. If there are requests that are sent in parallel and some of them are responded with 403 Forbidden responses, then the scenario matches to case2.
For highest security protection the recommendations to be considered in the following order:
1) If possible revise the scenario implementation to avoid re-authentication in parallel requests. For example, design the application with an initial authentication request, followed by the necessary parallel requests.
2) If the previous option is not possible, consider configuring the applications, affected by the parallel requests scenario, to use the same authentication stack.
If additional configuration of the grace period, during which parallel requests within one authentication stack is accepted, is necessary refer to SAP Note 1464914.
3) If the previous options are not possible, change the authentication stack configuration of the application. Set the "Session Fixation Protection" property to "Grace Period" (the default value is "Strict"). This will make the server accept parallel requests to this application within the grace period, described in SAP Note 1464914.
Procedure for options 2) and 3):
1. Start SAP NetWeaver Administrator and go to quick link /nwa/auth.
2. Choose Components.
3. Select the policy configuration of type Web, corresponding to the affected web application.
4. On the "Authentication Stack" tab, choose Edit
5.
5.1. For option 2) edit the "Login Modules" section
5.2. For option 3) change the value of the "Session Fixation Protection" property to "Grace Period"
6. Save the configuration.
Note: option 3) above should be used with caution and only to authentication mechanisms that are secure enough (e.g. x509 certificate) and cannot be easily imitated by a third party client.
If a session fixation attack is in place the error message is returned to the client with the outdated cookies (the attacker), while the client that has obtained access to the protected resource is able to continue their work.
Case 2:
Disclaimer: The following recommendations must be applied only when the scenario is well investigated and certainly matches case 2.
An easy way to determine that case 2 occurred is to reproduce the scenario with a single web client. If there are requests that are sent in parallel and some of them are responded with 403 Forbidden responses, then the scenario matches to case2.
For highest security protection the recommendations to be considered in the following order:
1) If possible revise the scenario implementation to avoid re-authentication in parallel requests. For example, design the application with an initial authentication request, followed by the necessary parallel requests.
2) If the previous option is not possible, consider configuring the applications, affected by the parallel requests scenario, to use the same authentication stack.
If additional configuration of the grace period, during which parallel requests within one authentication stack is accepted, is necessary refer to SAP Note 1464914.
3) If the previous options are not possible, change the authentication stack configuration of the application. Set the "Session Fixation Protection" property to "Grace Period" (the default value is "Strict"). This will make the server accept parallel requests to this application within the grace period, described in SAP Note 1464914.
Procedure for options 2) and 3):
1. Start SAP NetWeaver Administrator and go to quick link /nwa/auth.
2. Choose Components.
3. Select the policy configuration of type Web, corresponding to the affected web application.
4. On the "Authentication Stack" tab, choose Edit
5.
5.1. For option 2) edit the "Login Modules" section
5.2. For option 3) change the value of the "Session Fixation Protection" property to "Grace Period"
6. Save the configuration.
Note: option 3) above should be used with caution and only to authentication mechanisms that are secure enough (e.g. x509 certificate) and cannot be easily imitated by a third party client.
Ссылки
