תקציר
הגילוי של CVE-2025-66478 בדצמבר 2025 מייצג נקודת מפנה קריטית עבור אבטחת יישומים מודרניים באינטרנט. מסגרות כמו Next.js מטשטשות את הגבול בין הלקוח לשרת באמצעות פעולות שרת, הם מציגים משטחי תקיפה חדשים שמודלים אבטחה מסורתיים אינם מצליחים לטפל בהם. פגיעות זו אינה פגם הזרקה פשוט; זוהי באג לוגי מתוחכם הנובע מפירוק סדרתי לא בטוח המאפשר זיהום אב טיפוס, אשר יכול להחמיר ל ביצוע קוד מרחוק (RCE) בתנאים ספציפיים.
מדריך מקיף זה חורג מההנחיות הבסיסיות. ננתח את הפגיעות ברמת זמן הריצה של JavaScript, נבחן את דפוסי הקוד המדויקים שיוצרים את הסיכון, נסביר מדוע הגנות היקפיות כמו WAF אינן יעילות, ונדגים כיצד אימות מבוסס AI המותאם להקשר, שפותח לראשונה על ידי Penligent, הכרחי כדי להבטיח את הפרדיגמה החדשה הזו.
החזית החדשה: פעולות שרת וסיכוני סידוריות
פעולות שרת Next.js ('השתמש בשרת') חוללו מהפכה בפיתוח full-stack בכך שאפשרו למפתחים להפעיל פונקציות בצד השרת ישירות מרכיבים בצד הלקוח. חוויה חלקה זו מתאפשרת הודות למנגנוני סידור סדרתי מורכבים, הפועלים מאחורי הקלעים ומארגנים נתונים — טפסים, אובייקטים וסגירות — מעבר לגבולות הרשת.
עם זאת, נוחות לעתים קרובות באה על חשבון האבטחה. CVE-2025-66478 חושף פגם מהותי באופן שבו Next.js טיפל בקלט לא מהימן במהלך תהליך ההידרציה הזה. המסגרת סמכה באופן מובלע על מבנה האובייקטים הנכנסים, מה שאפשר לתוקפים לתפעל את מאפייני האובייקטים הבסיסיים של JavaScript.
אנטומיה של הפגם: מזיהום אב טיפוס ועד RCE
בבסיסו, CVE-2025-66478 הוא זיהום אב טיפוס פגיעות מופעלת במהלך קישור נתוני הבקשה לארגומנטים של פעולת השרת.
המנגנון: מיזוג רקורסיבי לא בטוח
האופי הדינמי של JavaScript מאפשר לאובייקטים לרשת תכונות מהאב-טיפוס שלהם. האב-טיפוס השורשי הוא אובייקט.prototype. אם תוקף יכול לשנות את אב-הטיפוס הזה, כל אובייקט במופע היישום הפועל יירש את השינוי הזה.
הפגיעות מתעוררת כאשר פעולת שרת מקבלת מבני נתונים מורכבים (כגון JSON מקונן או מבנה נתונים שנוצר במיוחד). FormData) והמסגרת — או קוד המפתח בתוך הפעולה — מבצעת מיזוג או הקצאה רקורסיבית לא בטוחה.
וקטור ההתקפה:
תוקף שולח מטען שתוכנן לעבור את שרשרת האבטיפוס של האובייקט באמצעות מפתחות מאפיינים מיוחדים כמו פרוטו, קונסטרוקטור או אב טיפוס.
JSON
// מטען התקפה קונספטואלי שנשלח לשרת Action { "userUpdate": { "__proto__": { "isAdmin": true, "execPath": "/bin/sh" // גאדג'ט עבור RCE פוטנציאלי } } }
אם הלוגיקה בצד השרת ממזגת זאת בתמימות עדכון משתמש אובייקט לאובייקט משתמש קיים או לבלוק תצורה, ה- __proto__ המפתח אינו מפורש כשדה נתונים, אלא כהוראה לשנות את האב-טיפוס של האובייקט היעד.
הסלמה: שרשרת הגאדג'טים RCE
זיהום אב טיפוס הוא לעתים נדירות המטרה הסופית; הוא האמצעי המאפשר. עבור מהנדס אבטחה קשוח, השאלה הקריטית היא: "איך אני הופך זיהום לביצוע?"
לשם כך יש למצוא "גאדג'ט" — קטע קוד לגיטימי בתוך היישום או התלות שלו, המשתמש במאפיין מוגדר מראש באופן מסוכן. על ידי זיהום המאפיין הזה באופן גלובלי, התוקף שולט בהתנהגות הגאדג'ט.
דוגמה לתרחיש RCE ב-Node.js:
קחו לדוגמה תהליך backend שמפעיל מדי פעם תהליכים-בנים באמצעות child_process.spawn() או כלי עזר דומים. לעתים קרובות, כלי עזר אלה מקבלים אובייקט אפשרויות, שיכול לחפש מאפיינים כמו shell, env או execPath.
- זיהום: התוקף משתמש ב-CVE-2025-66478 בפעולת שרת כדי לזהם
Object.prototype.shellעם ערך כמו/bin/shאוcmd.exe. - הדק: מאוחר יותר, במקום אחר ביישום, פונקציה שאינה קשורה כלל קוראת
spawn('ls', ['-la'], {}). - ביצוע: מכיוון שאובייקט האפשרויות
{}יורש מהאב טיפוס המזוהם,להתרבותרואה{ shell: '/bin/sh' }. הפקודה מבוצעת כעת בתוך מעטפת, מה שמאפשר הזרקת פקודות באמצעות הארגומנטים.
מסלול ההסלמה הזה מדגיש מדוע CVE-2025-66478 מדורג כקריטי. הוא הופך שגיאה בטיפול בנתונים לפגיעה מלאה בשרת.
הדילמה של המפתח: דפוסי קוד פגיעים לעומת דפוסי קוד מאובטחים
זיהוי פגיעות זו מחייב חיפוש אחר "ריחות קוד" ספציפיים, שבהם קלט המשתמש זוכה לאמון מופרז מדי בפעולות אובייקט.
האנטי-תבנית (קוד פגיע)
הטעות הנפוצה ביותר היא המרה ישירה FormData או JSON לא מאומת לאובייקט ומעביר אותו לפונקציות המבצעות מיזוגים עמוקים או פעולות מסד נתונים המסתמכות על מבנה האובייקט.
JavaScript
// app/actions/user.js 'use server'
import { db } from ‘@/lib/db’; // כלי מיזוג עמוק גנרי ולא מאובטח הנפוץ בבסיסי קוד import { deepMerge } from ‘@/utils/genericHelpers’;
ייצא פונקציה אסינכרונית updateProfileSettings(formData) { // סכנה: המרת FormData לא אמין ישירות לאובייקט const rawInput = Object.fromEntries(formData);
// נניח ש-getCurrentConfig() מחזיר אובייקט תצורה בסיסי. const currentConfig = await db.config.findFirst(); // גורם לפגיעות: // אם deepMerge אינו חוסם במפורש את __proto__, // תוקף יכול לזהם את סוג אובייקט התצורה הבסיסי. const newConfig = deepMerge({}, currentConfig, rawInput);
// התצורה המזוהמת נשמרת או משמשת בדרכים מסוכנות await db.user.update({ where: { id: rawInput.userId }, data: { settings: newConfig } });
}`
הדפוס הבטוח (מגן הזוד)
ההגנה היחידה האיתנה מפני התקפות של הקצאה המונית וזיהום אב טיפוס היא אימות קפדני, מבוסס סכימה. ספריות כמו זוד לשמש כחומת אש עבור לוגיקת היישום שלך, ליצור רשימת היתרים של מאפיינים מותרים ולהסיר את כל השאר.
JavaScript
// app/actions/user.js 'use server'
import { z } מ-‘zod’; import { db } מ-‘@/lib/db’;
// הגנה: הגדר סכימה קפדנית. רק המפתחות האלה יעברו. // כל 'פרוטו' או מפתחות לא ידועים מוסרים אוטומטית. const ProfileSettingsSchema = z.object({ userId: z.string().uuid(), theme: z.enum([‘light’, ‘dark’, ‘system’]), notificationsEnabled: z.boolean(), metadata: z.object({ bio: z.string().max(280).optional(), website: z.string().url().optional() }).strict() // .strict() אוסר על מפתחות לא ידועים באובייקטים מקוננים });
export async function updateProfileSettings(formData) { // שלב 1: ניתוח ואימות // safeParse מחזיר אובייקט מוקלד ונקי אם הפעולה הצליחה, או שגיאות. const parseResult = ProfileSettingsSchema.safeParse( Object.fromEntries(formData) );
if (!parseResult.success) { // טיפול אלגנטי בקלט שגוי מבלי לחשוף מבנים פנימיים console.error('האימות נכשל:', parseResult.error); throw new Error('נתוני בקשה לא חוקיים'); } // שלב 2: שימוש בנתונים המטוהרים // parseResult.data מכיל בוודאות רק מפתחות מוגדרים.
await db.user.update({ where: { id: parseResult.data.userId }, data: { theme: parseResult.data.theme, notifications: parseResult.data.notificationsEnabled, metadata: parseResult.data.metadata } });
}`
מדוע שכבות האבטחה המסורתיות נכשלות
ארגונים רבים מאמינים בטעות שההגנות ההיקפיות הקיימות שלהם יתפסו את CVE-2025-66478. הנחה זו מסוכנת.
עיוורון WAF ופרוטוקול הטיסה
חומות אש ליישומי אינטרנט (WAF) פועלות בדרך כלל על התאמת ביטויים רגולריים מול אלמנטים HTTP סטנדרטיים כמו פרמטרי URL וגופי JSON, ומחפשות SQLi (' או 1=1) או XSS (<script>) חתימות.
פעולות השרת של Next.js, לעומת זאת, מתקשרות באמצעות פרוטוקול טיסה—תערובת מורכבת של טקסט ונתונים בינאריים. מטען זדוני עשוי להיות מקונן עמוק בתוך בקשת multipart/form-data או להיות מסודר באופן שמטשטש את __proto__ מפתח מהתאמת מחרוזת פשוטה. WAFs שאינם מבינים באופן ספציפי את פורמט הסידוריות של Next.js יראו תעבורה תמימה.
הפער הסמנטי
יתר על כן, מטען כמו {"constructor": {"prototype": {"isAdmin": true}}} הוא JSON תקין מבחינה תחבירית. WAF אינו יכול לקבוע אם זו בקשה לגיטימית שנועדה לעדכן אובייקט תצורה מורכב, או שמדובר בהתקפה. לשם כך נדרש הבנה סמנטית של לוגיקת היישום, אשר חסרה בהיקפים.
אימות מתקדם: הגישה המונעת על ידי בינה מלאכותית עם Penligent
לאור המגבלות של ביקורת ידנית וכלים מסורתיים, נדרשת גישה חדשה. Penligent משתמש במנוע בדיקות חדירה מבוסס בינה מלאכותית, שנועד להבין את הקשר של היישום.
מעבר לניתוח סטטי: פוזינג רגיש להקשר
כלי בדיקת אבטחת יישומים סטטיים (SAST) מסורתיים מתקשים להתמודד עם האופי הדינמי של JavaScript ולעתים קרובות מסמנים יותר מדי תוצאות חיוביות כוזבות או מפספסים זרימות נתונים מורכבות החוצות את גבול פעולת השרת.
מנוע ה-AI של Penligent מנתח את עץ התחביר המופשט (AST) של היישום כדי לזהות:
- מקורות: פונקציות המסומנות ב-
'השתמש בשרת'. - כיורים: פעולות מסוכנות כמו מיזוג אובייקטים, כתיבה למסד נתונים או ביצוע פקודות.
- זרימת נתונים: הנתיב שעובר קלט לא מהימן מהמקור ועד היעד.
על ידי הבנת הקשר זה, Penligent מייצר מטעני פוזינג ממוקדים שתוכננו במיוחד לבדיקת זיהום אב טיפוס בנתיבי הנתונים שזוהו.
הוכחת תפיסה לא הרסנית (Safe PoC)
הוכחת קיומה של פגיעות מבלי לגרום לקריסת המערכת היא בעלת חשיבות עליונה. Penligent משתמשת בשיטת "Safe PoC" (הוכחת פגיעות בטוחה).
במקום לנסות לבצע RCE או לשבש את מצב היישום, הסוכן Penligent מנסה לזהם נכס זמני ותמים.
- פעולה: הסוכן שולח מטען לפעולת שרת:
{"__proto__": {"penligent_validation_flag_{unique_id}": true}}. - אימות: לאחר מכן, הסוכן מבצע בקשה נוספת לנקודת קצה אחרת ובודק אם הדגל המזהם הגלובלי מופיע בנתוני התגובה.
- תוצאה: אם הדגל קיים, הפגיעות מאושרת בוודאות של 100% וללא השפעה על העסק.
תובנה של Penligent: "בארכיטקטורת האינטרנט המודרנית, האבטחה חייבת לעבור מחסימה ברמת הרשת לאימות לוגי ברמת היישום. בינה מלאכותית היא הדרך היחידה הניתנת להרחבה כדי לגשר על הפער הזה."
רשימת הבדיקה הסופית לתיקון
צוותי DevSecOps וארכיטקטים נדרשים לנקוט בפעולה מיידית כדי לאבטח סביבות Next.js.
- תיקון מיידי: שדרג את כל מופעי Next.js ל- v15.0.4+ או v14.2.16+. התיקונים הרשמיים מכילים חיזוקים ברמת המסגרת כנגד סוגים מסוימים של הרעלת נכסים במהלך סידוריות.
- אכיפת אימות סכימה: לאמץ מדיניות של כל פעולת השרת חייבת להתחיל באימות קפדני של הקלט באמצעות Zod, Yup או Valibot. יש להתייחס לקלט שלא אומת כאל הפרה חמורה של אבטחת הקוד בבדיקות הקוד.
- קידוד הגנתי:
- הימנע משימוש בפונקציות "מיזוג עמוק" כלליות על קלט המשתמש.
- העדיפו ליצור אובייקטים חדשים עם מאפיינים מפורשים על פני מיזוג:
const newData = { prop1: input.prop1, prop2: input.prop2 }; - שקול להשתמש ב
Object.create(null)עבור אובייקטים שיכילו קלט משתמש, כדי להבטיח שאין להם אב טיפוס.
- הקשחת זמן ריצה (האופציה הגרעינית): כקו הגנה אחרון, ניתן להקפיא את אב הטיפוס של האובייקט בעת הפעלת היישום. שימו לב שפעולה זו עלולה לפגוע בספריות צד שלישי המסתמכות על שינוי אב טיפוסים.JavaScript
// ב-instrumentation.js או ב-root layout if (process.env.NODE_ENV === 'production') { Object.freeze(Object.prototype); Object.freeze(Array.prototype); }
הפניות וקישורים לסמכויות:
