🛡️ Sentinel: [CRITICAL] Fix missing file extension validation in presigned upload endpoint#150
Conversation
Co-authored-by: xb1g <70068561+xb1g@users.noreply.github.com>
|
👋 Jules, reporting for duty! I'm here to lend a hand with this pull request. When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down. I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job! For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with New to Jules? Learn more at jules.google/docs. For security, I will only act on instructions from the user who triggered this task. |
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
d337d82 to
1e8d358
Compare
|
Unable to deploy a commit from a private repository on your GitHub organization to the wachaa1319's projects team on Vercel, which is currently on the Hobby plan. In order to deploy, you can:
To read more about collaboration on Vercel, click here. |
There was a problem hiding this comment.
Pull request overview
This PR strengthens the /api/upload/presigned upload URL broker in the Next.js app by switching from ad-hoc checks to the shared validateFile utility, aiming to prevent dangerous uploads (e.g., executables / script payloads) via spoofed MIME types in presigned S3/B2 uploads.
Changes:
- Replaced inline
fileName/fileType/fileSizevalidation inapp/api/upload/presigned/route.tswith sharedvalidateFile+ centralized allowlists/limits. - Added a new Sentinel entry documenting the presigned upload validation vulnerability and the intended prevention approach.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 3 comments.
| File | Description |
|---|---|
| app/api/upload/presigned/route.ts | Routes presigned upload requests through centralized file validation rules before generating B2/S3 presigned URLs. |
| .jules/sentinel.md | Documents the vulnerability and prevention guidance for presigned upload validation. |
| // Use shared validation logic to enforce secure file types and extensions | ||
| const fileValidation = validateFile( | ||
| fileName || "", | ||
| fileSize || 0, | ||
| fileType || "", | ||
| allowedTypes, | ||
| MAX_FILE_SIZE | ||
| ); |
| // Use shared validation logic to enforce secure file types and extensions | ||
| const fileValidation = validateFile( | ||
| fileName || "", | ||
| fileSize || 0, | ||
| fileType || "", | ||
| allowedTypes, | ||
| MAX_FILE_SIZE |
| **Vulnerability:** User-controlled SVG strings (`avatar.svg_data`) were being injected directly into the DOM using `dangerouslySetInnerHTML`. An attacker could inject an SVG containing embedded malicious `<script>` tags or `onload` event handlers, leading to Stored Cross-Site Scripting (XSS). | ||
| **Learning:** Rendering raw SVGs inline is inherently dangerous. SVGs are essentially XML documents capable of embedding JavaScript. | ||
| **Prevention:** When you need to display user-provided SVGs and you don't need to manipulate their internal paths via CSS/JS, do not use `dangerouslySetInnerHTML`. Instead, render the SVG securely by encoding it as a data URI (`data:image/svg+xml;charset=utf-8,${encodeURIComponent(svgData)}`) and using it as the `src` attribute of a standard `<img>` tag. This forces the browser to treat the SVG strictly as an image, entirely disabling any embedded script execution. No newline at end of file | ||
| **Prevention:** When you need to display user-provided SVGs and you don't need to manipulate their internal paths via CSS/JS, do not use `dangerouslySetInnerHTML`. Instead, render the SVG securely by encoding it as a data URI (`data:image/svg+xml;charset=utf-8,${encodeURIComponent(svgData)}`) and using it as the `src` attribute of a standard `<img>` tag. This forces the browser to treat the SVG strictly as an image, entirely disabling any embedded script execution.## 2024-05-24 - File Extension Validation in Presigned URLs |
be0a653 to
8d7b089
Compare
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ❌ Deployment failed View logs |
web | 8d7b089 | May 11 2026, 06:33 PM |
🚨 Severity: CRITICAL
💡 Vulnerability: The
/api/upload/presignedendpoint generated Backblaze B2/S3 presigned URLs based strictly on the client-providedfileTypeMIME string, but did not validate the actualfileNameextension against known dangerous files (e.g.,.exe,.sh,.html). Because S3/B2 trust the client MIME type and Next.js CDN routing does not double-check files in transit, this could allow an attacker to upload an executable or XSS payload disguised as a valid MIME type.🎯 Impact: An attacker could execute arbitrary scripts (XSS) via uploaded
.htmlfiles, or trick users into downloading malicious executable binaries directly from the application's domain.🔧 Fix: Removed manual, inline string checks for file type and size. Integrated the centralized
validateFileutility from@/lib/constants/upload, mapping the request'suploadTypeto strict sets of permitted extensions and blocking all entries inDANGEROUS_EXTENSIONS.✅ Verification: Ensure tests pass via
pnpm test. Attempting to request a presigned URL with an.exefile name or spoofed MIME type will now correctly return a400 Bad Requestwith "File type not allowed for security reasons".PR created automatically by Jules for task 17489820446762992084 started by @xb1g