Common Weakness Enumeration

CWE-290

Allowed

Authentication Bypass by Spoofing

Abstraction: Base · Status: Incomplete

This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.

925 vulnerabilities reference this CWE, most recent first.

GHSA-VM34-2MCQ-J9Q8

Vulnerability from github – Published: 2024-09-23 18:30 – Updated: 2024-11-04 18:31

Details

Entrust Instant Financial Issuance (On Premise) Software (formerly known as Cardwizard) 6.10.0, 6.9.0, 6.9.1, 6.9.2, and 6.8.x and earlier leaves behind a configuration file (i.e. WebAPI.cfg.xml) after the installation process. This file can be accessed without authentication on HTTP port 80 by guessing the correct IIS webroot path. It includes system configuration parameter names and values with sensitive configuration values encrypted.

Severity

5.9 (Medium)


                  
                    CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-39341"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-23T18:15:05Z",
    "severity": "MODERATE"
  },
  "details": "Entrust Instant Financial Issuance (On Premise) Software (formerly known as Cardwizard) 6.10.0, 6.9.0, 6.9.1, 6.9.2, and 6.8.x and earlier leaves behind a configuration file (i.e. WebAPI.cfg.xml) after the installation process. This file can be accessed without authentication on HTTP port 80 by guessing the correct IIS webroot path. It includes system configuration parameter names and values with sensitive configuration values encrypted.",
  "id": "GHSA-vm34-2mcq-j9q8",
  "modified": "2024-11-04T18:31:18Z",
  "published": "2024-09-23T18:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-39341"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/VAMorales/21a8700a67d80c263b38e693fd528313"
    },
    {
      "type": "WEB",
      "url": "https://trustedcare.entrust.com/login"
    },
    {
      "type": "WEB",
      "url": "https://www.entrust.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VM5R-C87R-PF6X

Vulnerability from github – Published: 2023-01-31 22:21 – Updated: 2023-02-04 00:14

Summary

Parse Server option `masterKeyIps` vulnerability to IP spoofing

Details

Impact

Parse Server uses the request header x-forwarded-for to determine the client IP address. If Parse Server doesn't run behind a proxy server, then a client can set this header and Parse Server will trust the value of the header. The incorrect client IP address will be used by various features in Parse Server. This allows to circumvent the security mechanism of the Parse Server option masterKeyIps by setting an allowed IP address as the x-forwarded-for header value.

Patches

The mechanism to determine the client IP address has been rewritten. The correct IP address determination now requires to set the Parse Server option trustProxy accordingly, see the express framework's trust proxy setting.

References

https://github.com/parse-community/parse-server/security/advisories/GHSA-vm5r-c87r-pf6x
https://expressjs.com/en/guide/behind-proxies.html

Severity

8.7 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "parse-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "5.4.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2023-22474"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-01-31T22:21:48Z",
    "nvd_published_at": "2023-02-03T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "### Impact\n\nParse Server uses the request header `x-forwarded-for` to determine the client IP address. If Parse Server doesn\u0027t run behind a proxy server, then a client can set this header and Parse Server will trust the value of the header. The incorrect client IP address will be used by various features in Parse Server. This allows to circumvent the security mechanism of the Parse Server option `masterKeyIps` by setting an allowed IP address as the `x-forwarded-for` header value.\n\n### Patches\n\nThe mechanism to determine the client IP address has been rewritten. The correct IP address determination now requires to set the Parse Server option `trustProxy` accordingly, see the express framework\u0027s [trust proxy](https://expressjs.com/en/guide/behind-proxies.html) setting.\n\n### References\n- https://github.com/parse-community/parse-server/security/advisories/GHSA-vm5r-c87r-pf6x\n- https://expressjs.com/en/guide/behind-proxies.html",
  "id": "GHSA-vm5r-c87r-pf6x",
  "modified": "2023-02-04T00:14:05Z",
  "published": "2023-01-31T22:21:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/security/advisories/GHSA-vm5r-c87r-pf6x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-22474"
    },
    {
      "type": "WEB",
      "url": "https://github.com/parse-community/parse-server/commit/e016d813e083ce6828f9abce245d15b681a224d8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/parse-community/parse-server"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Parse Server option `masterKeyIps` vulnerability to IP spoofing"
}

GHSA-VP68-F85J-5GW3

Vulnerability from github – Published: 2026-04-17 03:30 – Updated: 2026-04-17 03:30

Details

