Bedienungsanleitung
Was das ist
Füge eine SAMLResponse/SAMLRequest ein — die komplette URL eines Redirect-Bindings, den Base64-Wert eines POST-Bindings oder das bereits dekodierte XML — und sie wird dekodiert und geprüft: Signatur, Algorithmen, Ablauf, Audience und das klassische Angriffsmuster XML Signature Wrapping (XSW). Nichts verlässt den Browser.
Die Signatur prüfen
Wenn du das Signaturzertifikat des IdP einfügst (in PEM, in Base64 wie in der Metadata, oder die gesamte Metadata), prüft es jede Signatur wirklich: dass das Signierte sich nicht geändert hat (der Digest) und dass sie mit dem Schlüssel dieses Zertifikats signiert wurde. Niemals mit dem Zertifikat, das in der Nachricht in KeyInfo enthalten ist: das setzt derjenige, der signiert, und ein Angreifer setzt sein eigenes. Eine gültige Signatur reicht nicht: Sie muss außerdem die Assertion abdecken, die deine Anwendung liest, und das prüft die XSW-Regel. Geprüft mit xmldsigjs, abgeglichen mit von echten IdPs signierten Antworten.
Was das NICHT macht
Entschlüsselt keine verschlüsselten Assertions (dafür bräuchte es den privaten Schlüssel des Service Providers, der nirgendwo eingefügt werden sollte), prüft nicht die Zertifikatskette des IdP (in SAML wird ihm vertraut, weil er im Metadata steht, nicht wegen des Ausstellers) und weiß nicht, welche ID deine Anwendung wirklich liest: Wenn dein Code die Assertion anders auswählt, kann XSW weiterhin durchrutschen.
Was ist XSW?
XML Signature Wrapping: Ein Angreifer schleust ein neues Element ein (mit derselben ID wie das Original oder einer anderen), damit der Code, der die Signatur validiert, etwas anderes betrachtet als der Code, der die Daten liest. Das bricht in der Produktion immer noch SSO-Implementierungen — PortSwigger hat es 2025 erneut dokumentiert.
