מה זה CSRF - כשאתר אחר עושה פעולות בשמכם בלי שידעתם

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

אז מה זה בעצם CSRF

CSRF זה קיצור של Cross-Site Request Forgery - זיוף בקשה חוצה אתרים. הרעיון הוא שהדפדפן שלכם, בכל פעם שאתם מחוברים לאתר, שומר "הוכחת התחברות" בצורת עוגייה - cookie. הבעיה היא שהדפדפן שולח את העוגייה הזאת אוטומטית עם כל בקשה לאתר, גם אם הבקשה הזאת בעצם הופעלה מדף אחר לגמרי, בלי ידיעתכם.

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

למה זה עובד בכלל

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

איך זה שונה מ-XSS

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

מה תוקף יכול לעשות עם CSRF

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

מתי CSRF פחות רלוונטי

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

איך מגנים על אתר מפני CSRF

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

איך לומדים את זה בפועל

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

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

לסיכום

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

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