CSRF ו-XSS: ההבדל, איך כל אחד עובד, ואיך מגינים

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

איך CSRF מנצל אמון בין דפדפן לשרת ו-XSS מריץ קוד זר, SameSite Cookies ו-CSRF Tokens, שלושת סוגי ה-XSS, ולמה נדרשות כמה שכבות הגנה במקביל.

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

איך CSRF עובד בפועל

אם משתמש מחובר לאתר בנקאי בטאב אחד, ואתר זדוני בטאב אחר שולח בקשת POST לכתובת הבנק (למשל דרך form שמוגש אוטומטית), הדפדפן יצרף את ה-Cookie של הבנק לבקשה הזו כרגיל — האתר הזדוני לא צריך לגנוב שום דבר, רק לנצל שהדפדפן שולח קרדנציאלים אוטומטית לכל בקשה לדומיין הזה, מכל מקור שהוא. הקורבן אפילו לא צריך ללחוץ על משהו במודע; מספיק שהעמוד הזדוני נטען ברקע.

הגנות CSRF: SameSite ו-CSRF Tokens

SameSite=Lax או Strict על ה-Cookie מונע מהדפדפן לצרף אותו לבקשות שמקורן בדומיין אחר — הגנה חזקה וכמעט חינמית שכיום ברירת מחדל בדפדפנים מודרניים. CSRF Token — ערך אקראי שהשרת מצפה לו בכל בקשה משנה-מצב, ושדף זדוני חיצוני לא יכול לדעת — נשאר שכבת הגנה נוספת חשובה, בעיקר כשלא ניתן לסמוך רק על SameSite (למשל תמיכה בדפדפנים ישנים או תרחישי Cross-Site לגיטימיים).

איך XSS עובד: שלושה סוגים שונים

Stored XSS מזריק קוד שנשמר בשרת (למשל בתגובה) ורץ אצל כל מי שצופה בה — הפגיע ביותר, כי פוגע בכל משתמש שנחשף לתוכן בלי שום פעולה נוספת מהתוקף. Reflected XSS מחזיר קוד זדוני מפרמטר URL ישירות לתגובת השרת בלי לנקות אותו, ודורש שהקורבן ילחץ על קישור מוכן מראש. DOM-based XSS לא נוגע בשרת בכלל — הקוד הזדוני מופעל דרך מניפולציה על ה-DOM בצד הלקוח, למשל דרך innerHTML שמזין תוכן לא נקי ישירות מ-URL הדפדפן.

הגנות XSS: Escaping ו-CSP

ההגנה הראשונה היא Escaping נכון של כל תוכן שמוזרק ל-HTML — פריימוורקים מודרניים עושים את זה אוטומטית ברוב המקרים, אבל שימוש ב-dangerouslySetInnerHTML או innerHTML ישיר עוקף את ההגנה הזו במכוון. שכבת ההגנה השנייה, שפועלת גם אם Escaping נכשל במקום כלשהו, היא Content Security Policy שחוסם הרצת סקריפטים ממקורות לא מורשים ברמת הדפדפן עצמו.

הקשר בין XSS לאחסון Token

XSS מוצלח לא רק "מריץ קוד" — הוא יכול לגנוב כל דבר שנגיש ל-JavaScript בדף, כולל Token שנשמר ב-localStorage. זו הסיבה שהמלצת האבטחה המקובלת היא Cookie מסוג HttpOnly עבור Token רגישים, שאינו נגיש ל-JavaScript בכלל — הרחבה מלאה של הנושא נמצאת במלכודות JWT.

Double-Submit Cookie: חלופה ל-Token מבוסס Session

כשאין Session בצד השרת (למשל API Stateless), דפוס Double-Submit שולח את אותו ערך CSRF גם כ-Cookie וגם כשדה נסתר או Header בבקשה — השרת מוודא שהשניים תואמים. תוקף שלא יכול לקרוא Cookies מדומיין אחר (מדיניות Same-Origin) לא יכול לשחזר את הערך הנדרש, גם בלי Session מרכזי שמנהל את הערך.

Defense in Depth: אף הגנה בודדת לא מספיקה

SameSite לבד לא מגן מפני כל תרחיש (יש חריגים בבקשות Top-Level Navigation), Escaping לבד לא מכסה כל נקודת הזרקה אפשרית, ו-CSP לבד לא מונע CSRF בכלל. ההנחה הנכונה היא שכל הגנה בודדת יכולה להיכשל בנקודה כלשהי, ולכן משלבים כמה שכבות במקביל — בדיוק העיקרון שעומד מאחורי WAF כשכבת הגנה נוספת ברמת הרשת, לא תחליף לקוד מאובטח.

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

תגיות: CSRF · XSS · אבטחת מידע · Web Security · CSP

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