1. 項目概述從一次安全審計引發(fā)的深度思考最近在幫一個朋友的公司做內(nèi)部安全審計他們用Dify搭建了一個內(nèi)部的AI應(yīng)用開發(fā)平臺方便業(yè)務(wù)團(tuán)隊快速調(diào)用大模型能力。審計過程中我發(fā)現(xiàn)了一個讓我有點后背發(fā)涼的問題他們自認(rèn)為已經(jīng)配置好的API安全防護(hù)——跨域CORS、CSRF跨站請求偽造和速率限制Rate Limit——在實際測試中竟然存在多處配置疏漏導(dǎo)致防護(hù)幾乎形同虛設(shè)。更關(guān)鍵的是他們完全忽略了內(nèi)容安全策略CSP這最后一道重要的防線。這讓我意識到對于Dify這類新興的、功能強大的AI應(yīng)用平臺很多團(tuán)隊在快速上業(yè)務(wù)的同時很容易忽視其作為Web應(yīng)用本身的基礎(chǔ)安全配置。大家可能更關(guān)注模型效果、工作流設(shè)計但部署在公網(wǎng)或內(nèi)網(wǎng)敏感環(huán)境的Dify實例其API網(wǎng)關(guān)就是攻擊者眼中的“肥肉”。一次成功的CSRF攻擊可能導(dǎo)致知識庫被惡意篡改一個未受控的跨域配置可能泄露敏感應(yīng)用數(shù)據(jù)而缺失的速率限制則會讓API成為DDoS的幫兇。因此我決定結(jié)合這次實戰(zhàn)審計的經(jīng)驗整理一份針對Dify的、可落地的企業(yè)級安全加固清單。這份清單不僅會詳細(xì)拆解CORS、CSRF、Rate Limit的正確配置姿勢避免常見的“配置了但沒完全生效”的坑更重要的是我會分享一個自己寫的CSP策略生成器腳本。這個腳本能幫你自動化分析并生成最適合你Dify實例的CSP策略而不是簡單地從網(wǎng)上抄一段可能根本不適用的配置。安全不是 checklist 上的勾選而是持續(xù)的過程希望這份從實戰(zhàn)中來的清單能幫你堵上那些容易被忽略的漏洞。2. 三重防護(hù)失效的典型場景與根因分析在深入配置之前我們必須先搞清楚為什么明明配了防護(hù)卻會失效。這往往不是Dify本身的問題而是配置理解和實踐上的偏差。2.1 跨域CORS配置的“寬松陷阱”Dify 的后端 API 默認(rèn)可能只允許同源訪問。為了讓前端可能部署在不同域名或端口能正常調(diào)用我們必須配置 CORS。常見的失效場景是配置得過于寬松。場景復(fù)現(xiàn) 開發(fā)者在docker-compose.yml或環(huán)境變量中設(shè)置了CORS_ALLOW_ORIGINS*或者在前端 Nginx 配置中直接添加了add_header Access-Control-Allow-Origin *;。這確實解決了前端的跨域報錯但也意味著任何網(wǎng)站都可以通過瀏覽器腳本JavaScript向你的 Dify API 發(fā)起請求并讀取響應(yīng)。如果API接口涉及敏感信息如知識庫列表、應(yīng)用配置這就造成了信息泄露。根因分析通配符*的濫用Access-Control-Allow-Origin: *是最大的風(fēng)險源。它僅在接口完全不涉及用戶憑證Cookies, Authorization Header時勉強可用。但Dify的認(rèn)證接口通常需要攜帶Token此時瀏覽器會拒絕通配符配置下的 credentialed 請求反而可能導(dǎo)致前端功能異常迫使開發(fā)者轉(zhuǎn)向更不安全的配置。憑證Credentials配置缺失當(dāng)你的前端需要發(fā)送認(rèn)證信息如通過withCredentials: true或自動攜帶的 Cookies時服務(wù)端除了指定具體的Origin還必須設(shè)置Access-Control-Allow-Credentials: true。很多配置只改了前者忘了后者導(dǎo)致認(rèn)證請求失敗。預(yù)檢Preflight請求處理不當(dāng)對于非簡單請求如 Content-Type 為application/json的 POST 請求瀏覽器會先發(fā)一個OPTIONS方法的預(yù)檢請求。如果后端沒有正確處理OPTIONS請求或者沒有在預(yù)檢響應(yīng)的Access-Control-Allow-Methods和Access-Control-Allow-Headers中放行對應(yīng)的方法和頭信息實際請求也會被瀏覽器攔截。注意在生產(chǎn)環(huán)境中絕對不要使用*作為允許的源。應(yīng)該通過環(huán)境變量動態(tài)配置一個允許的源列表例如CORS_ALLOW_ORIGINShttps://ai.your-company.com,https://internal-portal.your-company.com。2.2 CSRF防護(hù)的“形同虛設(shè)”CSRF攻擊的原理是誘騙已登錄用戶在不知情的情況下向目標(biāo)網(wǎng)站發(fā)送惡意請求。Dify 的 Web 界面本身可能有一定的防護(hù)但其 API 接口是 CSRF 的重災(zāi)區(qū)。場景復(fù)現(xiàn) 攻擊者構(gòu)造一個惡意頁面其中包含一個自動提交的表單或一個自動發(fā)起的 AJAX 請求目標(biāo)指向https://your-dify.com/api/v1/applications/[app_id]/update更新應(yīng)用或/api/v1/conversations發(fā)起對話。由于用戶瀏覽器中已保存了 Dify 的登錄態(tài)Session Cookie 或 Token該請求會攜帶認(rèn)證信息并被服務(wù)器正常執(zhí)行從而在用戶無感知的情況下篡改應(yīng)用或進(jìn)行惡意對話。根因分析依賴瀏覽器同源策略的誤區(qū)很多人認(rèn)為配置了 CORS 就能防 CSRF這是錯誤的。CORS 限制的是跨域讀取響應(yīng)而 CSRF 攻擊往往不需要讀取響應(yīng)它只需要請求被成功發(fā)送并執(zhí)行。即使 CORS 阻止了前端 JavaScript 讀取響應(yīng)內(nèi)容這個修改數(shù)據(jù)的 POST 請求可能已經(jīng)執(zhí)行成功了。Token 驗證缺失或錯誤實現(xiàn)標(biāo)準(zhǔn)的 CSRF 防護(hù)是使用 CSRF Token。但問題在于API 專用 Token 的誤區(qū)如果前端使用 Bearer Token如 JWT放在Authorization頭中進(jìn)行認(rèn)證并且這個 Token 不是由 Cookie 自動攜帶的那么某種程度上可以避免基于 Cookie 的 CSRF。但是如果這個 Token 被存儲在localStorage或sessionStorage中惡意網(wǎng)站通過 XSS 漏洞依然可以竊取它。因此僅依賴 API Token 并不絕對安全。雙重提交 Cookie 模式未啟用更健壯的方式是啟用類似 Django 等框架的 CSRF 中間件要求所有狀態(tài)修改請求POST PUT DELETE PATCH必須攜帶一個特殊的 CSRF Token該 Token 同時存在于 Cookie 和請求體或 Header中服務(wù)器進(jìn)行比對。Dify 可能未默認(rèn)開啟或配置此功能。SameSite Cookie 屬性未設(shè)置對于使用 Cookie 進(jìn)行會話管理的部署沒有為會話 Cookie 設(shè)置SameSiteStrict或SameSiteLax屬性。SameSiteLax可以阻止大多數(shù)跨站的 POST 請求攜帶 Cookie是防御 CSRF 非常有效且簡單的一環(huán)。2.3 速率限制Rate Limit的“配置幻覺”速率限制是保護(hù) API 免遭濫用和暴力攻擊的關(guān)鍵。配置不當(dāng)會導(dǎo)致限制不生效或誤傷正常用戶。場景復(fù)現(xiàn)全局限流局部失控在 Nginx 層面配置了全局的limit_req但對POST /api/v1/completion-messages流式對話接口這樣消耗資源巨大的端點沒有設(shè)置更嚴(yán)格的獨立限制。攻擊者可以通過單個 IP 低頻率但持續(xù)地調(diào)用該接口耗盡后端計算資源。維度單一易于繞過僅通過 IP 地址限流。在企業(yè) NAT 環(huán)境下一個出口 IP 背后可能有成百上千的用戶導(dǎo)致無辜用戶被限制?；蛘吖粽呤褂么沓亍or 網(wǎng)絡(luò)輕松更換 IP使 IP 限流失效。關(guān)鍵管理接口未設(shè)限忘記對管理類 API如創(chuàng)建應(yīng)用、修改知識庫、用戶管理進(jìn)行速率限制。攻擊者一旦獲得一個低權(quán)限憑證可以通過腳本快速枚舉或破壞資源?！傲钆仆啊眳?shù)配置不合理設(shè)置了速率限制但burst突發(fā)容量參數(shù)過大或者nodelay參數(shù)未使用使得限制在短時間內(nèi)失去作用。根因分析 缺乏分層次、多維度的速率限制策略。有效的 Rate Limit 應(yīng)該結(jié)合 IP、用戶 ID、API Key 等多種標(biāo)識符并對不同業(yè)務(wù)重要性的接口設(shè)置不同的閾值。同時需要區(qū)分認(rèn)證前如登錄接口和認(rèn)證后的限流策略。3. 企業(yè)級安全加固實操清單下面我們逐項進(jìn)行加固并提供具體的配置示例。假設(shè)我們的 Dify 通過 Docker Compose 部署使用 Nginx 作為反向代理。3.1 精準(zhǔn)的跨域CORS配置目標(biāo)在確保前端正常工作的前提下將跨域權(quán)限收緊到最小范圍。1. 后端Dify 服務(wù)配置最佳實踐是通過環(huán)境變量控制。修改你的docker-compose.yml中api服務(wù)的環(huán)境變量部分。services: api: image: langgenius/dify-api:latest environment: # ... 其他配置 - CORS_ALLOW_ORIGINShttps://ai.your-company.com,https://portal.your-company.com # 明確列出允許的源用逗號分隔 - CORS_ALLOW_CREDENTIALStrue # 如果前端需要發(fā)送憑證必須設(shè)為 true - CORS_ALLOW_METHODSGET,POST,PUT,PATCH,DELETE,OPTIONS # 明確允許的方法 - CORS_ALLOW_HEADERSContent-Type,Authorization,X-CSRF-Token # 明確允許的請求頭 # ...2. 前端Web 服務(wù)配置如果你的 Dify Web 前端是獨立服務(wù)也需要確保它不會成為漏洞。但更多時候我們會在反向代理層統(tǒng)一處理 CORS。3. 反向代理Nginx層配置推薦在 Nginx 配置中處理 CORS 更為靈活和統(tǒng)一。在對應(yīng) Dify API 的location塊中配置。server { listen 443 ssl; server_name api.dify.your-company.com; location / { proxy_pass http://dify-api:5001; # 指向后端 API 服務(wù) # 核心 CORS 配置 if ($http_origin ~* (https://ai\.your-company\.com|https://portal\.your-company\.com)) { set $cors_origin $http_origin; } # 對于預(yù)檢請求直接返回 204 并添加 CORS 頭 if ($request_method OPTIONS) { add_header Access-Control-Allow-Origin $cors_origin always; add_header Access-Control-Allow-Methods GET, POST, OPTIONS, PUT, PATCH, DELETE always; add_header Access-Control-Allow-Headers DNT,User-Agent,X-Requested-With,If-Modified-Since,Cache-Control,Content-Type,Range,Authorization,X-CSRF-Token always; add_header Access-Control-Allow-Credentials true always; add_header Access-Control-Max-Age 1728000 always; # 緩存預(yù)檢結(jié)果20天 add_header Content-Type text/plain; charsetutf-8 always; add_header Content-Length 0 always; return 204; } # 對于正常請求添加 CORS 頭 add_header Access-Control-Allow-Origin $cors_origin always; add_header Access-Control-Allow-Credentials true always; add_header Access-Control-Expose-Headers Content-Length,Content-Range always; # ... 其他代理配置 } }實操心得使用 Nginx 的if指令進(jìn)行 Origin 校驗時要注意性能。如果允許的源很多可以考慮使用map指令或?qū)⑿ｒ炦壿嫹诺胶蠖藨?yīng)用。上述示例中我們通過變量$cors_origin來動態(tài)設(shè)置允許的源避免了寫死的*。always參數(shù)確保即使后端返回 4xx/5xx 錯誤CORS 頭也會被添加方便前端調(diào)試。3.2 多層防御的 CSRF 保護(hù)策略我們需要構(gòu)建一個縱深防御體系而不是依賴單一機制。1. 確保 Cookie 的 SameSite 屬性治本良方之一如果你使用 Cookie 進(jìn)行會話管理這是最簡單有效的第一步。在設(shè)置會話 Cookie 的服務(wù)端代碼或反向代理中配置。在 Nginx 中修改代理響應(yīng)頭如果后端返回的Set-Cookie沒有此屬性proxy_cookie_path / /; secure; HttpOnly; SameSiteLax;這會給所有通過此 location 代理設(shè)置的 Cookie 加上Secure; HttpOnly; SameSiteLax屬性。SameSiteLax能阻止大多數(shù)跨站的危險請求如 POST 表單自動攜帶 Cookie但允許從外部鏈接導(dǎo)航過來的 GET 請求攜帶 Cookie用戶體驗更好。2. 啟用并驗證 CSRF Token針對狀態(tài)修改請求這需要前后端配合。Dify 可能內(nèi)置了相關(guān)功能但需要確認(rèn)和啟用。后端檢查查閱 Dify 文檔確認(rèn)是否有CSRF_TRUSTED_ORIGINS、CSRF_COOKIE_SECURE等環(huán)境變量或配置項需要設(shè)置。確保所有非冪等的請求POST, PUT, PATCH, DELETE都經(jīng)過 CSRF Token 校驗中間件。前端適配如果 Dify 前端是 React/Vue 應(yīng)用它應(yīng)該能自動從 Cookie 中讀取 CSRF Token通常名為csrftoken或X-CSRFToken并在請求的 Header如X-CSRF-Token或表單字段中攜帶。你需要確保前端應(yīng)用正確配置了與后端的憑證交互。3. 為 API Token 的使用增加約束對于使用 Bearer Token 的 API 調(diào)用更常見于 Dify 的 API 接口雖然不受基于 Cookie 的 CSRF 影響但需防范 XSS 導(dǎo)致的 Token 泄露。設(shè)置較短的 Token 過期時間。提供 Token 吊銷機制。在反向代理層可以檢查Authorization頭是否存在于某些敏感的管理接口請求中但這屬于額外加固。4. 關(guān)鍵操作增加二次確認(rèn)或 MFA對于“刪除應(yīng)用”、“清空知識庫”等極高風(fēng)險操作應(yīng)在業(yè)務(wù)邏輯層增加二次密碼確認(rèn)或動態(tài)令牌MFA驗證這能從業(yè)務(wù)層面徹底杜絕 CSRF。3.3 立體化的速率限制Rate Limit方案在 Nginx 和 Dify 應(yīng)用層同時設(shè)置速率限制形成互補。1. Nginx 層限流基于 IP防御基礎(chǔ)攻擊在 Nginx 的http或server塊中定義限流區(qū)并在location中應(yīng)用。http { # 定義限流區(qū)。$binary_remote_addr 以二進(jìn)制形式存儲IP更省空間。 # zoneip_limit:10m 表示開辟一個10MB的內(nèi)存區(qū)名為ip_limit用于存儲IP狀態(tài)。 # rate10r/s 表示每秒10個請求。 limit_req_zone $binary_remote_addr zoneip_limit:10m rate10r/s; # 針對登錄接口設(shè)置更嚴(yán)格的限制防止密碼爆破 limit_req_zone $binary_remote_addr zonelogin_limit:10m rate2r/m; # 每分鐘2次 server { listen 443 ssl; server_name api.dify.your-company.com; # 通用API限流 location /api/ { limit_req zoneip_limit burst20 nodelay; # burst20 允許在超過 rate 后最多有20個請求排隊。 # nodelay 表示對于排隊中的請求不延遲處理立即處理但超過 burstrate 的請求會被拒絕。 limit_req_status 429; # 超過限制時返回 429 Too Many Requests而非默認(rèn)的503 proxy_pass http://dify-api:5001; # ... 其他代理配置 } # 對登錄接口應(yīng)用更嚴(yán)格的限制 location ~ ^/api/(auth|login) { limit_req zonelogin_limit burst3 nodelay; limit_req_status 429; proxy_pass http://dify-api:5001; } # 對高消耗的流式輸出接口可以單獨限制 location ~ ^/api/v1/completion-messages { # 假設(shè)我們允許每秒1次請求突發(fā)5個 limit_req zoneip_limit rate1r/s burst5 nodelay; limit_req_status 429; proxy_pass http://dify-api:5001; } } }2. 應(yīng)用層限流基于用戶/API Key更細(xì)粒度Nginx 的限流基于 IP不夠精確。Dify 應(yīng)該在其業(yè)務(wù)代碼中實現(xiàn)基于用戶 ID 或 API Key 的限流。你需要檢查 Dify 的配置項在環(huán)境變量或配置文件中尋找如RATE_LIMIT_ENABLED,RATE_LIMIT_PER_USER,RATE_LIMIT_PER_KEY等配置。通常格式可能是RATE_LIMIT100/hour或RATE_LIMIT_PER_KEY1000/day。重點確保為不同的端點設(shè)置不同的限制。例如對話接口的限制應(yīng)高于管理接口匿名用戶的限制應(yīng)遠(yuǎn)低于認(rèn)證用戶。3. 監(jiān)控與告警配置日志監(jiān)控當(dāng)出現(xiàn)大量 429 狀態(tài)碼時觸發(fā)告警。這可能是攻擊的跡象也可能是你的限流策略過于嚴(yán)格影響了正常業(yè)務(wù)需要調(diào)整。4. 終極防線內(nèi)容安全策略CSP與自動化腳本CSP 通過白名單機制告訴瀏覽器當(dāng)前頁面允許加載哪些來源的資源腳本、樣式、圖片、字體等能有效緩解 XSS 和數(shù)據(jù)注入攻擊。即使攻擊者成功注入了惡意腳本如果該腳本的來源不在白名單內(nèi)瀏覽器也不會執(zhí)行它。手動配置 CSP 的挑戰(zhàn) CSP 策略需要根據(jù)你實際使用的資源來定制。盲目復(fù)制網(wǎng)上策略會導(dǎo)致功能損壞比如第三方圖表庫不工作。策略過于寬松則失去安全意義。解決方案使用自動化腳本在“報告模式”下收集數(shù)據(jù)再生成策略。4.1 CSP 策略生成器腳本實戰(zhàn)我寫了一個 Python 腳本它通過以下步驟工作在你的 Dify 前端 Nginx 配置中臨時設(shè)置一個僅報告不攔截的 CSP 頭。你或你的團(tuán)隊在報告期內(nèi)如24小時正常使用 Dify 的所有功能。腳本分析 Nginx 日志中記錄的 CSP 違規(guī)報告提取出所有嘗試加載的資源來源。腳本根據(jù)分析結(jié)果生成一個建議的、收緊的 CSP 策略。步驟一部署報告模式 CSP在 Nginx 中配置 Dify 前端站點的 CSP 報告頭server { listen 443 ssl; server_name ai.your-company.com; location / { # 僅報告不阻止。default-src self 是基礎(chǔ)策略任何不符合的加載都會被記錄。 add_header Content-Security-Policy-Report-Only default-src self; script-src self unsafe-inline unsafe-eval; style-src self unsafe-inline; img-src self data: https:; font-src self; connect-src self https://api.dify.your-company.com; report-uri /csp-violation-report-endpoint; always; # 注意這里為了收集全面暫時允許了 unsafe-inline 和 unsafe-eval這是不安全的最終策略要去掉它們。 proxy_pass http://dify-web:3000; # ... 其他配置 } # 一個用于接收違規(guī)報告的內(nèi)部端點 location /csp-violation-report-endpoint { internal; # 標(biāo)記為內(nèi)部禁止外部直接訪問 access_log /var/log/nginx/csp-violations.log json; # 記錄到單獨日志格式為JSON return 204; # 只需返回空響應(yīng) } }重啟 Nginx 后所有 CSP 違規(guī)行為都會被記錄到/var/log/nginx/csp-violations.log而不會影響頁面功能。步驟二運行分析腳本在收集了足夠多的日志后確保覆蓋了所有功能頁面運行下面的 Python 腳本generate_csp.py。#!/usr/bin/env python3 Dify CSP 策略生成器 分析 Nginx 記錄的 CSP 違規(guī)報告日志生成建議的 CSP 策略。 使用方法python generate_csp.py /var/log/nginx/csp-violations.log import json import sys import re from collections import defaultdict from urllib.parse import urlparse def parse_log_file(log_path): 解析 JSON 格式的 CSP 違規(guī)日志。 返回一個字典鍵是 CSP 指令如 script-src值是該指令下出現(xiàn)的所有來源集合。 directives defaultdict(set) line_count 0 processed_count 0 try: with open(log_path, r) as f: for line in f: line_count 1 line line.strip() if not line: continue try: # 假設(shè)日志格式是 Nginx 的 json 格式CSP 報告在 request_body 字段 # 實際格式可能需要根據(jù)你的 Nginx 日志配置調(diào)整 log_entry json.loads(line) # 提取 CSP 報告。報告可能在 request_body 或 body 字段且本身是 JSON 字符串 report_str log_entry.get(request_body) or log_entry.get(body) if not report_str: continue report json.loads(report_str) csp_report report.get(csp-report) if not csp_report: continue violated_directive csp_report.get(violated-directive, ) blocked_uri csp_report.get(blocked-uri, ) # 簡化處理提取指令名稱如 script-src # 實際可能是 script-src-elem 或 style-src-attr 等 # 我們統(tǒng)一歸類到主指令 match re.match(r^([a-z]-src), violated_directive) if match: directive match.group(1) # 如 script-src, style-src else: directive violated_directive.split()[0] if in violated_directive else violated_directive # 處理 blocked-uri if blocked_uri in (inline, eval, wasm-unsafe-eval): # 這些是特殊關(guān)鍵字需要單獨處理 directives[directive].add(f{blocked_uri}) elif blocked_uri.startswith(data:): directives[directive].add(data:) elif blocked_uri.startswith(http://) or blocked_uri.startswith(https://): # 提取協(xié)議、域名和端口 parsed urlparse(blocked_uri) origin f{parsed.scheme}://{parsed.netloc} directives[directive].add(origin) elif blocked_uri.startswith(blob:): directives[directive].add(blob:) elif blocked_uri ! : # 忽略空的和 self 等 # 其他情況如 self或未知協(xié)議 directives[directive].add(blocked_uri) processed_count 1 except json.JSONDecodeError as e: print(f警告: 第 {line_count} 行 JSON 解析失敗: {e}, filesys.stderr) continue except KeyError as e: print(f警告: 第 {line_count} 行缺少關(guān)鍵字段: {e}, filesys.stderr) continue except FileNotFoundError: print(f錯誤: 日志文件未找到: {log_path}, filesys.stderr) sys.exit(1) print(f日志分析完成。共處理 {line_count} 行其中 {processed_count} 條有效 CSP 報告。, filesys.stderr) return directives def generate_csp_policy(directives_map): 根據(jù)分析結(jié)果生成 CSP 策略字符串。 策略會盡量收緊例如將多個同域名來源合并。 policy_parts [] # 定義指令的生成順序和默認(rèn)值 directive_order [ default-src, script-src, style-src, img-src, font-src, connect-src, frame-src, media-src, object-src, child-src, form-action, base-uri, report-uri, ] # 首先處理 default-src。如果存在則作為基礎(chǔ)。 # 通常我們建議 default-src 設(shè)為 self然后其他指令再具體化。 default_sources directives_map.get(default-src, set()) if none in default_sources: policy_parts.append(default-src none) else: base_sources {self} base_sources.update(default_sources - {unsafe-inline, unsafe-eval}) # 報告模式下可能包含這些最終策略要去掉 policy_parts.append(fdefault-src { .join(sorted(base_sources))}) # 處理其他指令 for directive in directive_order[1:]: # 跳過 default-src if directive report-uri: # report-uri 指令已廢棄推薦使用 report-to但兼容性考慮可以保留 # 這里我們生成一個報告端點 policy_parts.append(report-uri /csp-violation-report-endpoint) continue sources directives_map.get(directive.replace(-src, -src), set()) # 處理 script-src-elem 等變體 if not sources: # 如果沒有該指令的違規(guī)記錄且它不是 default-src通常可以省略瀏覽器會回退到 default-src。 # 但為了更安全我們可以顯式設(shè)置為 self 或根據(jù)需求設(shè)置。 # 例如object-src 和 child-src 通常建議設(shè)為 none if directive in [object-src, child-src]: policy_parts.append(f{directive} none) continue # 清理和優(yōu)化來源列表 filtered_sources set() for src in sources: if src in (unsafe-inline, unsafe-eval, wasm-unsafe-eval): # 這些是不安全的在最終策略中我們應(yīng)該極力避免。 # 腳本可以記錄下哪些功能依賴內(nèi)聯(lián)腳本以便后續(xù)重構(gòu)。 print(f警告: 策略依賴不安全指令 {directive}: {src}。請檢查相關(guān)功能并嘗試移除。, filesys.stderr) # 為了生成可工作的策略暫時保留但強烈建議注釋掉并尋找替代方案 filtered_sources.add(src) elif src data:: filtered_sources.add(data:) elif src blob:: filtered_sources.add(blob:) elif src.startswith(http): # 可以在這里做域名合并例如將同一域名的不同子域名合并 filtered_sources.add(src) else: filtered_sources.add(src) if filtered_sources: policy_parts.append(f{directive} { .join(sorted(filtered_sources))}) # 添加 upgrade-insecure-requests 和 block-all-mixed-content 以增強安全 policy_parts.append(upgrade-insecure-requests) policy_parts.append(block-all-mixed-content) return ; .join(policy_parts) if __name__ __main__: if len(sys.argv) ! 2: print(f用法: {sys.argv[0]} csp_violation_log_file, filesys.stderr) sys.exit(1) log_file sys.argv[1] directives parse_log_file(log_file) print(\n 分析發(fā)現(xiàn)的資源來源 ) for dir_name, sources in sorted(directives.items()): print(f{dir_name}:) for src in sorted(sources): print(f - {src}) print(\n 建議的 CSP 策略 (Content-Security-Policy 頭) ) csp_policy generate_csp_policy(directives) print(csp_policy) print(\n Nginx 配置示例 (替換之前的報告頭) ) print(fadd_header Content-Security-Policy \{csp_policy}\ always;) print(\n注意) print(1. 將此策略設(shè)置為攔截模式移除 -Report-Only 后綴。) print(2. 部署后密切監(jiān)控錯誤日志和 /csp-violation-report-endpoint 的日志確保沒有誤攔截正常功能。) print(3. 對于標(biāo)記為警告的 unsafe-inline/eval應(yīng)作為長期優(yōu)化目標(biāo)逐步消除其必要性。)步驟三應(yīng)用并驗證生成的 CSP運行腳本python3 generate_csp.py /var/log/nginx/csp-violations.log。腳本會輸出一個建議的 CSP 策略字符串。將 Nginx 配置中的Content-Security-Policy-Report-Only頭替換為Content-Security-Policy并使用生成的策略。重啟 Nginx使策略生效現(xiàn)在瀏覽器會真正攔截違規(guī)行為。至關(guān)重要在監(jiān)控下全功能回歸測試。繼續(xù)觀察csp-violations.log如果出現(xiàn)新的、合理的違規(guī)報告說明策略過嚴(yán)你需要手動調(diào)整策略將必要的來源添加進(jìn)去。這是一個迭代收緊的過程。實操心得CSP 策略的生成不是一勞永逸的。每當(dāng)你的 Dify 前端引入新的第三方庫如新的圖表組件、字體圖標(biāo)庫或修改了資源加載方式時都可能需要更新 CSP。將這個腳本和流程納入你的 CI/CD 流水線在每次前端有重大更新后在預(yù)發(fā)布環(huán)境重新收集報告并更新策略是保持安全性的好習(xí)慣。5. 部署后監(jiān)控與持續(xù)加固安全配置不是“設(shè)置并遺忘”的。部署上述所有加固措施后你必須建立監(jiān)控。Nginx 錯誤日志監(jiān)控重點關(guān)注429 Too Many Requests限流觸發(fā)和403 Forbidden可能由嚴(yán)格 CSP 引起錯誤。設(shè)置告警閾值。CSP 違規(guī)報告監(jiān)控定期檢查/var/log/nginx/csp-violations.log。持續(xù)的、來源不明的違規(guī)報告可能預(yù)示著潛在的 XSS 攻擊嘗試。應(yīng)用日志審計確保 Dify 的應(yīng)用日志記錄了重要的安全事件如登錄失敗、敏感操作API Key 創(chuàng)建、刪除。將這些日志接入你的 SIEM安全信息和事件管理系統(tǒng)。定期漏洞掃描與滲透測試每季度或每次重大升級后對 Dify 的公開接口進(jìn)行授權(quán)下的安全掃描和滲透測試主動發(fā)現(xiàn)新引入的漏洞或配置錯誤。依賴項更新密切關(guān)注 Dify 官方發(fā)布的安全更新并及時升級 Docker 鏡像。同時如果你自定義了前端也需要定期更新其 npm 依賴修復(fù)已知的前端庫漏洞。安全是一個動態(tài)的過程尤其是在 Dify 這樣快速迭代的平臺上。這份清單為你提供了一個堅實的起點但真正的安全源于持續(xù)的關(guān)注、嚴(yán)謹(jǐn)?shù)倪\維和不斷演進(jìn)的安全實踐。從今天起檢查你的 Dify 部署別再讓三重防護(hù)停留在“已配置”的假象里。