CVE-2024-56140: Bypass of CSRF Middleware in Astro
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.
Other sources
Astro is a web framework for content-driven websites. In affected versions a bug in Astro’s CSRF-protection middleware allows requests to bypass CSRF checks. When the security.checkOrigin configuration option is set to true, Astro middleware will perform a CSRF check. However, a vulnerability exists that can bypass this security. 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. Additionally, the Content-Type header is not required for a request. This issue has been addressed in version 4.16.17 and all users are advised to upgrade. There are no known workarounds for this vulnerability.
— NVD
Affected Software
Remediation
Event History
Frequently Asked Questions
What is the severity of CVE-2024-56140?
CVE-2024-56140 is considered a moderate severity vulnerability that affects CSRF protections in Astro's middleware.
How do I fix CVE-2024-56140?
To mitigate CVE-2024-56140, update your Astro package to version 4.16.17 or later.
What types of requests are affected by CVE-2024-56140?
CVE-2024-56140 allows certain HTTP requests to bypass CSRF checks if the middleware is improperly configured.
What conditions must be met for CVE-2024-56140 to occur?
CVE-2024-56140 occurs when the `security.checkOrigin` configuration option is set to true but is improperly handled.
Are all versions of Astro vulnerable to CVE-2024-56140?
No, only versions of Astro prior to 4.16.17 are vulnerable to CVE-2024-56140.