Remarque pour les pentests d'applications

Lorsque la sécurité d'applications intégrées à eIAM est contrôlée à l'aide d'un pentest, il y a souvent des constatations qui sont liées à eIAM.

Cette page documente les trouvailles récurrentes pour eIAM et décrit leur signification.

Manipulation de l'attribut SameSite

Ces considérations se rapportent au cookie NPSession*, qui suit la session sur le PEP. Il est important de noter qu'il ne s'agit pas de la session de l'application.

Fonctionnement du SameSite

L'attribut de cookie samesite permet de contrôler quels cookies le navigateur est autorisé à envoyer lors de l'appel d'une URL <site>, en cas d'accès à celle-ci depuis une URL <site> étrangère. Il s'agit donc d'une des mesures possibles pour empêcher les attaques "Cross-Site Request Forgery" (CSRF ou XSRF en abrégé).

Tous les accès au même domaine sont considérés comme SameSite, donc par exemple tout ce qui est sous admin.ch.
Tout le reste sont des accès Cross-Site.

Les règles complètes se trouvent ici :

Analyse

Cross-Site GET	Site croisé   POST	SameSite GET	SameSite POST	Note
Strict	-	-	SENT	SENT
Lax	SENT	-	SENT	SENT	Valeur par défaut Il y a des navigateurs qui envoient aussi au POST dans les 2 premières minutes après le premier placement du cookie, mais on ne peut pas s'y fier
Non	SENT	SENT	SENT	SENT	En outre, l'attribut secure doit encore être défini.

Protection contre les attaques CSRF grâce à l'attribut SameSite

Voir aussi

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.

Cas	Scénario	SameSite nécessaire Paramètres du PEP Cookies de session	Description	Justification / Conclusion
1	STS-PEP : l'application et le PEP sont des sites croisés. Un attaquant envoie une AuthRequest au PEP sur le site croisé.	samesite=none	Comme l'application est également intersite, aucun attaquant ne peut être bloqué de cette manière. La protection CSRF fonctionne différemment avec SAML : signature de l'AuthnRequest par l'application Liste blanche des URL de retour (ACS-Whitelisting), c'est-à-dire que les réponses sont toujours envoyées à l'application cible, et non à l'attaquant. Des URL de retour incorrectes dans les AuthnRequests entraînent un message d'erreur. Avec un samesite=strict, ce n'est pas l'application qui serait protégée, mais uniquement la session sur le PEP, qui ne peut pas être utilisée dans ce cas. Dans ce cas, le SSO / SLO avec d'autres applications n'est donc plus possible	samesite=none sur le cookie de session PEP est le seul paramètre possible.
2	STS-PEP : l'application et le PEP sont SameSite. Un attaquant envoie une AuthnRequest cross-site au PEP	samesite=strict	Le login fonctionne aussi pour l'attaquant. Toutefois, il ne s'agit pas d'un SSO / SLO pour l'attaquant, ce qui ne devrait de toute façon pas l'intéresser. Un attaquant pourrait toutefois contourner cette restriction en appelant simplement le lien de connexion de l'application au lieu d'envoyer une AuthnRequest au PEP.	samesite=strict sur le cookie de session PEP est possible, mais n'apporte aucun avantage.
3	RP-PEP : PEP et BTB sont des sites croisés. C'est typiquement le cas dans le pattern d'intégration RP-PEP, mais il y a des exceptions (https://sts002.swissmedic.ch/). Un attaquant envoie une AuthnRequest au PEP	samesite=none	PEP traite la requête GET/POST et transmet la requête au BTB. En fin de compte, le PEP reçoit en retour un jeton SAML. Si le jeton SAML émis ne correspond pas à l'AuthnRequest, un message d'erreur est émis, ce qui entraîne la tenue d'une session sur le PEP. Si samesite=strict est défini, la session ne peut plus être trouvée et le PEP réagit avec un message d'erreur. Du point de vue de l'application, il n'est donc plus possible de se connecter. Il est important de mentionner ici que pour les intégrations RP-PEP, cette session contient en plus un CookieStore, dans lequel les cookies de l'application peuvent être cachés au client. Si l'application protège ses cookies de session avec samesite=strict, cette protection serait inefficace, car les cookies ne parviennent jamais au navigateur, mais sont contrôlés par le cookie de session PEP. Les 2 points suivants sont importants : La protection CSRF ne devrait pas s'appuyer uniquement sur SameSite (voir ci-dessus), si l'application en a besoin, le Cookie Store peut être désactivé par configuration. La protection CSRF proprement dite ne se base pas sur les cookies, mais sur des éléments d'en-tête HTTP ou de formulaires cachés qui ne peuvent pas être influencés par la session PEP	samesite=none sur le cookie de la session PEP est le seul paramètre possible.
4	RP-PEP : PEP et BTB sont des sites croisés. C'est typiquement le cas dans le pattern d'intégration RP-PEP, mais il y a des exceptions (https://sts002.swissmedic.ch/). La session est maintenant établie. L'attaquant envoie maintenant une requête cross-site à l'application.	samesite=none	La session PEP est établie. Le RP-PEP devient ainsi transparent, c'est-à-dire que le navigateur et le backend peuvent communiquer entre eux tant que la session PEP existe. Un attaquant qui fait une requête cross-site contre l'application sera rejeté si samesite=strict, car le PEP ne trouve pas sa session. Toutefois, dans ce scénario, il n'est plus possible de se connecter (cas 3), c'est pourquoi il faut tout de même définir samesite=none. Ainsi, le RP-PEP ne peut pas fournir l'effet de protection requis (pour SZ+) dans son intégralité. Il s'agit uniquement de l'accès à la zone, pas de la protection supplémentaire de l'application contre les attaques CSRF.	samesite=none sur le cookie de session PEP est le seul paramètre possible. L'effet de protection (protection du périmètre lors de l'accès à la zone SZ+) du PEP RP est limité.
5	RP-PEP : PEP et BTB sont SameSite. La session est établie. L'attaquant envoie maintenant une requête cross-site à l'application.	samesite=strict	L'attaquant est bloqué par le RP-PEP, car la session PEP n'est pas trouvée. Toutefois, l'effet de protection ainsi obtenu n'est qu'un effet qui, selon le concept de zone, n'est exigé que pour SZ+ (accès authentique à la zone). Cela signifie que tous les autres PEP RP qui permettent des accès à d'autres zones ne doivent pas obligatoirement avoir samesite=strict.	samesite=strict est utile et possible. Il est obligatoire pour les accès à la zone SZ+, optionnel pour tous les autres accès

SameSite pour le cookie NPSession*

Les règles suivantes s'appliquent donc à l'attribut SameSite pour l'eIAM :

samesite=none est défini
Sauf si l'application est intégrée à RP-PEP et si l'application se trouve dans une zone nécessitant une protection accrue (par ex. SZ+) (cas 5 ci-dessus)