Notes for pentests of applications

When eIAM-integrated applications are tested for security using a pentest, there are often also findings that are related to eIAM.

This page documents recurring findings in eIAM and describes their significance.

Handling Samesite attribute

These considerations relate to the NPSession* cookie, which tracks the session on the PEP. It is important to note that this is not the session of the application.

SameSite functionality

The samesite cookie attribute can be used to control which cookies the browser is allowed to send when a <site> URL is called up if it is accessed from a third-party <site> URL. This is one of the possible measures to prevent "Cross-Site Request Forgery" attacks (CSRF or XSRF for short).
  • As SameSite are all accesses to the same domain, e.g. everything under admin.ch.
  • Everything else is Cross-Site access.
The complete rules can be found here:

Cross-Site              
GET 		Cross-Site                
POST 		SameSite              
GET 		SameSite              
POST
Note
Strict
-
-
 SENT SENT
Lax SENT
-
 SENT SENT Default value
There are browsers which are also sent on POST in the first 2 minutes after the cookie is set for the first time, but you cannot rely on this
Non SENT SENT SENT SENT In addition, the secure attribute must be set.

Protection against CSRF attacks by the SameSite attribute

See also

It is important to note that this attribute should be implemented as an additional layer defense in depth concept. This attribute protects the user through the browsers supporting it, and it contains as well 2 ways to bypass it as mentioned in the following section. This attribute should not replace having a CSRF Token. Instead, it should co-exist with that token in order to protect the user in a more robust way.

Analysis


Case
Scenario
 Necessary SameSite
Parameters of the PEP
Session Cookies
Description
 Reason / Conclusion
1 STS-PEP: Application and PEP are cross-site.
An attacker sends a cross-site AuthRequest to the PEP
 samesite=none As the application is also cross-site, no attacker can be blocked in this way.
CSRF protection works in a different way with SAML:
  • Signing of the AuthnRequest by the application
  • Whitelisting of return URLs (ACS whitelisting), i.e. responses are always sent to the target application, not to the attacker. Respectively incorrect return URLs in the AuthnRequests lead to an error message.
    A samesite=strict would not protect the application, but only the session on the PEP, which cannot be used in this case. Therefore, SSO / SLO with other applications is no longer possible in this case
    		• samesite=none on the PEP session cookie is the only possible parameter.
    2 STS-PEP: Application and PEP are SameSite.
    An attacker sends a cross-site AuthnRequest to the PEP     		samesite=strict The login also works for the attacker. However, it is not an SSO / SLO for the attacker, which he is unlikely to be interested in anyway.
    However, an attacker could circumvent this restriction by simply calling up the login link of the application instead of an AuthnRequest to the PEP.     		samesite=strict on the PEP session cookie is possible, but does not provide any advantage.
    3 RP-PEP: PEP and BTB are cross-site. This is typically the case in the RP-PEP integration pattern, but there are exceptions (https://sts002.swissmedic.ch/).
    An attacker sends an AuthnRequest to the PEP     		samesite=none PEP processes the GET/POST request and forwards the request to the BTB. Finally, the PEP receives a SAML token back. If the issued SAML token does not match the AuthnRequest, an error message is issued, for which a session is maintained on the PEP.
    If samesite=strict is now set, the session can no longer be found and the PEP responds with an error message. From the application's point of view, login is no longer possible.
    It is also important to mention here that with RP-PEP integrations, this session also contains a CookieStore in which the application's cookies can be hidden from the client. If the application protects its session cookies there with samesite=strict, this protection would be ineffective because the cookies never reach the browser, but are controlled by the PEP session cookie. The following 2 points are important:
  • The CSRF protection should not be based solely on SameSite (see above), if necessary from the application's point of view, the cookie store can be disabled configuratively
  • The actual CSRF protection is not based on cookies, but on HTTP headers or hidden forms elements that cannot be influenced by the PEP session.
    • 4
    RP-PEP: PEP and BTB are cross-site. This is typically the case in the RP-PEP integration pattern, but there are exceptions (https://sts002.swissmedic.ch/).
    The session is now established. The attacker now sends a cross-site request to the application.     		samesite=none The PEP session is established. This makes the RP-PEP transparent, i.e. the browser and backend can communicate with each other as long as the PEP session exists.
    An attacker who makes a cross-site request against the application is rejected if samesite=strict, as the PEP cannot find its session.
    However, login is no longer possible in this scenario (case 3), so samesite=none must be set.
    This means that the RP-PEP cannot fully provide the required protection (for SZ+). This is only about zone access, not about further protection of the application against CSRF attacks.     		samesite=none on the PEP session cookie is the only possible parameter.
    The protective effect (perimeter protection when accessing the SZ+ zone) of the RP-PEP is restricted.
    5 RP-PEP: PEP and BTB are SameSite.
    The session is established. The attacker now sends a cross-site request to the application.     		samesite=strict The attacker is blocked by the RP-PEP because the PEP session is not found.
    However, the protective effect achieved in this way is only one that is only required for SZ+ according to the zone concept (authentic zone access).
    This means that all other RP-PEPs that allow access to other zones do not necessarily have to have samesite=strict.     		samesite=strict is sensible and possible.
    This is mandatory for access to the SZ+ zone and optional for all other accesses

    SameSite for cookie NPSession*

    Therefore, the following rules apply to the SameSite attribute in eIAM:
    • samesite=none is set
    • EXCEPT: The application is RP-PEP-integrated and the application is in a zone with increased protection requirements (e.g. SZ+) (case 5 above)