Cloud Foundry UUA is vulnerable to a bypass that allows an attacker to obtain a token for any user and gain access to UAA-protected systems. This vulnerability exists when SAML 2.0 bearer assertions are enabled for a client, as the UAA accepts SAML 2.0 bearer assertions that are neither signed nor encrypted. This issue affects UUA from v77.30.0 to v78.7.0 (inclusive) and it affects CF Deployment from v48.7.0 to v54.14.0 (inclusive).

Severity

8.6 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2026-22734"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-17T01:17:37Z",
    "severity": "HIGH"
  },
  "details": "Cloud Foundry UUA is\u00a0vulnerable to a bypass that allows an attacker to obtain a token for any user and gain access to UAA-protected systems. This vulnerability exists when SAML 2.0 bearer assertions are enabled for a client, as the UAA accepts SAML 2.0 bearer assertions that are neither signed nor encrypted.\u00a0This issue affects UUA\u00a0from v77.30.0 to v78.7.0 (inclusive)\u00a0and it affects\u00a0CF Deployment\u00a0from v48.7.0 to v54.14.0 (inclusive).",
  "id": "GHSA-vp68-f85j-5gw3",
  "modified": "2026-04-17T03:30:51Z",
  "published": "2026-04-17T03:30:51Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-22734"
    },
    {
      "type": "WEB",
      "url": "https://www.cloudfoundry.org/blog/cve-2026-22734-uaa-saml-2-0-signature-bypass"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VPF7-3WWJ-8VJH

Vulnerability from github – Published: 2023-07-14 18:31 – Updated: 2024-04-04 06:08

Details

Microsoft Edge for iOS Spoofing Vulnerability

Severity

4.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2023-36883"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-07-14T18:15:10Z",
    "severity": "MODERATE"
  },
  "details": "Microsoft Edge for iOS Spoofing Vulnerability",
  "id": "GHSA-vpf7-3wwj-8vjh",
  "modified": "2024-04-04T06:08:49Z",
  "published": "2023-07-14T18:31:03Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-36883"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2023-36883"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VPFG-W257-RQ9F

Vulnerability from github – Published: 2024-12-19 00:37 – Updated: 2024-12-26 21:30

Details

An IDOR vulnerability in the manage-notes.php module in PHPGurukul Online Notes Sharing Management System v1.0 allows unauthorized users to delete notes belonging to other accounts due to missing authorization checks. This flaw enables attackers to delete another user's information.

Severity

