יסודות אבטחת אינטרנט: הסבר על SSRF, CSRF ו-CORS

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

היום, נצלול לשלושה מושגים קריטיים שכל מפתח אינטרנט חייב להכיר: SSRF, CSRF ו-CORS. למרות שהם עשויים להישמע כמו מרק אותיות, הם מייצגים את קווי החזית של אבטחת אפליקציות אינטרנט.

1. SSRF (Server-Side Request Forgery)

SSRF היא פגיעות שבה תוקף יכול לאלץ אפליקציית צד-שרת לבצע בקשות HTTP לדומיין שרירותי לבחירתו של התוקף.

איך זה עובד

דמיינו אפליקציית אינטרנט שמקבלת URL כקלט (למשל, כדי להביא תמונת פרופיל או להציג תצוגה מקדימה של קישור) ואז מבצעת בקשה ל-URL הזה מהשרת. אם האפליקציה אינה מאמתת את ה-URL הזה כראוי, תוקף יכול לספק כתובת IP פנימית או כתובת לולאה חזרה (127.0.0.1).

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

• מטא-דאטה של ענן: גישה ל-169.254.169.254 ב-AWS/GCP כדי לשלוף אישורי IAM.
• לוחות ניהול פנימיים: גישה לכלים פנימיים כמו Jenkins או לוחות בקרה של Kubernetes.
• סריקת פורטים: גילוי שירותים אחרים הפועלים ברשת הפנימית.

מניעה

• רשימה לבנה (Allowlisting): אפשר בקשות רק לרשימה מוגדרת מראש של דומיינים מהימנים.
• אימות קלט: ודא שה-URL משתמש בפרוטוקולים מותרים (למשל, https:// בלבד) ואינו מצביע על טווחי IP פנימיים.
• הפרדת רשת: ודא שלשרת האינטרנט יש גישה מוגבלת למשאבים פנימיים.

2. CSRF (Cross-Site Request Forgery)

CSRF היא התקפה שמרמה את הדפדפן של הקורבן לבצע פעולה לא רצויה באתר אחר שבו הקורבן מחובר כעת.

איך זה עובד

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

1. משתמש מתחבר ל-bank.com.
2. המשתמש מבקר באתר זדוני evil.com בלשונית אחרת.
3. evil.com מכיל טופס נסתר ששולח בקשת POST ל-bank.com/transfer?amount=1000&to=attacker.
4. הדפדפן שולח את הבקשה יחד עם עוגיית הסשן של המשתמש ב-bank.com.
5. bank.com רואה סשן תקף ומעבד את ההעברה.

מניעה

• אסימוני אנטי-CSRF: כלול אסימון ייחודי, סודי ובלתי ניתן לחיזוי בכל בקשה המשנה מצב. השרת מאמת אסימון זה לפני העיבוד.
• עוגיות SameSite: הגדר את תכונת ה-SameSite בעוגיות ל-Strict או Lax כדי למנוע את שליחתן בבקשות חוצות-אתרים.
• כותרות מותאמות אישית: עבור בקשות AJAX, דרוש כותרת מותאמת אישית (למשל, X-Requested-With) שלא ניתן להגדיר באמצעות טופס HTML רגיל.

3. CORS (Cross-Origin Resource Sharing)

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

למה זה קיים

כברירת מחדל, דפדפנים אוכפים את מדיניות המקור הזהה (SOP), המונעת מסקריפט באתר אחד לקרוא נתונים מאתר אחר. זה מונע מ-evil.com לקרוא את האימיילים שלך ב-gmail.com.

CORS מאפשר לשרתים להרפות ממדיניות זו בבטחה. כאשר אפליקציית אינטרנט מבצעת בקשה חוצת-מקורות, הדפדפן שולח כותרת Origin. השרת מגיב עם Access-Control-Allow-Origin.

טעויות הגדרה נפוצות

• מקור כללי (*): מתיר את כל המקורות. בעוד שזה בסדר עבור ממשקי API ציבוריים, זה מסוכן אם משולב עם Access-Control-Allow-Credentials: true.
• החזרת המקור (Reflecting the Origin): הגדרה דינמית של המקור המותר בהתבסס על כותרת ה-Origin ללא אימות. זה למעשה עוקף את ה-SOP לחלוטין.

שיטות מומלצות

• היה ספציפי: אפשר רק לדומיינים הספציפיים הזקוקים לגישה.
• הימנע מאישורים אם אפשר: אם ה-API שלך אינו זקוק לעוגיות או לכותרות Authorization, אל תאפשר אותם.
• השתמש ב-Middleware של אבטחה: השתמש בספריות שנבדקו היטב לטיפול בהגדרות CORS במקום ניהול ידני של כותרות.

השוואה מסכמת

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

הישארו בטוחים, ותיהנו מהתכנות!