Hinweise für Pentests von Applikationen

Wenn eIAM integrierte Applikationen mit einem Pentest auf die Sicherheit geprüft werden, dann gibt es oftmals auch Findings, welche mit eIAM zusammenhängen.

Diese Seite dokumentiert wiederkehrende Findings bei eIAM und beschreibt deren Bedeutung.

Handhabung SameSite Attribut

Diese Betrachtungen beziehen sich auf das Cookie NPSession*, welches auf dem PEP die Session trackt. Wichtig zu sehen ist, dass es sich hier nicht um die Session der Applikation handelt.

SameSite Funktionsweise

Mit dem Cookie Attribut samesite kann gesteuert werden, welche Cookies der Browser beim Aufruf einer <site> URL mit senden darf, falls von einer fremden <site> URL darauf zugegriffen wird. Damit ist dies eine der möglichen Massnahmen um "Cross-Site Request Forgery" Angriffe (CSRF oder XSRF abgekürzt) zu verhindern.
  • Als SameSite gelten alle Zugriffe auf die gleiche Domain, also z.B. alles was unter admin.ch ist.
  • Alles andere sind Cross-Site Zugriffe.
Die vollständigen Regeln finden sich hier:

Cross-Site              
GET 		Cross-Site                
POST 		SameSite              
GET 		SameSite              
POST
Hinweis
Strict
-
-
 SENT SENT
Lax SENT
-
 SENT SENT Default-Wert
Es gibt Browser, welche in den ersten 2 Minuten nach dem erstmaligen Setzen des Cookies auch bei POST gesendet werden, aber darauf kann man sich nicht verlassen
Non SENT SENT SENT SENT Zusätzlich muss noch das Attribut secure gesetzt werden.

Schutz vor CSRF-Angriffe durch das SameSite-Attribut

Siehe auch

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.

Analyse


Fall
Szenario
 Notwendiger SameSite
Parameter des PEP
Session Cookies
Beschreibung
 Begründung / Fazit
1 STS-PEP: Applikation und PEP sind Cross-Site.
Ein Angreifer sendet Cross-Site einen AuthRequest an den PEP
 samesite=none Da auch die Applikation Cross-Site ist, kann auf diese Weise auch kein Angreifer blockiert werden.