5.4 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-55232"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-12-18T22:15:07Z",
    "severity": "MODERATE"
  },
  "details": "An IDOR vulnerability in the manage-notes.php module in PHPGurukul Online Notes Sharing Management System v1.0 allows unauthorized users to delete notes belonging to other accounts due to missing authorization checks. This flaw enables attackers to delete another user\u0027s information.",
  "id": "GHSA-vpfg-w257-rq9f",
  "modified": "2024-12-26T21:30:36Z",
  "published": "2024-12-19T00:37:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-55232"
    },
    {
      "type": "WEB",
      "url": "https://github.com/CV1523/CVEs/blob/main/CVE-2024-55232.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VQ63-8F72-F486

Vulnerability from github – Published: 2025-02-18 19:25 – Updated: 2025-02-18 19:25

Summary

AspNetCore Remote Authenticator for CIE3.0 Allows SAML Response Signature Verification Bypass

Details

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 cie-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 cie-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

Severity

9.1 (Critical)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.0.4"
      },
      "package": {
        "ecosystem": "NuGet",
        "name": "CIE.AspNetCore.Authentication"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2.1.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2025-24895"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2025-02-18T19:25:19Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "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 `cie-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\u0027s credentials, generates a signed SAML response, this is propagated to the SP by the user\u0027s browser and the SP, after verifying the signature, can extract the data needed to build the user\u0027s 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 `cie-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 \u003e 1) ?\n                                    signedDocument.GetElementsByTagName(\"ds:Signature\") :\n                                   (signedDocument.GetElementsByTagName(\"ns2:Signature\")?.Count \u003e 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 \u003e 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\u003csamlp: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\"\u003e\n    \u003csaml:Issuer Format=\"urn:oasis:names:tc:SAML:2.0:nameid-format:entity\"\u003e\n        https://demo.spid.gov.it/validator\n    \u003c/saml:Issuer\u003e\n    \u003cds:Signature xmlns:ds=\"http://www.w3.org/2000/09/xmldsig#\"\u003e\n        \u003cds:SignedInfo\u003e\n            \u003cds:CanonicalizationMethod Algorithm=\"http://www.w3.org/2001/10/xml-exc-c14n#\"/\u003e\n            \u003cds:SignatureMethod Algorithm=\"http://www.w3.org/2001/04/xmldsig-more#rsa-sha256\"/\u003e\n            \u003cds:Reference URI=\"#response_id\"\u003e\n                \u003cds:Transforms\u003e\n                    \u003cds:Transform Algorithm=\"http://www.w3.org/2000/09/xmldsig#enveloped-signature\"/\u003e\n                \u003c/ds:Transforms\u003e\n                \u003cds:DigestMethod Algorithm=\"http://www.w3.org/2001/04/xmlenc#sha256\"/\u003e\n                \u003cds:DigestValue\u003e\n                    \u003c!-- DIGEST --\u003e\n                \u003c/ds:DigestValue\u003e\n            \u003c/ds:Reference\u003e\n        \u003c/ds:SignedInfo\u003e\n        \u003cds:SignatureValue\u003e\n           \u003c!-- SIGNATURE --\u003e\n        \u003c/ds:SignatureValue\u003e\n        \u003cds:KeyInfo\u003e\n            \u003cds:X509Data\u003e\n                \u003cds:X509Certificate\u003e\n                    \u003c!-- CERTIFICATE --\u003e\n                \u003c/ds:X509Certificate\u003e\n            \u003c/ds:X509Data\u003e\n        \u003c/ds:KeyInfo\u003e\n    \u003c/ds:Signature\u003e\n    \u003csamlp:Status\u003e\n        \u003csamlp:StatusCode Value=\"urn:oasis:names:tc:SAML:2.0:status:Success\"/\u003e\n    \u003c/samlp:Status\u003e\n    \u003csaml: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\"\u003e\n        \u003csaml:Issuer Format=\"urn:oasis:names:tc:SAML:2.0:nameid-format:entity\"\u003e\n            https://demo.spid.gov.it/validator\n        \u003c/saml:Issuer\u003e\n        \u003cds:Signature xmlns:ds=\"http://www.w3.org/2000/09/xmldsig#\"\u003e\n            \u003cds:SignedInfo\u003e\n                \u003cds:CanonicalizationMethod Algorithm=\"http://www.w3.org/2001/10/xml-exc-c14n#\"/\u003e\n                \u003cds:SignatureMethod Algorithm=\"http://www.w3.org/2001/04/xmldsig-more#rsa-sha256\"/\u003e\n                \u003cds:Reference URI=\"#assertion_id\"\u003e\n                    \u003cds:Transforms\u003e\n                        \u003cds:Transform Algorithm=\"http://www.w3.org/2000/09/xmldsig#enveloped-signature\"/\u003e\n                    \u003c/ds:Transforms\u003e\n                    \u003cds:DigestMethod Algorithm=\"http://www.w3.org/2001/04/xmlenc#sha256\"/\u003e\n                    \u003cds:DigestValue\u003e\n                        \u003c!-- DIGEST --\u003e\n                    \u003c/ds:DigestValue\u003e\n                \u003c/ds:Reference\u003e\n            \u003c/ds:SignedInfo\u003e\n            \u003cds:SignatureValue\u003e\n                \u003c!-- SIGNATURE --\u003e\n            \u003c/ds:SignatureValue\u003e\n            \u003cds:KeyInfo\u003e\n                \u003cds:X509Data\u003e\n                    \u003cds:X509Certificate\u003e\n                        \u003c!-- CERTIFICATE --\u003e\n                    \u003c/ds:X509Certificate\u003e\n                \u003c/ds:X509Data\u003e\n            \u003c/ds:KeyInfo\u003e\n        \u003c/ds:Signature\u003e\n        \u003csaml:AttributeStatement\u003e\n            \u003csaml:Attribute Name=\"spidCode\" NameFormat=\"urn:oasis:names:tc:SAML:2.0:attrname-format:basic\"\u003e\n                \u003csaml:AttributeValue xmlns:xs=\"http://www.w3.org/2001/XMLSchema\" xmlns:xsi=\"http://www.w3.org/2001/XMLSchema-instance\" xsi:type=\"xs:string\"\u003e\n                    AGID-001\n                \u003c/saml:AttributeValue\u003e\n            \u003c/saml:Attribute\u003e\n            \u003c!-- ... SNIP ... --\u003e\n        \u003c/saml:AttributeStatement\u003e\n    \u003c/saml:Assertion\u003e\n\u003c/samlp:Response\u003e\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 `\u003cds:Reference URI=\"#response_id\"\u003e` points to the root object `\u003csamlp:Response ID=\"response_id\" ...\u003e`. 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 \u200b\u200bused in step 3: `dotnet build \"SPID.AspNetCore.WebApp.csproj\" -o ./app/build \u0026\u0026 dotnet publish \"SPID.AspNetCore.WebApp.csproj\" -o ./app/publish \u0026\u0026 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\" \u003e \"DemoSpid\" (second IdP in the list)\n7. Visit the \"Response\" \u003e \"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\u0027s 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 `\u003csaml:Assertion\u003e`, 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\u00e0](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)",
  "id": "GHSA-vq63-8f72-f486",
  "modified": "2025-02-18T19:25:19Z",
  "published": "2025-02-18T19:25:19Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/italia/cie-aspnetcore/security/advisories/GHSA-vq63-8f72-f486"
    },
    {
      "type": "WEB",
      "url": "https://github.com/italia/cie-aspnetcore/commit/e66b7f336ff5d4c69f95f197f27f3145f2484994"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/italia/cie-aspnetcore"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "AspNetCore Remote Authenticator for CIE3.0 Allows SAML Response Signature Verification Bypass"
}

