CVE-2025-24894: SPID.AspNetCore.Authentication The AspNetCore Remote Authenticator For Vulnerability

CRITICAL
Advisory Identifier: GHSA-36h8-r92j-w9vw
CVSS 9.1
CWE-290
Published
Advisory Summary

CVE-2025-24894 is a CRITICAL (CVSS 9.1) the aspnetcore remote authenticator for vulnerability (CWE-290: Authentication Bypass by Spoofing) affecting SPID.AspNetCore.Authentication libraries in the NuGet ecosystem. The issue involves the aspnetcore remote authenticator for spid allows saml response signature verification bypass. Remediation is available by upgrading affected packages to version 3.4.0.

CVE-2025-24894 at a Glance

CVE Identifier CVE-2025-24894
GHSA Identifier GHSA-36h8-r92j-w9vw
Severity CRITICAL
CVSS v3.1 Base Score 9.1
CWE Classification CWE-290: Authentication Bypass by Spoofing
Affected Product SPID.AspNetCore.Authentication
Package Ecosystem NuGet
Published Date
Last Updated

Security Impact

CVSS: 9.1

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N).

Attack Vector Network (AV:N)
Attack Complexity Low (AC:L)
Privileges Required None (PR:N)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity High (I:H)
Availability None (A:N)

How to Fix CVE-2025-24894

To remediate this vulnerability, upgrade all affected SPID.AspNetCore.Authentication dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

SPID.AspNetCore.Authentication fixed: 3.4.0
Upgrade SPID.AspNetCore.Authentication to 3.4.0
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for SPID.AspNetCore.Authentication

How to Check if You Are Affected

To determine whether your application is affected by CVE-2025-24894, inspect your project dependencies for SPID.AspNetCore.Authentication:

inspect dependencies for SPID.AspNetCore.Authentication

Analyze the terminal output to locate any version of SPID.AspNetCore.Authentication in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 3.4.0), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-290: Authentication Bypass by Spoofing, where this attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks. In SPID.AspNetCore.Authentication, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### 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: ![](https://github.com/user-attachments/assets/5b10c8f8-5121-446f-95f8-c0355daa5959) 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`. ```csharp 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): ```xml <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: ![](https://github.com/user-attachments/assets/42b8c97a-96ae-45c9-afed-aab7066201a1) ### 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 1. Clone the repository https://github.com/italia/spid-aspnetcore.git 2. From the root of the project, enter the folder relating to the example webapp: `samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/` 3. Change the value of the `AssertionConsumerServiceURL` key in the file `appsettings.json` to a custom domain: `https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid` 4. 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` 5. Visit URL: `https://$CUSTOM_DOMAIN:$CUSTOM_PORT/` 6. Click "Enter with SPID" > "DemoSpid" (second IdP in the list) 7. Visit the "Response" > "Check Response" section 8. Insert the following string into the "Audience" field (right column): `https://spid.aspnetcore.it/` 9. Click "Send response to Service Provider", note the redirect to `/home/loggedin` and consequently the correct execution of the login on the example portal ![](https://github.com/user-attachments/assets/af3775a1-5f01-4ffa-9b28-730fef487869) 10. Repeat steps 5 to 8 inclusive 11. Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite 12. Perform URL-decoding and Base64-decoding of the POST `SAMLResponse` parameter 13. Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml 14. Change the contents of the tag `<saml:Assertion>`, for example change the `email` attribute to an arbitrary value: `spid.tech@shielder.it` 15. Run Base64-encoding and then URL-encoding the `SAMLResponse` parameter 16. 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 ![](https://github.com/user-attachments/assets/a725401f-7884-4910-b4e5-b6c55c1cde83) ### Recommended Solution Verify all signatures within the SAML response and do not accept unsigned XML elements. ### References - https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html ### Credits - [Abdel Adim `smaury` Oisfi](https://x.com/smaury92) di [Shielder](https://www.shielder.com) - [Paolo`paupu` Cavaglià](https://x.com/paupu_95) di [Shielder](https://www.shielder.com) - [Nicola `fromveeko` Davico](https://x.com/fromveeko) di [Shielder](https://www.shielder.com)

CVE-2025-24894 Affected SPID.AspNetCore.Authentication Versions

1 component(s)
Fixed Versions:
3.4.0
Product / Package Ecosystem Affected Versions Fixed Version
SPID.AspNetCore.Authentication
NuGet
< 3.4.0
3.4.0

References

Frequently Asked Questions

