SSRF: כשהשרת שלכם הופך לפרוקסי בשביל התוקף

מאת צוות מדיה דיל · 05.07.2026 · אבטחת מידע · 4 דק׳

Metadata Endpoint בענן, DNS Rebinding, Blind SSRF, סריקת רשת פנימית, Allowlist הדוק, ובידוד רשת מפני SSRF.

כל endpoint שמקבל URL מהמשתמש ומבצע בקשת HTTP אליו בעצמו - שליפת preview לתמונה, webhook, ייבוא קובץ מקישור חיצוני - הוא פוטנציאלית כלי שהשרת שלכם מוכן להפעיל בשבילכם על כתובת שהתוקף בחר. Server-Side Request Forgery מנצל בדיוק את זה: במקום לתקוף ישירות משאב פנימי שהוא לא יכול לגעת בו מרשת חיצונית, התוקף משכנע את השרת שלכם - שכן נמצא בתוך הרשת הפנימית - לשלוח את הבקשה במקומו. השרת הופך לפרוקסי לא רצוני שמדלג בדיוק על כל בקרות הגישה שהגנו על המשאב הפנימי מלכתחילה.

Metadata Endpoints - הפרס שכל תוקף SSRF מחפש בענן

כמעט כל ספק ענן חושף endpoint פנימי בכתובת http://169.254.169.254 שמספק לאינסטנס מידע על עצמו - ובעננים רבים, כולל credentials זמניים של ה-IAM role שמחובר לאינסטנס. אם תוקף מצליח לגרום לשרת לבצע בקשה לכתובת הזו, הוא מקבל בחזרה access key ו-secret key בתוקף מלא בלי צורך בשום חולשה נוספת - ומשם יכול לגשת לכל שירות ענן שהתפקיד הזה מורשה אליו, S3 buckets, מסדי נתונים, ואפילו יכולת לשגר instances חדשים. זו הסיבה ש-SSRF נחשב לחולשה קריטית בסביבת ענן, לא רק מטרד.

עקיפת Allowlist עם DNS Rebinding וטריקי קידוד

הגנה נאיבית שבודקת רק שה-hostname נראה בטוח נופלת בקלות לתוקפים שמשתמשים ב-DNS Rebinding - רישום domain שבבדיקה הראשונה מצביע לכתובת חיצונית תמימה, אבל בזמן שהבקשה בפועל יוצאת (אחרי ה-TTL הקצר של הרשומה) DNS resolution מחזיר כתובת פנימית כמו 127.0.0.1. שיטות נוספות כוללות קידוד ה-IP במספר עשרוני יחיד, שימוש ב-redirect שבדיקת ה-allowlist לא עוקבת אחריו, וניצול IPv6 שלעיתים לא נבדק כלל באותה רמת קפדנות כמו IPv4.

Blind SSRF - כשאין תשובה חוזרת אבל הנזק כבר קרה

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

SSRF כדלת כניסה לרשת פנימית שלמה

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

הגנה מעשית - Allowlist הדוק ובידוד רשת

ההגנה האפקטיבית ביותר משלבת שכבות: allowlist מפורש (לא blocklist) של דומיינים או כתובות מותרות לביצוע outbound requests מהשרת, resolution של ה-DNS פעם אחת עם נעילת התוצאה לפני שליחת הבקשה בפועל כדי למנוע rebinding, וחסימת גישה ל-metadata endpoint ברמת ה-network policy עצמה. שילוב עם WAF שמזהה דפוסי URL חשודים בפרמטרים נכנסים מוסיף שכבת זיהוי מוקדמת לפני שהבקשה בכלל מגיעה לקוד שמבצע אותה.

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

תגיות: SSRF · Server-Side Request Forgery · Metadata Endpoint · DNS Rebinding · Blind SSRF · Cloud Security

← חזרה לבלוג · צור קשר