Skip to content

Latest commit

 

History

History
283 lines (216 loc) · 24.5 KB

SECURITY.md

File metadata and controls

283 lines (216 loc) · 24.5 KB

Security Policy (עברית)

🌐 Languages: 🇺🇸 English · 🇪🇹 am · 🇸🇦 ar · 🇦🇿 az · 🇧🇬 bg · 🇧🇩 bn · 🇧🇦 bs · 🇨🇿 cs · 🇩🇰 da · 🇩🇪 de · 🇬🇷 el · 🇪🇸 es · 🇪🇪 et · 🇮🇷 fa · 🇫🇮 fi · 🇫🇷 fr · 🇮🇪 ga · 🇮🇳 gu · 🇳🇬 ha · 🇮🇳 hi · 🇭🇷 hr · 🇭🇺 hu · 🇦🇲 hy · 🇮🇩 id · 🇳🇬 ig · 🇮🇹 it · 🇯🇵 ja · 🇬🇪 ka · 🇰🇭 km · 🇮🇳 kn · 🇰🇷 ko · 🇱🇹 lt · 🇱🇻 lv · 🇮🇳 ml · 🇮🇳 mr · 🇲🇾 ms · 🇲🇹 mt · 🇲🇲 my · 🇳🇵 ne · 🇳🇱 nl · 🇳🇴 no · 🇮🇳 or · 🇮🇳 pa · 🇵🇭 phi · 🇵🇱 pl · 🇵🇹 pt · 🇧🇷 pt-BR · 🇷🇴 ro · 🇷🇺 ru · 🇱🇰 si · 🇸🇰 sk · 🇸🇮 sl · 🇷🇸 sr · 🇸🇪 sv · 🇰🇪 sw · 🇮🇳 ta · 🇮🇳 te · 🇹🇭 th · 🇹🇷 tr · 🇺🇦 uk-UA · 🇵🇰 ur · 🇺🇿 uz · 🇻🇳 vi · 🇳🇬 yo · 🇨🇳 zh-CN · 🇹🇼 zh-TW


דיווח על פגיעויות

אם גיליתם פגיעות אבטחה ב-OmniRoute, אנא דווחו עליה באופן אחראי:

  1. אל תפתחו דיווח ציבורי ב-GitHub
  2. השתמשו ב-GitHub Security Advisories
  3. כללו: תיאור, שלבים לשחזור והשפעה אפשרית

לוח זמנים לתגובה

שלב יעד
אישור קבלה 48 שעות
מיון והערכה 5 ימי עסקים
פרסום תיקון 14 ימי עסקים (לבעיה קריטית)

גרסאות נתמכות

גרסה מצב תמיכה
3.9.x 🗓️ מתוכננת — קו LTS (stable/v3), ראו להלן
3.8.x ✅ פעילה
3.7.x ✅ אבטחה
< 3.7.0 ❌ אינה נתמכת

חלון התמיכה של LTS ‏(v3.9.x)

לאחר 3.8.59, הגרסה הבאה היא 3.9.0, שפותחת את קו התמיכה ארוכת הטווח בענף stable/v3 (ראו ROADMAP.md ← "שלב 3 — v3.9.0 LTS").

  • מה מקבל stable/v3: תיקוני באגים, תיקוני אבטחה ועדכוני ספקים. תכונות חדשות מגיעות לערוץ v4; קו ה-LTS נותן עדיפות ליציבות. npm install omniroute (ה-dist-tag בשם latest) נשאר ב-v3 לאורך כל מחזור v4.
  • משך החלון: stable/v3 מקבל תיקוני אבטחה ותיקונים לרגרסיות קריטיות במשך 12 חודשים לאחר השקת 3.9.0, או עד 90 יום לאחר פרסום v4.0.0 בתור latest — לפי המאוחר מביניהם. תאריך הסיום שיתקבל מתועד בהערות המהדורה של 3.9.0 ובקובץ ROADMAP.md בעת ההשקה.
  • דיווח על פגיעות בקו ה-LTS: דרך אותו ערוץ כמו בכל גרסה אחרת — דיווח אבטחה פרטי ב-GitHub, ולעולם לא דיווח פומבי. ציינו איזו גרסה בדקתם (לדוגמה 3.9.2); התיקונים נכנסים אל stable/v3 ומועברים קדימה אל v4.
  • בסיס האבטחה בעת השקת ה-LTS: מצב הסורק שנמדד, הגנת הנתיבים והוכחות פרטי הגישה הציבוריים מתועדים בקובץ docs/security/LTS_SECURITY_BASELINE.md.

