מצאנו פרצת אבטחה מסוג SSRF אצל אחד הלקוחות שלנו.

מה זה SSRF?

Server Side Request Forgery – מתקפה המאפשרת לתוקף לגרום לשרת להוציא בקשת HTTP לכל מקום שירצה, מהשרת עצמו. כלומר מתוך הרשת הפנימית, אל כל שירות שלא פתוח כלפי חוץ.

לא מזמן מצאנו בבדיקת חוסן שביצענו אצל אחד הלקוחות שלנו חולשה מעניינת במוצר ששילב יכולות AI בתוך פיצ’ר קיים של העלאת קבצים וניתוח מסמכים. המשתמש היה יכול לספק קובץ להעלאה או URL חיצוני, והמערכת הייתה מושכת את התוכן, שולחת אותו ל-AI service פנימי ומחזירה סיכום. לכאורה מדובר בפיצ’ר נוח, אבל בפועל זה יצר SSRF חמור.

ברגע שהשדה url לא עבר ולידציה אמיתית, תוקף יכול היה לדוגמה לשלוח קריאה כזו:

POST /api/analyze
{
"url": "169.254.169.254/latest/meta-data/iam/security-credentials/"
}

במקום להוריד PDF, השירות הפנימי ניגש ל-metadata service של הענן והחזיר credentials תקפים. משם הדרך קצרה לגישה ל-storage buckets, לסודות פנימיים ול-API calls ברמת חשבון הענן. בבדיקות נוספות ראינו שגם קריאות ל-internal services על 10.x ו-172.x התקבלו בהצלחה, מה שאפשר מעבר מלא לכל שכבת ה-infrastructure דרך פרוקסי לגיטימי לכאורה.

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

איך פותרים

• לא לאפשר URL מהמשתמש, אלא לעבוד עם מזהים פנימיים שממופים בצד השרת לכתובות מאושרות.
• אם חייבים לאפשר URL חיצוני, להגדיר allowlist קפדני של דומיינים מותרים ולחסום במפורש גישה ל-169.254.169.254 ולטווחי RFC1918.
• להריץ את ה-AI service בסביבה מבודדת, נטולת גישה לרשת הפנימית.
• לנטר קריאות יוצאות ולזהות דפוסי שימוש חשודים, כמו ניסיונות לגשת ל-metadata או ל-internal endpoints.

המסקנה ברורה – כשמשלבים AI בפיצ’ר קיים, חשוב לא רק לחשוב על החוויה אלא גם על איך הפיצ’ר יכול להפוך ל-attack surface. טעות קטנה בהנחות לגבי input של המשתמש יכולה להפוך מערכת חכמה לכלי נשק שמופעל נגדך.

פוסט זה פורסם לראשונה בלינקדאין בתאריך 2025-09-30. — ארז מטולה