For more clarification, here is the email we got from BundID:
Dear colleagues,
You are receiving this email because you have indicated that you would like to be informed about BundID maintenance windows etc.
On June 10, 2024 and June 24, we already informed you about the publication of a possible scam attack in connection with BundID.
After working with the online service concerned, we would like to provide you with some final information.
About the first attack (redirect):
A reprocessing of the first attack has revealed that the ReturnTo variable (in the SAML context: the RelayState) could be used to trigger the unwanted redirect. The RelayState can be used by an online service to return the user to the originally accessed service in the logged-in state after successful login to the IDP. A component of the online service concerned was responsible for sending (and subsequently processing) the RelayState. The BundID cannot technically reduce or avoid this risk in a meaningful way by means of a check. However, the following approaches are strongly recommended to minimize the risk of successful misuse:
Displaying the name of the calling portal/online service when the user is authenticated in the BundID. This shows the user where they are expected to be returned. If there are any deviations, the user has the opportunity to react. I.e. for communication with the BundID on the part of the online service: transfer of the OrganizationDisplayName attribute.
Checking the SAML-RelayState before processing by the online service. Alternatively: no use of the RelayState attribute, or no use of URLs in the RelayState. This may mean that the required data is held for the user by the online service until the user returns authenticated.
The second attack (Liferay):
The changes in the online service component after the first attack have taken effect so far. In the second attack, however, attackers were able to exploit the misconfiguration of the Liferay portal base, where the abusive redirect was “hidden” within a valid redirect. There was also no validation of the redirect in the Liferay configuration; this has since been rectified.
For our part, we can make the following recommendations:
Ensure that the components and libraries used are updated regularly, especially in the case of known vulnerabilities (CVEs)
Follow the recommendations of the OWASP (e.g. the Secure Coding Practices). In the course of this, for example, code reviews should be carried out in which attention is paid to such points. In addition, technical solutions such as static code analysis tools, dependency checkers, etc. can be used to identify errors or security gaps during implementation.
Back URL
The back URL should be treated in a similar way to the RelaySate. Manipulation can also potentially take place via the back URL. For this reason, if you use the back URL, we recommend the same measures as for the RelayState.
Translated with DeepL.com (free version)