ארכיטקטורת אבטחה

OmniRoute מממש מודל אבטחה רב-שכבתי:

בקשה → CORS → תהליך Authz (סיווג → מדיניות → אכיפה)
       → מנגנוני הגנה (מסכת PII, הזרקת הנחיות, גשר ראייה)
       → מגביל קצב → מפסק זרם → תקופת צינון → חסימת מודל → ספק

🔐 אימות והרשאה

תכונה מימוש
כניסה ללוח הבקרה אימות מבוסס סיסמה באמצעות אסימוני JWT (קובצי Cookie מסוג HttpOnly)
אימות מפתח API מפתחות חתומים ב-HMAC עם אימות CRC
OAuth 2.0 + PKCE OAuth ייעודי לספק בדפדפן/במכשיר משתמש ב-PKCE כאשר הדבר נתמך; אישורי Devin המיועדים לייבוא בלבד מטופלים בנפרד.
רענון אסימון רענון אוטומטי של אסימון OAuth לפני תפוגתו
קובצי Cookie מאובטחים AUTH_COOKIE_SECURE=true עבור סביבות HTTPS
תהליך Authz סיווג נתיבים (PUBLIC / CLIENT_API / MANAGEMENT) — ראו docs/architecture/AUTHZ_GUIDE.md
רמות הגנת נתיבים מודל בן 3 רמות עבור נתיבי ניהול (LOCAL_ONLY / ALWAYS_PROTECTED / MANAGEMENT) — ראו docs/security/ROUTE_GUARD_TIERS.md
MCP בהיקף ניהול גישה מרוחקת אל /api/mcp/* מוגבלת באמצעות מפתחות API בעלי היקף manage; הנתיב /api/cli-tools/runtime/* נשאר מוגבל בקפדנות ל-loopback. ראו ROUTE_GUARD_TIERS
היקפי MCP 32 היקפים פרטניים (read:health, write:combos, execute:completions וכו') — ראו docs/frameworks/MCP-SERVER.md

🛡️ הצפנה במצב מנוחה

כל הנתונים הרגישים המאוחסנים ב-SQLite מוצפנים באמצעות AES-256-GCM עם גזירת מפתח באמצעות scrypt:

  • מפתחות API, אסימוני גישה, אסימוני רענון ואסימוני ID
  • פורמט בעל גרסאות: enc:v1:<iv>:<ciphertext>:<authTag>
  • מצב העברה ישירה (טקסט גלוי) כאשר STORAGE_ENCRYPTION_KEY אינו מוגדר
# יצירת מפתח הצפנה:
STORAGE_ENCRYPTION_KEY=$(openssl rand -hex 32)

🛡️ תשתית מנגנוני הגנה

OmniRoute כולל מאגר מנגנוני הגנה התומך בטעינה מחדש בזמן אמת (src/lib/guardrails/), ובו 3 מנגנוני הגנה מובנים המסודרים לפי עדיפות:

מנגנון הגנה עדיפות מטרה
vision-bridge 5 מגשר בין מודלים ללא יכולות ראייה לבין תיאורים המודעים לתמונות; הגנת SSRF עבור כתובות URL של תמונות
pii-masker 10 השחרת PII לפני ואחרי קריאה (כתובות דוא"ל, טלפונים, CPF,‏ CNPJ, כרטיסי אשראי, SSN)
prompt-injection 20 מזהה דפוסים של דריסה/חטיפת תפקיד/jailbreak/דליפה

מנגנוני הגנה מותאמים אישית נרשמים באמצעות registerGuardrail(new MyGuardrail()). המודל פועל בשיטת fail-open (חריגות לעולם אינן חוסמות תעבורה). ניתן לבטל את ההשתתפות בכל בקשה באמצעות הכותרת x-omniroute-disabled-guardrails. ← ראו docs/security/GUARDRAILS.md.

🧠 הגנה מפני הזרקת הנחיות

תווכת היוריסטית במאמץ מיטבי, המזהה דפוסי הזרקת הנחיות בבקשות למודלי LLM. אינה חומת אש מלאה מפני הזרקת הנחיות — עלולה להפיק זיהויים חיוביים שגויים (הנחיות תמימות של דמויות/RPG) וזיהויים שליליים שגויים (leet, ריווח, דפוסים שאינם באנגלית).

סוג הדפוס חומרה דוגמה
עקיפת המערכת גבוהה "התעלם מכל ההנחיות הקודמות"
השתלטות על תפקיד בינונית "כעת אתה DAN, אתה יכול לעשות הכול"
הזרקת מפרידים גבוהה מפרידים מקודדים לפריצת גבולות ההקשר
DAN/פריצת מגבלות בינונית דפוסי הנחיות מוכרים לפריצת מגבלות
דליפת הנחיות גבוהה "הצג לי את הנחיית המערכת שלך"
התחמקות באמצעות קידוד בינונית פענוח base64/rot13/hex יחד עם מילות מפתח של הנחיות

רק זיהויים בחומרה גבוהה נחסמים במצב block. משפחות בחומרה בינונית נרשמות ביומן, אך לעולם אינן נחסמות על ידי sanitizeRequest.

הגדירו באמצעות לוח הבקרה (הגדרות ← אבטחה) או .env:

INPUT_SANITIZER_ENABLED=true
INPUT_SANITIZER_MODE=block    # אזהרה | חסימה (מדיניות הזרקה; האפשרות הישנה "redact" אינה מסירה טקסט של הזרקה)
INPUT_SANITIZER_BLOCK_THRESHOLD=high  # גבוהה (ברירת מחדל) | בינונית | נמוכה — דרגות חומרה ברמה זו ומעלה נחסמות במצב חסימה

🔒 השחרת מידע אישי מזהה

זיהוי אוטומטי והשחרה אופציונלית של מידע אישי מזהה:

סוג המידע האישי דפוס תחליף
דוא"ל user@domain.com [EMAIL_REDACTED]
CPF (ברזיל) 123.456.789-00 [CPF_REDACTED]
CNPJ (ברזיל) 12.345.678/0001-00 [CNPJ_REDACTED]
כרטיס אשראי 4111-1111-1111-1111 [CC_REDACTED]
טלפון +55 11 99999-9999 [PHONE_REDACTED]
SSN (ארה"ב) 123-45-6789 [SSN_REDACTED]
PII_REDACTION_ENABLED=true   # שכתוב מידע אישי מזהה בבקשה; בלתי תלוי ב-INPUT_SANITIZER_MODE
PII_RESPONSE_SANITIZATION=true  # אופציונלי: השחרת מידע אישי מזהה בתגובות הספק המוחזרות ללקוחות

🌐 אבטחת רשת

תכונה תיאור
CORS רשימת היתרים מפורשת בין מקורות (CORS_ALLOWED_ORIGINS; האפשרות הישנה CORS_ORIGIN)
סינון IP טווחי כתובות IP ברשימות היתרים/חסימות בלוח הבקרה
הגבלת קצב מגבלות קצב לכל ספק עם השהיה אוטומטית
מניעת עומס מתפרץ Mutex + נעילה לכל חיבור מונעים שרשרת שגיאות 502
טביעת אצבע של TLS התחזות לטביעת אצבע של TLS דמוית דפדפן לצמצום זיהוי כבוט
טביעת אצבע של CLI סדר כותרות/גוף ייחודי לכל ספק, התואם לחתימות CLI מקוריות

🔌 עמידות וזמינות

תכונה תיאור
מפסק זרם 3 מצבים (סגור ← פתוח ← פתוח למחצה) לכל ספק, עם התמדה ב-SQLite
אידמפוטנטיות בקשות חלון ביטול כפילויות של 5 שניות לבקשות זהות
השהיה מעריכית ניסיון חוזר אוטומטי עם השהיות הולכות וגדלות
לוח בקרת תקינות ניטור תקינות ספקים בזמן אמת

📋 תאימות

תכונה תיאור
שמירת יומנים ניקוי אוטומטי לאחר CALL_LOG_RETENTION_DAYS
ביטול רישום ביומן הדגל noLog לכל מפתח API משבית את רישום הבקשות ביומן
יומן ביקורת פעולות ניהוליות מתועדות בטבלה audit_log
ביקורת MCP רישום ביקורת המבוסס על SQLite לכל הקריאות לכלי MCP
אימות Zod כל קלטי ה-API מאומתים באמצעות סכמות Zod v4 בעת טעינת המודול

משתני סביבה נדרשים

יש להגדיר את כל הסודות לפני הפעלת השרת. השרת ייכשל מיד אם הם חסרים או חלשים.

# חובה — השרת לא יופעל בלעדיהם:
JWT_SECRET=$(openssl rand -base64 48)     # לפחות 32 תווים
API_KEY_SECRET=$(openssl rand -hex 32)    # לפחות 16 תווים

# מומלץ — מאפשר הצפנת נתונים במצב מנוחה:
STORAGE_ENCRYPTION_KEY=$(openssl rand -hex 32)

השרת דוחה באופן פעיל ערכים חלשים ומוכרים כמו changeme,‏ secret או password.


אבטחת Docker

  • השתמשו במשתמש שאינו root בסביבת ייצור
  • עגנו סודות כאמצעי אחסון לקריאה בלבד
  • לעולם אל תעתיקו קובצי .env לתמונות Docker
  • השתמשו ב-.dockerignore כדי להחריג קבצים רגישים
  • הגדירו AUTH_COOKIE_SECURE=true כאשר השרת נמצא מאחורי HTTPS
docker run -d \
  --name omniroute \
  --restart unless-stopped \
  --read-only \
  -p 20128:20128 \
  -v omniroute-data:/app/data \
  -e JWT_SECRET="$(openssl rand -base64 48)" \
  -e API_KEY_SECRET="$(openssl rand -hex 32)" \
  -e STORAGE_ENCRYPTION_KEY="$(openssl rand -hex 32)" \
  diegosouzapw/omniroute:latest

תלויות

  • הריצו את npm audit באופן קבוע (npm run audit:deps מכסה את main ואת electron)
  • הקפידו לעדכן את התלויות
  • הפרויקט משתמש ב-husky וב-lint-staged לבדיקות טרום-commit ‏(lint-staged + check-docs-sync + check:any-budget:t11)
  • תהליך ה-CI מריץ כללי אבטחה של ESLint בכל push ‏(no-eval,‏ no-implied-eval,‏ no-new-func = שגיאה)
  • קבועי ספקים מאומתים בעת טעינת המודול באמצעות Zod ‏(src/shared/validation/schemas.ts)
  • נעשה שימוש בספריות מאובטחות כברירת מחדל: dompurify / isomorphic-dompurify ‏(XSS),‏ jose ‏(JWT),‏ better-sqlite3 (ללא סיכון ל-SQLi הודות לשאילתות עם פרמטרים),‏ bcryptjs (גיבוב סיסמאות)

כללי אבטחה מחמירים

כלים וסוקרים אוכפים את הכללים הבאים:

  1. לעולם אל תבצעו commit לסודות — .env מוחרג באמצעות gitignore;‏ .env.example הוא התבנית (ללא ערכים מילוליים, הערות בלבד — ראו PUBLIC_CREDS.md להלן)
  2. לעולם אל תשתמשו ב-eval(), ב-new Function() או ב-eval מרומז — ESLint אוכף זאת
  3. לעולם אל תעקפו hooks של Husky ‏(--no-verify,‏ --no-gpg-sign) ללא אישור מפורש מהמפעיל
  4. לעולם אל תכתבו SQL גולמי בנתיבים — עברו תמיד דרך src/lib/db/ (עם פרמטרים)
  5. אמתו תמיד קלט באמצעות Zod — src/shared/validation/schemas.ts
  6. חטאו תמיד כותרות upstream — רשימת החסימה נמצאת ב-src/shared/constants/upstreamHeaders.ts
  7. הצפינו פרטי גישה במצב מנוחה — AES-256-GCM באמצעות src/lib/db/encryption.ts
  8. מזהי OAuth ציבוריים של upstream באמצעות resolvePublicCred() — לעולם אל תטמיעו ערכים מילוליים מסוג AIza… / GOCSPX-… / …apps.googleusercontent.com בקוד המקור. ראו docs/security/PUBLIC_CREDS.md.
  9. תגובות שגיאה באמצעות buildErrorBody() / sanitizeErrorMessage() — לעולם אל תכללו err.stack / err.message גולמיים בגופי תגובות HTTP / SSE / executor / MCP. ראו docs/security/ERROR_SANITIZATION.md.
  10. ערכי זמן ריצה של exec() / spawn() באמצעות האפשרות env — לעולם אל תשלבו נתיבים חיצוניים או ערכים שאינם מהימנים כמחרוזות בסקריפטים המועברים למעטפת. מקור לעיון: src/mitm/cert/install.ts::updateNssDatabases.
  11. העדיפו ספריות מאובטחות כברירת מחדל — ראו tldrsec/awesome-secure-defaults ‏(Helmet.js, DOMPurify, ssrf-req-filter, safe-regex, Google Tink). העדיפו אותן לפני שתפתחו פתרון משלכם.

ממצאי סורקי שרשרת האספקה (Socket.dev / Snyk / כלים דומים)

הערת תחולה: הקובץ socket.yml שבשורש המאגר מגדיר רק את projectIgnorePaths עבור הסריקה של Socket.dev בצד הרישום לאחר פרסום ארטיפקט ה-npm שפורסם — הוא אינו שער מיזוג CI/PR שנאכף. שום תהליך עבודה ב-.github/workflows, שום סקריפט ב-package.json ושום יעד Makefile אינם מפעילים את Socket.dev.

ארטיפקט ה-npm שפורסם עבור omniroute כולל את ה-build של Next.js עם output: "standalone", ולכן כל מטפל נתיב — לרבות יכולות מתועדות בעלות הרשאות מיוחדות (MITM, ייבוא Zed, Cloud Sync ומפקח שירותים מובנה) — נכלל בסופו של דבר במקטעים ממוזערים תחת .next/server/*.js. סורקי שרשרת אספקה היוריסטיים מתאימים לעיתים קרובות דפוסים במקטעים אלה לחתימות של תוכנות זדוניות.

תצורת הסורק שבה אנו משתמשים נמצאת ב-socket.yml בשורש המאגר (פורמט v2 של אפליקציית GitHub של Socket.dev — ראו https://docs.socket.dev/docs/socket-yml). היא מחריגה במפורש ספריות שאינן מופצות (tests/, _tasks/, _references/, _ideia/, _mono_repo/, docs/ וכו'), כך שהסורק מדווח רק על נתיבי קוד שמגיעים בפועל למשתמשי הגרסה שפורסמה — הסריקה עצמה מופעלת על ידי אפליקציית GitHub של Socket שקוראת את הקובץ הזה, ולא על ידי תהליך עבודה במאגר זה.

עבור כל קטגוריית ממצאים אנו מתחזקים הצהרת אימות של המתחזקים לכל ממצא:

  • docs/security/SOCKET_DEV_FINDINGS.md — מיפוי לכל ממצא: קובץ מקור ↔ מקטע שסומן ↔ התנהגות ↔ אמצעי מניעה שהוחל ב-v3.8.6.
  • בלוקי SECURITY-AUDITOR-NOTE: בקוד המקור בכל פונקציה שסומנה מפנים חזרה לאותו מסמך.

למשתמשים שתהליך העבודה שלהם אינו מאפשר להקל את ההתראה: בנו באמצעות OMNIROUTE_BUILD_PROFILE=minimal npm run build. פעולה זו מחליפה את ארבעת המודולים הרגישים בגדמים שמחזירים בזמן ריצה HTTP 503 עם feature-disabled, כך שנתיבי הקוד בעלי ההרשאות המיוחדות נעדרים פיזית מהחבילה. ראו docs/security/SOCKET_DEV_FINDINGS.md לקבלת מתכון הפרסום.

מקורות עזר