GHSA-2P3C-P3QW-69R4

Vulnerability from github – Published: 2022-10-12 14:15 – Updated: 2023-07-31 20:39
VLAI
Summary
The graphql-upload library included in Apollo Server 2 is vulnerable to CSRF mutations
Details

Impact

The graphql-upload npm package can execute GraphQL operations contained in content-type: multipart/form-data POST requests. Because they are POST requests, they can contain GraphQL mutations. Because they use content-type: multipart/form-data, they can be "simple requests" which are not preflighted by browsers.

If your GraphQL server uses graphql-upload and uses SameSite=None cookies for authentication, then JS on any origin can cause browsers to send cookie-authenticated mutations to your GraphQL server, which will be executed without checking your CORS policy first. (The attack won't be able to see the response to the mutation if your CORS policy is set up properly, but the side effects of the mutation will still happen.)

Additionally, if your GraphQL server uses graphql-upload and relies on network properties for security (whether by explicitly looking at the client's IP address or by only being available on a private network), then JS on any origin can cause browsers (which may be on a private network or have an allowed IP address) to send mutations to your GraphQL server, which will be executed without checking your CORS policy first. (This attack does not require your server to use cookies. It is in some cases prevented by some browsers such as Chrome.)

Apollo Server 2 bundled graphql-upload and enabled it by default, so by default, Apollo Server 2 servers are vulnerable to these CSRF attacks. (Apollo Server 1 did not bundle graphql-upload. Apollo Server 3 no longer bundles graphql-upload, although AS3's docs do document how to manually integrate with graphql-upload.) It is enabled even if your server makes no use of the upload functionality.

If you are running Apollo Server 2 (older than v2.25.4) and do not specify uploads: false to new ApolloServer, then you are vulnerable to this CSRF mutation attack.

We recently introduced an opt-in CSRF prevention feature in Apollo Server 3.7. This feature successfully protects against CSRF even if you have manually integrated your AS3.7 server with graphql-upload. However, this feature is not available for Apollo Server 2.

Patches

If you are using Apollo Server 2 and do not actually use uploads in your schema (ie, the Upload scalar is not used as the argument to any field or in any input object definition, and you do not specify uploads to new ApolloServer), then upgrading to Apollo Server 2.25.4 will automatically disable graphql-upload in your server. This will fix the CSRF mutation vulnerability.

Upgrading to v2.25.4 does still leave your server vulnerable to non-mutation CSRF attacks such as timing attacks against query operations. To protect yourself against these potentially lower impact CSRF attack, we encourage upgrading to Apollo Server v3.7 and enabling CSRF prevention. See the Apollo Server 3 migration guide and the CSRF prevention docs for details.

If you are actively using the uploads feature with Apollo Server 2, then upgrading to v2.25.4 will not disable the feature and you will still be vulnerable. You should instead upgrade to v3.7 and enable the CSRF prevention feature.

If you are manually integrating the graphql-upload package with any version of Apollo Server (or any Node GraphQL server) and need to continue using the feature, then you must enable some sort of CSRF prevention feature to fix this vulnerability. We recommend the CSRF prevention feature in Apollo Server 3.7.

Workarounds

Instead of upgrading your Apollo Server 2 server, you can specify uploads: false to new ApolloServer to disable the graphql-upload integration and protect against CSRF mutations. (Only do this if you do not actually use the uploads feature in your server!) This will still leave your server vulnerable to non-mutation CSRF attacks such as timing attacks against query operations; you need to upgrade to v3.7 and enable CSRF prevention to protect against these attacks.

Related work

Show details on source website

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "apollo-server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.0.0"
            },
            {
              "fixed": "2.25.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-352"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2022-10-12T14:15:48Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "### Impact\nThe [graphql-upload](https://www.npmjs.com/package/graphql-upload) npm package can execute GraphQL operations contained in `content-type: multipart/form-data` POST requests. Because they are POST requests, they can contain GraphQL mutations. Because they use `content-type: multipart/form-data`, they can be \"simple requests\" which are not preflighted by browsers.\n\nIf your GraphQL server uses `graphql-upload` and uses `SameSite=None` cookies for authentication, then JS on any origin can cause browsers to send cookie-authenticated mutations to your GraphQL server, which will be executed without checking your CORS policy first. (The attack won\u0027t be able to see the response to the mutation if your CORS policy is set up properly, but the side effects of the mutation will still happen.)\n\nAdditionally, if your GraphQL server uses `graphql-upload` and relies on network properties for security (whether by explicitly looking at the client\u0027s IP address or by only being available on a private network), then JS on any origin can cause browsers (which may be on a private network or have an allowed IP address) to send mutations to your GraphQL server, which will be executed without checking your CORS policy first. (This attack does not require your server to use cookies. It is in some cases prevented by some browsers such as Chrome.)\n\nApollo Server 2 bundled `graphql-upload` and enabled it by default, so by default, Apollo Server 2 servers are vulnerable to these CSRF attacks.  (Apollo Server 1 did not bundle `graphql-upload`. Apollo Server 3 no longer bundles `graphql-upload`, although AS3\u0027s docs do document how to manually integrate with `graphql-upload`.) It is enabled even if your server makes no use of the upload functionality.\n\nIf you are running Apollo Server 2 (older than v2.25.4) and do not specify `uploads: false` to `new ApolloServer`, then you are vulnerable to this CSRF mutation attack.\n\nWe recently introduced an opt-in CSRF prevention feature in Apollo Server 3.7.  This feature successfully protects against CSRF even if you have manually integrated your AS3.7 server with `graphql-upload`. However, this feature is not available for Apollo Server 2.\n\n### Patches\nIf you are using Apollo Server 2 and do *not* actually use uploads in your schema (ie, the `Upload` scalar is not used as the argument to any field or in any input object definition, and you do not specify `uploads` to `new ApolloServer`), then upgrading to Apollo Server 2.25.4 will automatically disable `graphql-upload` in your server.  This will fix the CSRF mutation vulnerability.\n\nUpgrading to v2.25.4 does still leave your server vulnerable to non-mutation CSRF attacks such as timing attacks against query operations. To protect yourself against these potentially lower impact CSRF attack, we encourage upgrading to Apollo Server v3.7 and enabling CSRF prevention. See [the Apollo Server 3 migration guide](https://www.apollographql.com/docs/apollo-server/migration/) and the [CSRF prevention docs](https://www.apollographql.com/docs/apollo-server/security/cors/#preventing-cross-site-request-forgery-csrf) for details.\n\nIf you are actively using the uploads feature with Apollo Server 2, then upgrading to v2.25.4 will not disable the feature and you will still be vulnerable. You should instead upgrade to v3.7 and enable the CSRF prevention feature.\n\nIf you are manually integrating the `graphql-upload` package with any version of Apollo Server (or any Node GraphQL server) and need to continue using the feature, then you must enable some sort of CSRF prevention feature to fix this vulnerability. We recommend the CSRF prevention feature in Apollo Server 3.7.\n\n### Workarounds\nInstead of upgrading your Apollo Server 2 server, you can specify `uploads: false` to `new ApolloServer` to disable the `graphql-upload` integration and protect against CSRF mutations. (Only do this if you do not actually use the uploads feature in your server!) This will still leave your server vulnerable to non-mutation CSRF attacks such as timing attacks against query operations; you need to upgrade to v3.7 and enable CSRF prevention to protect against these attacks.\n\n### Related work\n- [PR adding a Security section to the GraphQL multipart request spec](https://github.com/jaydenseric/graphql-multipart-request-spec/pull/64)",
  "id": "GHSA-2p3c-p3qw-69r4",
  "modified": "2023-07-31T20:39:03Z",
  "published": "2022-10-12T14:15:48Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/apollographql/apollo-server/security/advisories/GHSA-2p3c-p3qw-69r4"
    },
    {
      "type": "WEB",
      "url": "https://github.com/jaydenseric/graphql-multipart-request-spec/pull/64"
    },
    {
      "type": "WEB",
      "url": "https://github.com/apollographql/apollo-server/commit/82d44985ddca8e61557957d67f41e9c1a705a5ca"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/apollographql/apollo-server"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [],
  "summary": "The graphql-upload library included in Apollo Server 2 is vulnerable to CSRF mutations"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.


Loading…

Loading…

Loading…

Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Loading…

Detection rules are retrieved from Rulezet.

Loading…

Loading…

Loading…