מילון סייבר בעברית

מה זה SSRF ואיך בקשה מהשרת הופכת לסיכון

SSRF, קיצור של Server-Side Request Forgery, היא חולשה שמאפשרת להשפיע על בקשות שיוצאות מהשרת כך שיפנו ליעד שאינו מורשה. לדוגמה, רכיב שמוריד קובץ מכתובת שהמשתמש מזין צריך לבדוק לאן השרת באמת מתחבר. הסיכון נובע מהגישה ומההקשר של השרת, ולא רק ממה שהמשתמש יכול לפתוח בדפדפן.

מתי שרת האתר פונה לכתובת שמגיעה מבחוץ

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

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

הגנה נבחנת לפי היעדים שהעסק באמת צריך

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

שאלות למיפוי בקשה יוצאת
שלבשאלה לבדיקהגבול תכנון
בחירת יעדהאם נחוצים יעדים קבועים או כתובת חופשיתלא לפתוח בחירה מעבר לצורך
פענוח כתובת ו-DNSלאן הבקשה אמורה להתחבר בפועלבדיקה טקסטואלית בלבד אינה מספיקה
הפניה לכתובת אחרתהאם מותר לעקוב אחריהלא לאשר יעד חדש אוטומטית
יציאה מהרשתאילו יעדים ושירותים נגישים לתהליךלצמצם גם בשכבת הרשת
OWASP: הגנה מבקשות שרת ליעדים לא מורשים

דוגמה: יבוא תמונת מוצר מקישור

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

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

מה ההבדל בין SSRF, XSS ו-CSRF

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

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

מה צריכה לכלול מסירת התיקון

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

מקור מקצועי: OWASP: הגנה מבקשות שרת ליעדים לא מורשיםמקור מקצועי: OWASP: אבטחת קבלת ושליחת webhooks

תשובות ברורות

שאלות שעולות בנושא

SSRF קיימת רק בשירותי ענן?

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

אפשר לפתור SSRF עם CSP?

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

חסימת כתובות פרטיות מסיימת את הבדיקה?

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

מתקדמים לפי הצורך

האתר מוריד תוכן או שולח מידע לכתובת שהמשתמש בוחר?

נמפה את תהליך הבקשה והגישה הזמינה ונגדיר בדיקה מורשית של יעדים ובקרות.

לתיאום בדיקה וטיפול