SPID.AspNetCore.Authentication

Version	Released
`3.4.0` minor	Feb 08, 2025
`3.3.0` minor 1 CVE	May 25, 2024
`3.2.0` minor 1 CVE	May 14, 2024
`3.1.1` patch 1 CVE	Dec 18, 2023
`3.1.0` minor 1 CVE	Nov 04, 2023
`3.0.0` major 1 CVE	Oct 14, 2023
`2.0.4` patch 1 CVE	Aug 24, 2023
`2.0.3` patch 1 CVE	Aug 22, 2023
`2.0.3-preview` pre 1 CVE	Aug 22, 2023
`2.0.2` patch 1 CVE	Jul 07, 2023
`2.0.1` patch 1 CVE	Jul 06, 2023
`2.0.0` major 1 CVE	Mar 31, 2023
`2.0.0-prerelease` pre 1 CVE	Mar 15, 2023
`1.3.12` patch 1 CVE	Jul 01, 2022
`1.3.12-prerelease` pre 1 CVE	Jul 01, 2022
`1.3.11` patch 1 CVE	May 06, 2022
`1.3.10` patch 1 CVE	Feb 14, 2022
`1.3.9` patch 1 CVE	Dec 06, 2021
`1.3.8` patch 1 CVE	Nov 24, 2021
`1.3.7` patch 1 CVE	Nov 24, 2021
`1.3.7-prerelease` pre 1 CVE	Nov 24, 2021
`1.3.6` patch 1 CVE	Nov 14, 2021
`1.3.5` patch 1 CVE	Oct 05, 2021
`1.3.4` patch 1 CVE	Jun 30, 2021
`1.3.3` patch 1 CVE	Jun 20, 2021
`1.3.2` patch 1 CVE	Jun 14, 2021
`1.3.1` patch 1 CVE	Jun 04, 2021
`1.3.0` minor 1 CVE	Jun 04, 2021
`1.2.1` patch 1 CVE	May 06, 2021
`1.2.0` minor 1 CVE	Apr 13, 2021
`1.1.5` patch 1 CVE	Apr 09, 2021
`1.1.4` patch 1 CVE	Mar 30, 2021
`1.1.3` patch 1 CVE	Feb 11, 2021
`1.1.2` patch 1 CVE	Feb 03, 2021
`1.1.1` patch 1 CVE	Jan 26, 2021
`1.1.0` minor 1 CVE	Jan 25, 2021
`1.0.2` patch 1 CVE	Jan 24, 2021
`1.0.1` patch 1 CVE	Jan 22, 2021
`1.0.0` initial 1 CVE	Jan 22, 2021

3.4.0 minor

Feb 08, 2025

3.3.0 minor

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

May 25, 2024

3.2.0 minor

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

May 14, 2024

3.1.1 patch

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Dec 18, 2023

3.1.0 minor

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Nov 04, 2023

3.0.0 major

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Oct 14, 2023

2.0.4 patch

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Aug 24, 2023

2.0.3 patch

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Aug 22, 2023

2.0.3-preview pre

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Aug 22, 2023

2.0.2 patch

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Jul 07, 2023

2.0.1 patch

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Jul 06, 2023

2.0.0 major

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Mar 31, 2023

2.0.0-prerelease pre

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Mar 15, 2023

1.3.12 patch

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Jul 01, 2022

1.3.12-prerelease pre

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Jul 01, 2022

1.3.11 patch

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

May 06, 2022

1.3.10 patch

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Feb 14, 2022

1.3.9 patch

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Dec 06, 2021

1.3.8 patch

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Nov 24, 2021

1.3.7 patch

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Nov 24, 2021

1.3.7-prerelease pre

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Nov 24, 2021

1.3.6 patch

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Nov 14, 2021

1.3.5 patch

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Oct 05, 2021

1.3.4 patch

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Jun 30, 2021

1.3.3 patch

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Jun 20, 2021

1.3.2 patch

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Jun 14, 2021

1.3.1 patch

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Jun 04, 2021

1.3.0 minor

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Jun 04, 2021

1.2.1 patch

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

May 06, 2021

1.2.0 minor

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Apr 13, 2021

1.1.5 patch

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Apr 09, 2021

1.1.4 patch

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Mar 30, 2021

1.1.3 patch

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Feb 11, 2021

1.1.2 patch

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Feb 03, 2021

