n8n-workflows 安全策略深度解析路径穿越修复、CORS 收紧、限流与重索引鉴权的源码级实现【免费下载链接】n8n-workflowsall of the workflows of n8n i could find (also from the site itself)项目地址: https://gitcode.com/GitHub_Trending/n8nworkflo/n8n-workflowsn8n-workflows 项目除了提供海量 n8n 工作流模板外还内置了一个 FastAPI 构建的文档 APIapi_server.py对外暴露工作流详情、下载与流程图等文件访问端点。本文基于仓库中的安全策略文档 SECURITY.md 及其对应源码实现完整拆解项目修复的三类漏洞路径穿越、CORS 错误配置、未鉴权重索引端点与新增的速率限制机制读者可以掌握每一道防线背后的代码逻辑、验证方式与生产部署检查清单。漏洞报告与披露流程安全策略文档首先明确了漏洞报告的处置原则发现项目中的安全漏洞时应通过邮件私下直接联系维护者不要为安全问题创建公开的 Issue。这一约定保证了漏洞在修复前不会成为公开的攻击入口。文档同时给出了已处理漏洞的时间线作为安全履历的公开记录日期问题状态修复版本2025 年 10 月路径穿越Issue #48已修复2.0.12025 年 11 月CORS 错误配置已修复2.0.12025 年 11 月未鉴权重索引端点已修复2.0.1其中路径穿越问题由社区贡献者通过 Issue #48 报告文档在致谢中公开了贡献者身份。这类披露时间线 致谢的做法对开源项目的安全信誉管理具有参考价值。修复一路径穿越漏洞Issue #48漏洞背景在修复之前API 服务器上的文件访问端点直接拼接用户传入的文件名参数在 Windows 系统下尤其容易受到路径穿越攻击——攻击者可以在 URL 中构造../序列使服务器读取workflows目录之外的任意文件如系统敏感文件。第一道防线validate_filename() 白名单校验修复的核心是 api_server.py 中的validate_filename()函数。它的防御思路是先解码、再黑名单拦截、最后白名单正则收口三层递进多轮 URL 解码循环最多 3 次调用urllib.parse.unquote()用于捕获嵌套编码的穿越尝试例如..%5c解码一次后变成..\\再编码一次则还原出..%2f这类双重编码变体。若解码过程抛出异常非法编码序列直接判定为不安全。危险字符黑名单对解码后的文件名逐一检查以下模式命中任意一项即拒绝父目录引用..、../、..\\路径分隔符\Windows 反斜杠、/Unix 正斜杠空字节\x00、换行符\n、\r~Home 目录、:盘符或流定位符Shell 重定向与通配符|、、、*、?变量展开与命令分隔符$、;、白名单正则收口只有形如^[a-zA-Z0-9_\-]\.json$的文件名纯字母、数字、连字符、下划线加.json扩展名才能通过额外再校验必须以.json结尾并拦截以/、\开头的绝对路径和C:这类盘符开头形式。第二道防线Path.resolve() relative_to() 纵深防御白名单校验之后端点在真正落盘取文件时还有一层目录归属验证。以详情端点 api_server.py 为例workflows_path Path(workflows).resolve() matching_file None for subdir in workflows_path.iterdir(): if subdir.is_dir(): target_file subdir / filename if target_file.exists() and target_file.is_file(): # Verify the file is actually within workflows directory try: target_file.resolve().relative_to(workflows_path) matching_file target_file break except ValueError: print(fSecurity: Blocked access to file outside workflows: {target_file}) continue代码先对workflows根目录调用resolve()得到真实绝对路径然后遍历其子目录寻找同名文件每找到一个候选文件都再次调用target_file.resolve().relative_to(workflows_path)——如果该文件经过符号链接解析后落在workflows目录之外relative_to()会抛出ValueError于是这条访问被记录日志并跳过。下载端点 api_server.py 在返回FileResponse之前还追加了最终一次归属校验越界即返回 HTTP 403 Access denied。这种文件名校验 路径归属验证的双层设计即使第一层出现遗漏第二层也能兜底拦截。应用范围与回归验证该校验被统一应用到全部三个文件访问端点均先校验、失败返回 400 Invalid filename format/api/workflows/{filename}详情api_server.py/api/workflows/{filename}/download下载api_server.py/api/workflows/{filename}/diagramMermaid 流程图api_server.py仓库提供了可执行的安全回归脚本 test_security.sh它向本地 8000 端口的/api/workflows/payload/download端点依次发送 10 种攻击载荷并断言响应码为 400 或 404declare -a attacks( ../api_server.py ../../etc/passwd ..%2F..%2Fapi_server.py ..%5C..%5Capi_server.py %2e%2e%2fapi_server.py ../../../../../../../etc/passwd ....//....//api_server.py ..;/api_server.py ..\api_server.py ~/.ssh/id_rsa )值得注意的是测试覆盖了 URL 编码%2F、%5C、%2e、....//过滤绕过变体、..;/分号注入和~Home 目录等典型手法——这些正是validate_filename()中黑名单模式一一对应拦截的对象。脚本最后还验证合法文件名.json结尾的常规工作流文件能正常以 200 下载确保加固没有误伤正常业务。修复二CORS 错误配置问题与修复修复之前API 的 CORS 配置为allow_origins[*]意味着任意网站的脚本都可以跨域调用该 API配合浏览器中登录态可能引发数据被任意第三方站点读取的风险。修复后的配置位于 api_server.py三处收紧同时落地ALLOWED_ORIGINS [ http://localhost:3000, http://localhost:8000, http://localhost:8080, # GitHub Pages 站点地址 # Render 社区部署地址 ] app.add_middleware( CORSMiddleware, allow_originsALLOWED_ORIGINS, # Security fix: Restrict origins allow_credentialsTrue, allow_methods[GET, POST], # Security fix: Only allow needed methods allow_headers[Content-Type, Authorization], # Security fix: Restrict headers )来源限制白名单只包含本地开发端口3000、8000、8080以及项目实际部署的 GitHub Pages 站点与社区 Render 部署地址完整值以上述源码中的ALLOWED_ORIGINS列表为准方法限制只放行GET和POST其余方法PUT、DELETE 等被浏览器预检直接拦截请求头限制只允许Content-Type和Authorization两个头收窄了跨域请求可携带的信息面。如何扩展允许来源如果你有自定义生产域名安全策略文档给出的做法是修改 api_server.py 中的ALLOWED_ORIGINS列表ALLOWED_ORIGINS [ http://localhost:3000, http://localhost:8000, https://your-domain.com, # Add your production domain ]要点是生产域名必须带https://协议前缀且只添加你实际托管前端页面的确切 Origin协议 域名 端口不含路径通配不要退回*通配符。修复三未鉴权重索引端点问题与修复/api/reindex会触发全库工作流重新索引属于重资源操作。修复前任何匿名访问者都能调用它等价于一个免费的 DoS 入口。修复后的实现见 api_server.py防御链按请求顺序依次为速率限制前置先按客户端 IP 做限流检查超限返回 429环境变量鉴权fail-closed 设计从环境变量读取ADMIN_TOKENexpected_token os.environ.get(ADMIN_TOKEN, None) if not expected_token: # If no token is configured, disable the endpoint for security raise HTTPException( status_code503, detailReindexing is disabled. Set ADMIN_TOKEN environment variable to enable., ) if admin_token ! expected_token: print(fSecurity: Unauthorized reindex attempt from {client_ip}) raise HTTPException(status_code401, detailInvalid authentication token)未配置ADMIN_TOKEN时端点直接返回503服务不可用即未配置即禁用避免留下一个无需鉴权就生效的开关请求需以查询参数admin_token携带令牌与ADMIN_TOKEN不一致返回401每次未授权尝试都会连同客户端 IP 打印到日志便于事后审计。后台执行鉴权通过后索引任务通过BackgroundTasks异步执行并立即返回 Reindexing started in background附带请求来源 IP避免长请求占用连接。源码注释中也坦诚注明生产环境应升级为 JWT、OAuth 等正式认证方案当前的环境变量令牌属于轻量过渡实现。速率限制机制作为新增的安全特性项目在 api_server.py 实现了一个基于滑动窗口的限流器rate_limit_storage defaultdict(list) MAX_REQUESTS_PER_MINUTE 60 # Configure as needed def check_rate_limit(client_ip: str) - bool: Check if client has exceeded rate limit. current_time time.time() # Clean old entries rate_limit_storage[client_ip] [ timestamp for timestamp in rate_limit_storage[client_ip] if current_time - timestamp 60 ] # Check rate limit if len(rate_limit_storage[client_ip]) MAX_REQUESTS_PER_MINUTE: return False # Add current request rate_limit_storage[client_ip].append(current_time) return True实现要点按客户端 IP 维护一个时间戳列表每次检查时先剔除 60 秒窗口外的旧记录再判断窗口内请求数是否达到上限默认每分钟 60 次超限的请求返回 HTTP429Rate limit exceeded. Please try again later.限流被应用到所有敏感端点三个文件访问端点详情、下载、diagram以及/api/reindex见 api_server.py有效抑制暴力枚举与 DoS 请求。需要说明的一处细节安全策略文档将MAX_REQUESTS_PER_MINUTE描述为可通过环境变量配置的可选参数默认 60而从当前仓库源码看该值实际是模块级常量api_server.py调整需直接修改代码这一点以源码为准。安全配置与生产部署环境变量安全策略文档给出的最小安全配置为# Required for reindex endpoint export ADMIN_TOKENyour-secure-random-token # Optional: Configure rate limiting (default: 60) # MAX_REQUESTS_PER_MINUTE60结合上文源码分析ADMIN_TOKEN是当前版本中真正被程序读取的环境变量未设置则重索引端点整体禁用MAX_REQUESTS_PER_MINUTE在文档中作为可选项列出实际修改方式见前文说明。部署安全检查清单文档为上线场景列出了八项检查清单逐条对照仓库实现情况设置强随机ADMIN_TOKEN环境变量启用重索引端点的前提按实际域名收紧 CORS 来源修改ALLOWED_ORIGINS全站 HTTPS仓库的 k8s/ingress.yaml 中生产 Ingress 通过 cert-manager 的letsencrypt-prod发行证书并设置了ssl-redirect: true与force-ssl-redirect: true注解强制跳转 HTTPSTLS 证书存于workflows-docs-tlsSecret边缘限流同一 Ingress 通过rate-limit-rps: 100注解在 Nginx 层增加了独立于应用层的限流每 IP 100 rps与应用内 60 次/分钟的窗口限流形成双层防护开发环境 Ingress 则叠加了 Basic Authauth-type: basic作为访问门槛防火墙规则、监控告警、令牌定期轮换、依赖保持更新、反向代理附加安全头——这些属于部署侧运维动作需由使用者在部署环境中落实。反向代理附加安全响应头文档建议在 Nginx/Apache 反向代理层追加以下响应头进一步收窄浏览器侧攻击面add_header X-Frame-Options SAMEORIGIN; add_header X-Content-Type-Options nosniff; add_header X-XSS-Protection 1; modeblock; add_header Content-Security-Policy default-src self; add_header Strict-Transport-Security max-age31536000; includeSubDomains;其中X-Frame-Options防点击劫持禁止被第三方页面 iframe 嵌套X-Content-Type-Options防 MIME 嗅探CSP 的default-src self把脚本等资源加载限制在自身来源内HSTS 则强制浏览器一年内在子域上只走 HTTPS。安全最佳实践文档同时给出五条日常安全准则敏感令牌与凭据绝不提交进仓库生产环境一律使用 HTTPSHTTP 仅限本地开发定期更新所有依赖以修复已知漏洞持续监控日志中的异常访问模式对工作流数据库做定期备份。依赖层面requirements.txt 对 FastAPI 0.109.0、uvicorn 0.27.0、Pydantic 2.5.3 等关键库做了精确版本锁定兼容 Python 3.9–3.12并在Authentication Security分组中纳入了 PyJWT 与 passlib生产部署使用 gunicorn 启动——精确锁版本正是依赖及时更新 可复现策略的一部分。仓库还提供了 trivy.yaml 作为 Trivy 扫描配置只报告 CRITICAL/HIGH 级漏洞、忽略无可用补丁的问题、跳过测试文件与文档目录、开启密钥扫描防止令牌误入库、跳过许可证扫描与定期更新依赖这条准则形成闭环。小结与源码级注意点n8n-workflows 的安全加固呈现出清晰的纵深防御结构validate_filename()白名单拦截绝大多数恶意输入resolve()/relative_to()目录归属验证兜底符号链接与路径拼接的边角情况CORS 三要素收紧隔离跨域访问面ADMIN_TOKENfail-closed 鉴权保护重操作端点滑动窗口限流压制暴力请求k8s 层再以 TLS 强制跳转与 rps 限流收口。配合 test_security.sh 的回归脚本与 trivy.yaml 的扫描策略这套机制在仓库内是自洽且可验证的。两点基于源码的提醒供部署者参考其一api_server.py 中 FastAPI 应用声明的版本字段为2.0.0而安全策略文档披露时间线标注的修复版本为 2.0.1核对补丁是否生效时建议以validate_filename()、ALLOWED_ORIGINS、ADMIN_TOKEN鉴权这三处代码是否存在为准其二api_server.py 的全局异常处理器会将异常信息文本写入 500 响应的detail字段从源码结构看这在公网部署时可能向调用方泄露内部错误细节建议在生产反向代理层对该字段做收敛或改写。【免费下载链接】n8n-workflowsall of the workflows of n8n i could find (also from the site itself)项目地址: https://gitcode.com/GitHub_Trending/n8nworkflo/n8n-workflows创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考