CSRF התקפת

מבוא לאבטחת יישומי ווב – התקפת CSRF

יישומי ווב

היום יותר ויותר רואים יישומים שרצים על הדפדפן, מה שנקרא "יישומי ווב" (web applications). אנשים ניגשים למידע רגיש שלהם דרך הדפדפן: לחשבון הבנק שלהם, לתוכניות הביטוח שלהם, למידע על כרטיסי האשראי שלהם, לאימיילים שלהם, לגיבויים שלהם ועוד. בעבודה, עובדים ניגשים למידע רגיש לעסק דרך הדפדפן: תאור מוצרים עתידיים, מסמכי שיווק, משכורות ועוד.

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

התקפת CSRF

נתאר כאן התקפה אחת שזכתה לשם Cross Site Request Forgery – ראשי תיבות CSRF.

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

פשוט מדהים.

איך זה עובד?

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

שימוש ב authentication cookie

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

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

מה התוקף עושה?

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

למה שהמשתמש הרגיל יעשה את זה? 

כי התוקף ישתמש בשיטות social engineering חכמות לשטות במשתמש כך שהמשתמש יפתח קישור לאתר של התוקף. לדוגמא: הוא ישלח אימייל שנראה בדיוק כמו אימייל של הבנק ובו רשום משהו כמו "דוח רבעוני של החשבון שלך מחכה באתר הבנק. להלן קישור לאתר הבנק לשימושך". 

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

הקוד של התוקף ישלח בקשת מידע מהדפדפן לשרת של יישום הווב הרגיש. לדוגמא, בקשה לקבלת מצב החשבון. עכשיו הדפדפן אוטומטית ייצרף לבקשה את כל ה cookies שהגיעו מאותו שרת. כולל ה authentication cookie.

השרת הלגיטימי יחשוב שהבקשה הגיע ממשתמש חוקי ויחזיר את התשובה.

והנה, התוקף הגיע למידע חסוי בשם המשתמש האמיתי.

איך מתגוננים?

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

גם אם המשתמש פתח אתר של התוקף, הקוד של התוקף לא יכול לקרוא את ה headers של המידע שמגיע ליישום הווב הלגיטימי.

ל angularJS יש תמיכה מראש בשיטה הזו.