1.1.1 patch

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Jan 26, 2021

1.1.0 minor

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Jan 25, 2021

1.0.2 patch

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Jan 24, 2021

1.0.1 patch

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Jan 22, 2021

1.0.0 initial

1 CVE

CVE-2025-24894 GHSA-36h8-r92j-w9vw Feb 18, 2025

The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass

9.1 / 10

Critical

Network Low None None Unchanged High High None

Description

Authentication using Spid and CIE is based on the SAML2 standard which provides for two entities:

Identity Provider (IdP): the system that authenticates users and provides identity information ( SAML assertions ) to the Service Provider, essentially, it is responsible for managing user credentials and identity; Service Provider (SP): The system that provides a service to the user and relies on the Identity Provider to authenticate the user, receives SAML assertions from the IdP to grant access to resources. The library spid-aspnetcorerefers to the second entity, i.e. the SP, and implements the validation logic of the SAML assertions present within the SAML response . The following is a summary diagram of an authentication flow via SAML:

As shown in the diagram, the IdP, after verifying the user's credentials, generates a signed SAML response, this is propagated to the SP by the user's browser and the SP, after verifying the signature, can extract the data needed to build the user's session.

The signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.

The following is the validation code implemented in spid-aspnetcore.

internal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){
    //...SNIP...
    SignedXml signedXml = new SignedXml(signedDocument);
    if (identityProvider is not null)
    {
        bool validated = false;
        foreach (var certificate in identityProvider.X509SigningCertificates){
            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));
            XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ds:Signature") :
                                   (signedDocument.GetElementsByTagName("ns2:Signature")?.Count > 1) ?
                                    signedDocument.GetElementsByTagName("ns2:Signature") :
                                    signedDocument.GetElementsByTagName("Signature");
            signedXml.LoadXml((XmlElement)nodeList[0]);
            validated |= signedXml.CheckSignature(publicMetadataCert, true);
        }
        return validated;
    }
    else{
        XmlNodeList nodeList = (signedDocument.GetElementsByTagName("ds:Signature")?.Count > 0) ?
                               signedDocument.GetElementsByTagName("ds:Signature") :
                               signedDocument.GetElementsByTagName("Signature");
        signedXml.LoadXml((XmlElement)nodeList[0]);
        return signedXml.CheckSignature();
    }
    //...SNIP...
}

The parameter signedDocument contains the SAML response in XML format, while the parameter identityProvider can contain the IdP info. If the parameter identityProvider has been specified, the public certificates of that IdP are extracted, so as to force their use during the signature verification, otherwise the certificates configured within the application are used.

Next, a response envelope is generated nodeList within which all XML elements containing an XML signature of part or all of the SAML response envelope are saved.

Finally, the first element of this list, i.e. the first signature found, is extracted and verified.

In a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):

<samlp:Response ID="response_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
    <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
        https://demo.spid.gov.it/validator
    </saml:Issuer>
    <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
        <ds:SignedInfo>
            <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
            <ds:Reference URI="#response_id">
                <ds:Transforms>
                    <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                </ds:Transforms>
                <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                <ds:DigestValue>
                    <!-- DIGEST -->
                </ds:DigestValue>
            </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue>
           <!-- SIGNATURE -->
        </ds:SignatureValue>
        <ds:KeyInfo>
            <ds:X509Data>
                <ds:X509Certificate>
                    <!-- CERTIFICATE -->
                </ds:X509Certificate>
            </ds:X509Data>
        </ds:KeyInfo>
    </ds:Signature>
    <samlp:Status>
        <samlp:StatusCode Value="urn:oasis:names:tc:SAML:2.0:status:Success"/>
    </samlp:Status>
    <saml:Assertion ID="assertion_id" IssueInstant="2025-01-07T13:37:00Z" Version="2.0" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
        <saml:Issuer Format="urn:oasis:names:tc:SAML:2.0:nameid-format:entity">
            https://demo.spid.gov.it/validator
        </saml:Issuer>
        <ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
            <ds:SignedInfo>
                <ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
                <ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
                <ds:Reference URI="#assertion_id">
                    <ds:Transforms>
                        <ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
                    </ds:Transforms>
                    <ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
                    <ds:DigestValue>
                        <!-- DIGEST -->
                    </ds:DigestValue>
                </ds:Reference>
            </ds:SignedInfo>
            <ds:SignatureValue>
                <!-- SIGNATURE -->
            </ds:SignatureValue>
            <ds:KeyInfo>
                <ds:X509Data>
                    <ds:X509Certificate>
                        <!-- CERTIFICATE -->
                    </ds:X509Certificate>
                </ds:X509Data>
            </ds:KeyInfo>
        </ds:Signature>
        <saml:AttributeStatement>
            <saml:Attribute Name="spidCode" NameFormat="urn:oasis:names:tc:SAML:2.0:attrname-format:basic">
                <saml:AttributeValue xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="xs:string">
                    AGID-001
                </saml:AttributeValue>
            </saml:Attribute>
            <!-- ... SNIP ... -->
        </saml:AttributeStatement>
    </saml:Assertion>