GHSA-VQ77-78V5-MQFP

Vulnerability from github – Published: 2022-05-24 17:01 – Updated: 2022-10-14 19:00

Details

Incorrect implementation in navigation in Google Chrome prior to 78.0.3904.70 allowed a remote attacker to spoof the contents of the Omnibox (URL bar) via a crafted HTML page.

Severity

4.3 (Medium)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2019-13701"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-11-25T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Incorrect implementation in navigation in Google Chrome prior to 78.0.3904.70 allowed a remote attacker to spoof the contents of the Omnibox (URL bar) via a crafted HTML page.",
  "id": "GHSA-vq77-78v5-mqfp",
  "modified": "2022-10-14T19:00:21Z",
  "published": "2022-05-24T17:01:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-13701"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2019/10/stable-channel-update-for-desktop_22.html"
    },
    {
      "type": "WEB",
      "url": "https://crbug.com/998284"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-01/msg00008.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VQJ4-MPGW-JRQV

Vulnerability from github – Published: 2022-07-29 00:00 – Updated: 2022-08-11 00:00

Details

Saia Burgess Controls (SBC) PCD through 2022-05-06 allows Authentication bypass. According to FSCT-2022-0062, there is a Saia Burgess Controls (SBC) PCD S-Bus authentication bypass issue. The affected components are characterized as: S-Bus (5050/UDP) authentication. The potential impact is: Authentication bypass. The Saia Burgess Controls (SBC) PCD controllers utilize the S-Bus protocol (5050/UDP) for a variety of engineering purposes. It is possible to configure a password in order to restrict access to sensitive engineering functionality. Authentication functions on the basis of a MAC/IP whitelist with inactivity timeout to which an authenticated client's MAC/IP is stored. UDP traffic can be spoofed to bypass the whitelist-based access control. Since UDP is stateless, an attacker capable of passively observing traffic can spoof arbitrary messages using the MAC/IP of an authenticated client. This allows the attacker access to sensitive engineering functionality such as uploading/downloading control logic and manipulating controller configuration.

Severity

8.1 (High)


                  
                    CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2022-30319"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-287",
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-07-28T16:15:00Z",
    "severity": "HIGH"
  },
  "details": "Saia Burgess Controls (SBC) PCD through 2022-05-06 allows Authentication bypass. According to FSCT-2022-0062, there is a Saia Burgess Controls (SBC) PCD S-Bus authentication bypass issue. The affected components are characterized as: S-Bus (5050/UDP) authentication. The potential impact is: Authentication bypass. The Saia Burgess Controls (SBC) PCD controllers utilize the S-Bus protocol (5050/UDP) for a variety of engineering purposes. It is possible to configure a password in order to restrict access to sensitive engineering functionality. Authentication functions on the basis of a MAC/IP whitelist with inactivity timeout to which an authenticated client\u0027s MAC/IP is stored. UDP traffic can be spoofed to bypass the whitelist-based access control. Since UDP is stateless, an attacker capable of passively observing traffic can spoof arbitrary messages using the MAC/IP of an authenticated client. This allows the attacker access to sensitive engineering functionality such as uploading/downloading control logic and manipulating controller configuration.",
  "id": "GHSA-vqj4-mpgw-jrqv",
  "modified": "2022-08-11T00:00:38Z",
  "published": "2022-07-29T00:00:24Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-30319"
    },
    {
      "type": "WEB",
      "url": "https://www.cisa.gov/uscert/ics/advisories/icsa-22-207-03"
    },
    {
      "type": "WEB",
      "url": "https://www.forescout.com/blog"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VV5G-XQ9C-77W7

Vulnerability from github – Published: 2024-10-12 15:30 – Updated: 2024-10-16 21:31

Details

Zendesk before 2024-07-02 allows remote attackers to read ticket history via e-mail spoofing, because Cc fields are extracted from incoming e-mail messages and used to grant additional authorization for ticket viewing, the mechanism for detecting spoofed e-mail messages is insufficient, and the support e-mail addresses associated with individual tickets are predictable.

Severity

7.5 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-49193"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-10-12T14:15:02Z",
    "severity": "HIGH"
  },
  "details": "Zendesk before 2024-07-02 allows remote attackers to read ticket history via e-mail spoofing, because Cc fields are extracted from incoming e-mail messages and used to grant additional authorization for ticket viewing, the mechanism for detecting spoofed e-mail messages is insufficient, and the support e-mail addresses associated with individual tickets are predictable.",
  "id": "GHSA-vv5g-xq9c-77w7",
  "modified": "2024-10-16T21:31:07Z",
  "published": "2024-10-12T15:30:42Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-49193"
    },
    {
      "type": "WEB",
      "url": "https://gist.github.com/hackermondev/68ec8ed145fcee49d2f5e2b9d2cf2e52"
    },
    {
      "type": "WEB",
      "url": "https://news.ycombinator.com/item?id=41818459"
    },
    {
      "type": "WEB",
      "url": "https://x.com/hackermondev/status/1844877950698537323"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-VVPG-5WFC-53JJ

Vulnerability from github – Published: 2024-04-24 06:30 – Updated: 2024-07-03 18:36

Details

cdbattags lua-resty-jwt 0.2.3 allows attackers to bypass all JWT-parsing signature checks by crafting a JWT with an enc header with the value A256GCM.

Severity

8.1 (High)


                  
                    CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N

Show details on source website

JSON

To clipboard

{
  "affected": [],
  "aliases": [
    "CVE-2024-33531"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-24T06:15:14Z",
    "severity": "HIGH"
  },
  "details": "cdbattags lua-resty-jwt 0.2.3 allows attackers to bypass all JWT-parsing signature checks by crafting a JWT with an enc header with the value A256GCM.",
  "id": "GHSA-vvpg-5wfc-53jj",
  "modified": "2024-07-03T18:36:46Z",
  "published": "2024-04-24T06:30:31Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33531"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cdbattags/lua-resty-jwt/issues/61"
    },
    {
      "type": "WEB",
      "url": "https://github.com/cdbattags/lua-resty-jwt/commit/d1558e2afefe868fea1e7e9a4b04ea94ab678a85"
    },
    {
      "type": "WEB",
      "url": "https://insinuator.net/2023/10/lua-resty-jwt-authentication-bypass"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-21: Exploitation of Trusted Identifiers

An adversary guesses, obtains, or "rides" a trusted identifier (e.g. session ID, resource ID, cookie, etc.) to perform authorized actions under the guise of an authenticated user or service.

CAPEC-22: Exploiting Trust in Client

An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.

CAPEC-459: Creating a Rogue Certification Authority Certificate

An adversary exploits a weakness resulting from using a hashing algorithm with weak collision resistance to generate certificate signing requests (CSR) that contain collision blocks in their "to be signed" parts. The adversary submits one CSR to be signed by a trusted certificate authority then uses the signed blob to make a second certificate appear signed by said certificate authority. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.

CAPEC-461: Web Services API Signature Forgery Leveraging Hash Function Extension Weakness

An adversary utilizes a hash function extension/padding weakness, to modify the parameters passed to the web service requesting authentication by generating their own call in order to generate a legitimate signature hash (as described in the notes), without knowledge of the secret token sometimes provided by the web service.

CAPEC-473: Signature Spoof

An attacker generates a message or datablock that causes the recipient to believe that the message or datablock was generated and cryptographically signed by an authoritative or reputable source, misleading a victim or victim operating system into performing malicious actions.

CAPEC-476: Signature Spoofing by Misrepresentation

An attacker exploits a weakness in the parsing or display code of the recipient software to generate a data blob containing a supposedly valid signature, but the signer's identity is falsely represented, which can lead to the attacker manipulating the recipient software or its victim user to perform compromising actions.

CAPEC-59: Session Credential Falsification through Prediction

This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.

CAPEC-60: Reusing Session IDs (aka Session Replay)

This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.

CAPEC-667: Bluetooth Impersonation AttackS (BIAS)

An adversary disguises the MAC address of their Bluetooth enabled device to one for which there exists an active and trusted connection and authenticates successfully. The adversary can then perform malicious actions on the target Bluetooth device depending on the target’s capabilities.

CAPEC-94: Adversary in the Middle (AiTM)

An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.

← Back to the CWE list