What is CVE-2025-24894?
CVE-2025-24894 is a security vulnerability in SPID.AspNetCore.Authentication involving The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass under CWE-290: Authentication Bypass by Spoofing.
Which SPID.AspNetCore.Authentication versions are affected?
Affected versions include releases prior to 3.4.0 across affected packages: SPID.AspNetCore.Authentication.
What version fixes CVE-2025-24894?
Upgrading to 3.4.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is SPID.AspNetCore.Authentication affected?
Yes, SPID.AspNetCore.Authentication is affected in releases prior to 3.4.0. Upgrade your dependency to 3.4.0 or later.
What is the CVSS score of CVE-2025-24894?
CVE-2025-24894 has a CVSS v3.1 base score of 9.1 (CRITICAL) with vector string CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N.
What CWE is associated with CVE-2025-24894?
CVE-2025-24894 is classified under CWE-290: Authentication Bypass by Spoofing (This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.).
How can I check NuGet dependencies for CVE-2025-24894?
Run the dependency tree command: 'inspect dependencies for SPID.AspNetCore.Authentication'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-36h8-r92j-w9vw",
  "modified" : "2025-02-18T19:25:13Z",
  "published" : "2025-02-18T19:25:13Z",
  "aliases" : [ "CVE-2025-24894" ],
  "summary" : "The AspNetCore Remote Authenticator for SPID Allows SAML Response Signature Verification Bypass",
  "details" : "### Description\n\nAuthentication using Spid and CIE is based on the SAML2 standard which provides for two entities:\n\nIdentity 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;\nService 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.\nThe 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:\n\n![](https://github.com/user-attachments/assets/5b10c8f8-5121-446f-95f8-c0355daa5959)\n\nAs 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.\n\nThe signature validation logic is central as it ensures that you cannot craft a SAML response with arbitrary assertions and thus impersonate other users.\n\nThe following is the validation code implemented in `spid-aspnetcore`.\n\n```csharp\ninternal static bool VerifySignature(XmlDocument signedDocument, IdentityProvider? identityProvider = null){\n    //...SNIP...\n    SignedXml signedXml = new SignedXml(signedDocument);\n    if (identityProvider is not null)\n    {\n        bool validated = false;\n        foreach (var certificate in identityProvider.X509SigningCertificates){\n            var publicMetadataCert = new X509Certificate2(Convert.FromBase64String(certificate));\n            XmlNodeList nodeList = (signedDocument.GetElementsByTagName(\"ds:Signature\")?.Count > 1) ?\n                                    signedDocument.GetElementsByTagName(\"ds:Signature\") :\n                                   (signedDocument.GetElementsByTagName(\"ns2:Signature\")?.Count > 1) ?\n                                    signedDocument.GetElementsByTagName(\"ns2:Signature\") :\n                                    signedDocument.GetElementsByTagName(\"Signature\");\n            signedXml.LoadXml((XmlElement)nodeList[0]);\n            validated |= signedXml.CheckSignature(publicMetadataCert, true);\n        }\n        return validated;\n    }\n    else{\n        XmlNodeList nodeList = (signedDocument.GetElementsByTagName(\"ds:Signature\")?.Count > 0) ?\n                               signedDocument.GetElementsByTagName(\"ds:Signature\") :\n                               signedDocument.GetElementsByTagName(\"Signature\");\n        signedXml.LoadXml((XmlElement)nodeList[0]);\n        return signedXml.CheckSignature();\n    }\n    //...SNIP...\n}\n```\n\nThe 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.\n\nNext, 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.\n\nFinally, the first element of this list, i.e. the first signature found, is extracted and verified.\n\nIn a normal authentication flow, the SAML response looks like this (note that some fields and attributes have been omitted for ease of reading):\n\n```xml\n<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\">\n    <saml:Issuer Format=\"urn:oasis:names:tc:SAML:2.0:nameid-format:entity\">\n        https://demo.spid.gov.it/validator\n    </saml:Issuer>\n    <ds:Signature xmlns:ds=\"http://www.w3.org/2000/09/xmldsig#\">\n        <ds:SignedInfo>\n            <ds:CanonicalizationMethod Algorithm=\"http://www.w3.org/2001/10/xml-exc-c14n#\"/>\n            <ds:SignatureMethod Algorithm=\"http://www.w3.org/2001/04/xmldsig-more#rsa-sha256\"/>\n            <ds:Reference URI=\"#response_id\">\n                <ds:Transforms>\n                    <ds:Transform Algorithm=\"http://www.w3.org/2000/09/xmldsig#enveloped-signature\"/>\n                </ds:Transforms>\n                <ds:DigestMethod Algorithm=\"http://www.w3.org/2001/04/xmlenc#sha256\"/>\n                <ds:DigestValue>\n                    <!-- DIGEST -->\n                </ds:DigestValue>\n            </ds:Reference>\n        </ds:SignedInfo>\n        <ds:SignatureValue>\n           <!-- SIGNATURE -->\n        </ds:SignatureValue>\n        <ds:KeyInfo>\n            <ds:X509Data>\n                <ds:X509Certificate>\n                    <!-- CERTIFICATE -->\n                </ds:X509Certificate>\n            </ds:X509Data>\n        </ds:KeyInfo>\n    </ds:Signature>\n    <samlp:Status>\n        <samlp:StatusCode Value=\"urn:oasis:names:tc:SAML:2.0:status:Success\"/>\n    </samlp:Status>\n    <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\">\n        <saml:Issuer Format=\"urn:oasis:names:tc:SAML:2.0:nameid-format:entity\">\n            https://demo.spid.gov.it/validator\n        </saml:Issuer>\n        <ds:Signature xmlns:ds=\"http://www.w3.org/2000/09/xmldsig#\">\n            <ds:SignedInfo>\n                <ds:CanonicalizationMethod Algorithm=\"http://www.w3.org/2001/10/xml-exc-c14n#\"/>\n                <ds:SignatureMethod Algorithm=\"http://www.w3.org/2001/04/xmldsig-more#rsa-sha256\"/>\n                <ds:Reference URI=\"#assertion_id\">\n                    <ds:Transforms>\n                        <ds:Transform Algorithm=\"http://www.w3.org/2000/09/xmldsig#enveloped-signature\"/>\n                    </ds:Transforms>\n                    <ds:DigestMethod Algorithm=\"http://www.w3.org/2001/04/xmlenc#sha256\"/>\n                    <ds:DigestValue>\n                        <!-- DIGEST -->\n                    </ds:DigestValue>\n                </ds:Reference>\n            </ds:SignedInfo>\n            <ds:SignatureValue>\n                <!-- SIGNATURE -->\n            </ds:SignatureValue>\n            <ds:KeyInfo>\n                <ds:X509Data>\n                    <ds:X509Certificate>\n                        <!-- CERTIFICATE -->\n                    </ds:X509Certificate>\n                </ds:X509Data>\n            </ds:KeyInfo>\n        </ds:Signature>\n        <saml:AttributeStatement>\n            <saml:Attribute Name=\"spidCode\" NameFormat=\"urn:oasis:names:tc:SAML:2.0:attrname-format:basic\">\n                <saml:AttributeValue xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xsi:type=\"xs:string\">\n                    AGID-001\n                </saml:AttributeValue>\n            </saml:Attribute>\n            <!-- ... SNIP ... -->\n        </saml:AttributeStatement>\n    </saml:Assertion>\n</samlp:Response>\n```\n\nThe 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.\n\nHowever, 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.\n\nThe SAML response would be structured like this:\n\n![](https://github.com/user-attachments/assets/42b8c97a-96ae-45c9-afed-aab7066201a1)\n\n### Impact\nAn 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.\n\n### Complexity of the attack\nThe 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.\n\n### Related issues\nN/A\n\n### PoC\n\n1. Clone the repository https://github.com/italia/spid-aspnetcore.git\n2. From the root of the project, enter the folder relating to the example webapp: `samples/1_SimpleSPWebApp/SPID.AspNetCore.WebApp/`\n3. Change the value of the `AssertionConsumerServiceURL` key in the file `appsettings.json` to a custom domain: `https://$CUSTOM_DOMAIN:$CUSTOM_PORT/signin-spid`\n4. 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`\n5. Visit URL: `https://$CUSTOM_DOMAIN:$CUSTOM_PORT/`\n6. Click \"Enter with SPID\" > \"DemoSpid\" (second IdP in the list)\n7. Visit the \"Response\" > \"Check Response\" section\n8. Insert the following string into the \"Audience\" field (right column): `https://spid.aspnetcore.it/`\n9. Click \"Send response to Service Provider\", note the redirect to  `/home/loggedin` and consequently the correct execution of the login on the example portal\n\n![](https://github.com/user-attachments/assets/af3775a1-5f01-4ffa-9b28-730fef487869)\n\n10. Repeat steps 5 to 8 inclusive\n11. Intercept the HTTP request generated in step 8 via an HTTP Proxy, such as PortSwigger's BurpSuite\n12. Perform URL-decoding and Base64-decoding of the POST `SAMLResponse` parameter\n13. Insert the content present at the following URL in the second line of the XML: https://demo.spid.gov.it/metadata.xml\n14. Change the contents of the tag `<saml:Assertion>`, for example change the `email` attribute to an arbitrary value: `spid.tech@shielder.it`\n15. Run Base64-encoding and then URL-encoding the `SAMLResponse` parameter\n16. 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\n\n![](https://github.com/user-attachments/assets/a725401f-7884-4910-b4e5-b6c55c1cde83)\n\n### Recommended Solution\n\nVerify all signatures within the SAML response and do not accept unsigned XML elements.\n\n### References\n\n- https://cheatsheetseries.owasp.org/cheatsheets/SAML_Security_Cheat_Sheet.html\n\n### Credits\n- [Abdel Adim `smaury` Oisfi](https://x.com/smaury92) di [Shielder](https://www.shielder.com)\n- [Paolo`paupu` Cavaglià](https://x.com/paupu_95) di [Shielder](https://www.shielder.com)\n- [Nicola `fromveeko` Davico](https://x.com/fromveeko) di [Shielder](https://www.shielder.com)",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "NuGet",
      "name" : "SPID.AspNetCore.Authentication"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "3.4.0"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 3.3.0"
    }
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/italia/spid-aspnetcore/security/advisories/GHSA-36h8-r92j-w9vw"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/italia/spid-aspnetcore/commit/093efa2273f8a1e0481f678a0bfcd57fbdc7b029"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/italia/spid-aspnetcore"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-290" ],
    "severity" : "CRITICAL",
    "github_reviewed" : true,
    "github_reviewed_at" : "2025-02-18T19:25:13Z",
    "nvd_published_at" : null
  }
}