Der CSRF Schutz funktioniert bei SAML auf andere Weise:
  • Signierung des AuthnRequests durch die Applikation
  • Whitelist der Return-URLs (ACS-Whitelisting), d.h. Antworten werden immer der Zielapplikation gesandt, nicht dem Angreifer. Respektive falsche Return-URLs in den AuthnRequests führen zu einer Fehlermeldung.
    Mit einem samesite=strict würde nicht die Applikation geschützt, sondern nur die Session auf dem PEP, welche in diesem Fall nicht verwendet werden kann. Daher ist in diesem Fall kein SSO / SLO mit anderen Applikationen mehr möglich
    		• samesite=none auf dem PEP-Session Cookie ist der einzig möglicher Parameter.
    2 STS-PEP: Applikation und PEP sind SameSite.
    Ein Angreifer sendet Cross-Site einen AuthnRequest an den PEP     		samesite=strict Das Login funktioniert auch für den Angreifer. Allerdings ist es für den Angreifer kein SSO / SLO, woran er aber sowieso nicht interessiert sein dürfte.
    Diese Einschränkung könnte ein Angreifer jedoch umgehen, in dem er statt einen AuthnRequest an den PEP einfach den Login-Link der Applikation aufruft.     		samesite=strict auf dem PEP-Session Cookie ist möglich, bringt aber keinen Vorteil.
    3 RP-PEP: PEP und BTB sind Cross-Site. Typischerweise ist dies im RP-PEP Integrationspattern der Fall, es gibt jedoch Ausnahmen (https://sts002.swissmedic.ch/).
    Ein Angreifer sendet einen AuthnRequest an den PEP     		samesite=none PEP verarbeitet den GET/POST Request und leitet den Request an den BTB weiter. Letztendlich bekommt der PEP dann ein SAML-Token zurück. Falls das ausgestellte SAML-Token nicht zum AuthnRequest passt, erfolgt eine Fehlermeldung, wozu auf dem PEP eine Session geführt wird.
    Wird nun samesite=strict gesetzt, kann die Session nicht mehr gefunden werden und der PEP reagiert mit einer Fehlermeldung. Aus Sicht Applikation ist damit kein Login mehr möglich.
    Wichtig zu erwähnen ist hier noch, dass bei RP-PEP Integrationen diese Session zusätzlich einen CookieStore beinhaltet, worin die Cookies der Applikation vor dem Client verborgen werden können. Sollte die Applikation ihre Session Cookies dort mit samesite=strict schützen, würde dieser Schutz wirkungslos, weil die Cookies gar nie zum Browser kommen, sondern vom PEP Session Cookie gesteuert werden. Folgende 2 Punkte sind wichtig:
  • Der CSRF-Schutz sollte sich nicht alleine auf SameSite abstützen (siehe oben), falls aus Sicht Applikation doch nötig, kann der Cookie Store konfigurativ disabled werden
  • Der eigentliche CSRF-Schutz basiert nicht auf Cookies, sondern auf HTTP-Header oder Hidden-Forms Elemente, welche von der PEP-Session nicht beeinflusst werden können
    		• samesite=none auf dem PEP-Session Cookie ist der einzig möglicher Parameter.
    4
    RP-PEP: PEP und BTB sind Cross-Site. Typischerweise ist dies im RP-PEP Integrationspattern der Fall, es gibt jedoch Ausnahmen (https://sts002.swissmedic.ch/).
    Die Session ist nun etabliert. Der Angreifer sendet nun Cross-Site ein Request an die Applikation.     		samesite=none Die PEP-Session ist etabliert. Damit wird der RP-PEP transparent, d.h. Browser und Backend können miteinander kommunizieren, solange die PEP-Session existiert.
    Ein Angreifer der Cross-Site einen Request gegen die Applikation stellt, wird bei samesite=strict abgewiesen, da der PEP seine Session nicht findet.
    Allerdings ist in diesem Szenario kein Login mehr möglich (Fall 3), daher muss doch samesite=none gesetzt werden.
    Damit kann der RP-PEP die geforderte Schutzwirkung (für SZ+) nicht vollumfänglich leisten. Dabei geht es nur um den Zonenzugang, nicht um den weiteren Schutz der Applikation vor CSRF-Angriffe.     		samesite=none auf dem PEP-Session Cookie ist der einzig möglicher Parameter.
    Die Schutzwirkung (Perimeter-Schutz beim Zugang zu SZ+ Zone) des RP-PEPs ist eingeschränkt.
    5 RP-PEP: PEP und BTB sind SameSite.
    Die Session ist etabliert. Der Angreifer sendet nun Cross-Site ein Request an die Applikation.     		samesite=strict Der Angreifer wird vom RP-PEP blockiert, weil die PEP-Session nicht gefunden wird.
    Allerdings ist die damit erreichte Schutzwirkung nur eine, welche gemäss Zonenkonzept nur für SZ+ gefordert wird (authentischer Zonenzugang).
    Dies bedeutet, dass alle anderen RP-PEPs, welche Zugänge in andere Zonen ermöglichen, samesite=strict nicht zwingend haben müssen.     		samesite=strict ist sinnvoll und möglich.
    Bei Zugängen zur SZ+ Zone ist dies zwingend, für alle anderen Zugänge optional

    SameSite beim Cookie NPSession*

    Daher gelten betreffend dem SameSite Attribute bei eIAM folgende Regeln:
    • samesite=none ist gesetzt
    • AUSSER: Die Applikation ist RP-PEP-integriert und die Applikation ist in einer Zone mit erhöhtem Schutzbedarf (z.B. SZ+) (Obiger Fall 5)