מה זה חולשת דה-סריאליזציה - מהחולשות המורכבות אבל המסוכנות ביותר

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

קודם צריך להבין מה זו בכלל סריאליזציה

תוכנות עובדות עם אובייקטים - מבני נתונים מורכבים בזיכרון של התוכנית. הבעיה היא שאי אפשר לשלוח אובייקט כזה כמו שהוא דרך הרשת, או לשמור אותו כמו שהוא בקובץ. סריאליזציה - Serialization - היא התהליך שבו הופכים אובייקט כזה לרצף בייטים או טקסט, שאפשר לשלוח או לשמור. דה-סריאליזציה היא התהליך ההפוך - לוקחים את הרצף הזה, וממנו בונים מחדש את האובייקט המקורי בזיכרון.

זה שימושי מאוד - שרת יכול לסרייל אובייקט של session משתמש, לשלוח אותו לדפדפן כעוגייה, ולבנות אותו מחדש כשהעוגייה חוזרת בבקשה הבאה. הבעיה היא שהתהליך הזה, בהרבה שפות תכנות, לא רק "מעתיק נתונים" - הוא בפועל מפעיל קוד כדי לשחזר את המבנה של האובייקט.

אז איפה בדיוק זה נהיה מסוכן

אם שרת מקבל נתונים מסוריילים ממקור שאינו מהימן - כלומר מהמשתמש - ומריץ עליהם דה-סריאליזציה בלי בדיקה, תוקף יכול לבנות רצף בייטים שמתחזה לאובייקט לגיטימי, אבל בפועל, כשהוא "נבנה מחדש" בזיכרון, גורם להרצת קוד שהתוקף בחר. זה קורה כי תהליך הבנייה מחדש של אובייקט מסוים יכול לכלול קריאה לפונקציות מסוימות באופן אוטומטי, ותוקף מיומן יודע לנצל בדיוק את הנקודות האלה כדי להשתיל שם את הקוד הזדוני שלו.

זה שונה מהותית מחולשות אחרות שדיברנו עליהן, כי כאן הנתונים עצמם, לא רק תוכן טקסטואלי, הם מה שגורם להרצת הקוד. זו הסיבה שחולשת דה-סריאליזציה נחשבת מורכבת יותר להבין, אבל גם קטלנית יותר כשמנצלים אותה בהצלחה.

איפה נתקלים בזה בפועל

חולשות דה-סריאליזציה מופיעות בעיקר בשפות ומסגרות עבודה שתומכות בפורמט סריאליזציה מובנה משלהן - כמו Java, PHP, ו-Python - שם קל למפתחים להשתמש בסריאליזציה מובנית בלי לחשוב פעמיים על המקור של הנתונים. הן פחות שכיחות במערכות שמשתמשות רק בפורמטים פשוטים כמו JSON טהור, אבל גם שם קיימות וריאציות של הבעיה כשמשתמשים בספריות שמוסיפות יכולות סריאליזציה מתקדמות יותר על גבי JSON.

למה זה נחשב לאחת החולשות החמורות ביותר

בדיוק כמו Command Injection והעלאת קבצים לא מאובטחת, חולשת דה-סריאליזציה שמנוצלת בהצלחה נותנת לתוקף הרצת קוד מרחוק - את הרמה הגבוהה ביותר של שליטה שתוקף יכול לקבל על מערכת. זו הסיבה שהיא מופיעה שוב ושוב ברשימת OWASP Top 10 תחת קטגוריית כשלי שלמות תוכנה ונתונים, למרות שהיא פחות מוכרת לקהל הרחב מ-XSS או SQL Injection.

איך מגנים מפני חולשת דה-סריאליזציה

הכלל הבסיסי ביותר הוא - לעולם לא לבצע דה-סריאליזציה על נתונים שמגיעים ממקור שאינו מהימן, בלי בדיקה קפדנית. כשזה ממש הכרחי, עדיף להשתמש בפורמטים פשוטים כמו JSON שלא מריצים קוד כחלק מהבנייה מחדש של האובייקט, במקום בפורמטים סריאליזציה מלאים של השפה. שכבות הגנה נוספות כוללות הרשאות מצומצמות לתהליך שמבצע את הדה-סריאליזציה, כדי להגביל את הנזק גם אם התקיפה מצליחה.

איך לומדים את זה בפועל

בגלל המורכבות היחסית של החולשה הזאת, הדרך הטובה ביותר ללמוד אותה היא אחרי שכבר יש לכם בסיס טוב בחולשות הפשוטות יותר, ובסביבת תרגול שבנויה במיוחד להדגים אותה שלב אחר שלב.

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

לסיכום

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

הצטרפו לקהילה בדיסקורד ותלמדו את זה יחד עם קהילה שמוכנה לעזור כשנתקעים.