feat(security): enhance file path validation and implement non-root D…

[taraka-vishnumolakala]

Enhance file path validation and implement non-root Docker user

• Validate resolved full file paths including workspace boundaries in SecureFileStore
• Resolve paths before validation in readFile and writeFile operations
• Run Docker container as non-root flowise user (uid/gid 1001)
• Apply proper file ownership and permissions for application files

Prevents path traversal attacks and follows container security best practices

[gemini-code-assist]

Summary of Changes

Hello @taraka-vishnumolakala, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request significantly bolsters the application's security posture by addressing two critical areas: preventing path traversal vulnerabilities and adhering to container security best practices. It ensures that file operations are rigorously validated against potential malicious inputs and that the Docker environment operates with minimal necessary privileges, thereby reducing the attack surface.

Highlights

• Enhanced File Path Validation: The SecureFileStore now resolves the full file path before performing validation checks in readFile and writeFile operations. This ensures that all path components, including those that might attempt to traverse outside the intended workspace, are properly evaluated against security rules.
• Non-Root Docker User Implementation: The Dockerfile has been updated to create and run the container as a dedicated non-root user named flowise (uid/gid 1001). This change significantly reduces the potential impact of security vulnerabilities by limiting the container's privileges.
• Proper File Ownership and Permissions: Application files within the Docker container are now owned by the flowise user and group. Additionally, the chromium-browser executable has been granted appropriate read and execute permissions for the flowise group, ensuring functionality while maintaining least privilege.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This pull request introduces significant security enhancements by running the Docker container as a non-root user and attempting to strengthen file path validation. The Dockerfile changes are well-implemented, and I've suggested a minor optimization to reduce image layers. However, the changes to SecureFileStore.ts for file path validation in readFile and writeFile introduce a critical bug. The new logic incorrectly validates resolved absolute paths, which will cause file operations to fail. I've provided comments with code suggestions to fix this issue while retaining the intended security improvements.

[HenryHengZJ]

@gemini-code-assist review

[gemini-code-assist]

Code Review

This pull request significantly enhances security by implementing more robust file path validation and adopting container security best practices like running as a non-root user. The changes are well-structured and address important security concerns. My review includes suggestions to further strengthen the Docker container security by ensuring correct file permissions and optimizing the image size, along with recommendations to refine the path validation logic to make it more precise and robust against bypasses.

[gemini-code-assist]

To prevent potential runtime permission errors, you should change the ownership of the application files to the node user before switching to it. This ensures that if the application needs to write files within its directory (for example, if a workspace is configured there), it will have the necessary permissions.

# Give the node user ownership of the application files
RUN chown -R node:node .

# Switch to non-root user (node user already exists in node:20-alpine)
USER node

[HenryHengZJ]

PR: #5479

[HenryHengZJ]

Vulnerabilities Fixed

1. System Binary Overwrite

• Attackers could use WriteFile tool to overwrite system executables like /usr/bin/chromium-browser

2. Environment Variable Manipulation

• Attackers could set PUPPETEER_EXECUTABLE_PATH=/workspace/evil.sh, create malicious script with WriteFile, then trigger execution through browser loaders

Changes

Enhanced Path Validation (validator.ts)

The improved version now has three layers of protection:

• Layer 1 - Absolute Path Detection (isUnsafeFilePath): Blocks any absolute paths
• Layer 2 - Workspace Boundaries (isWithinWorkspace): Ensures files are within the configured workspace
• Layer 3 - Sensitive Directory Detection (isSensitiveSystemPath): Now explicitly blocks system binary directories

Browser Loaders Protected (Puppeteer.ts, Playwright.ts)

• Validate browser executable paths before launch. isSafeBrowserExecutable() - whitelist-only validation for browser executables
• Only allow system-managed browser installations