</samlp:Response>

The SDK code would get as the first element of the nodeList, that is nodeList[0], the signature referring to the entire SAML response, in fact the reference of the first signature <ds:Reference URI="#response_id"> points to the root object <samlp:Response ID="response_id" ...>. Therefore, verifying this signature will ensure that the entire content of the SAML response is intact and authentic.

However, there is no guarantee that the first signature refers to the root object, so if an attacker injects a signed element as the first element, all other signatures will not be verified. The only requirement is to have a legitimately signed XML element from the IdP, which is easily accomplished using the public metadata of the IdP.

The SAML response would be structured like this:

Impact

An attacker could craft an arbitrary SAML response that would be accepted by SPs using the vulnerable SDKs, allowing him to impersonate any Spid and/or CIE user.

Complexity of the attack

The attacker needs an XML block containing a valid signature from one of the IdPs accepted by the SP. As described above, this requirement is satisfied by reading the public metadata of the IdP which is represented by a signed XML block of the IdP.

Related issues

N/A

PoC

Clone the repository https://github.com/italia/spid-aspnetcore.git
From the root of the project, enter the folder relating to the example webapp: samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/
Change the value of the AssertionConsumerServiceURL key in the file appsettings.json to a custom domain: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid
Compile and run the sample webapp using the following command, taking care to replace the placeholders with the same values used in step 3: dotnet build "SPID.AspNetCore.WebApp.csproj" -o ./app/build && dotnet publish "SPID.AspNetCore.WebApp.csproj" -o ./app/publish && dotnet ./app/publish/SPID.AspNetCore.WebApp.dll -urls=https://$CUSTOM_DOMAIN:$CUSTOM_PORT
Visit URL: https://$CUSTOM_DOMAIN:$CUSTOM_PORT/
Click "Enter with SPID" > "DemoSpid" (second IdP in the list)
Visit the "Response" > "Check Response" section
Insert the following string into the "Audience" field (right column): https://spid.aspnetcore.it/
Click "Send response to Service Provider", note the redirect to /home/loggedin and consequently the correct execution of the login on the example portal

Repeat steps 5 to 8 inclusive
Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite
Perform URL-decoding and Base64-decoding of the POST SAMLResponse parameter
Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml
Change the contents of the tag <saml:Assertion>, for example change the email attribute to an arbitrary value: spid.tech@shielder.it
Run Base64-encoding and then URL-encoding the SAMLResponse parameter
Send the request and note the redirect to /home/loggedin which demonstrates the correct identification and therefore also the verification of the arbitrary signature inserted in SAMLResponse despite the modification of the assertion

References

https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html

Credits

Affected versions


          1.0.0


          1.0.1


          1.0.2


          1.1.0


          1.1.1


          1.1.2


          1.1.3


          1.1.4


          1.1.5


          1.2.0


          1.2.1


          1.3.0

+ 27 more


            1.3.1


            1.3.10


            1.3.11


            1.3.12


            1.3.12-prerelease


            1.3.2


            1.3.3


            1.3.4


            1.3.5


            1.3.6


            1.3.7


            1.3.7-prerelease


            1.3.8


            1.3.9


            2.0.0


            2.0.0-prerelease


            2.0.1


            2.0.2


            2.0.3


            2.0.3-preview


            2.0.4


            3.0.0


            3.1.0


            3.1.1


            3.2.0


            3.3.0


            3.3.0-prerelease

Fixed in


          3.4.0

References

Updated Feb 18, 2025 · Source: OSV.dev

Jan 22, 2021

Activity

Details