CSRF – קללה חדשה

1 בדצמבר 2007

תגיות: , , ,
2 תגובות

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


הפעם אציג בקצרה קללה חדשה מאותה המשפחה, ואת הדרכים להתגונן מולה. הכוונה ל-CSRF – כלומר Cross Site Request Forgery.
גם אליה הגעתי בעצמי, כאשר הגעתי למסקנה שניתן לחזור לשרת תחת העוגיות שלי, בעזרת כמה שיטות פשוטות, וגם ללא JS פעיל ניתן לבצע פעולות בשמי בשרת. חיפוש קצר בגוגל העלה שלא חשבתי ראשון (בלשון המעטה) על הבעיה ויש לה אפילו שם מקצועי.
בעבר נתקלתי בבעיה 


המימוש הוא פשוט להחריד. הרבה יותר פשוט מאשר XSS הפופולארי. נניח שיש לי דף במערכת פורומים שיודע למחוק הודעות בשם /Forum/DelMsg.aspx?id=12345. בשלב הבא אני צריך רק להיכנס לפורום, ולשים בחתימה שלי תמונה:

<img style="display: none" src="/Forum/DelMsg.aspx?id=12345">

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


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

<script src="http://www.mysite.net/Forum/DelMsg.aspx?id=12345"></script>

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


 


מה עושים?
הכי פשוט – להחביא את כתובות תפריטי הניהול מכלל המשתמשים. חוסך מגולשים נטולי הרשאות לדעת את ה-URLים של ה"אוייב". עדיף גם לשבור את פורמט הקישורים שלכם באתר ולתת שם בלתי צפוי.
במידה ויש צורך לחשוף את הקישורים לגולשים, ניתן לחשוב על פיתרון יצירתי בסגנון CAPTCHA, ולוודא שהוא לא פוגע יותר מדי בחווית המשתמש של המנהל שלא יאהב הקלדה חוזרת ונשנית של מספרים או אותיות חסרות ערך על כל מחיקה מסכנה.
אפשר לנסות להשתמש ב-POST במקום ב-GET להעברת הנתונים, מה שיוכל לפתור את הבעיה חלקית (עדיין ניתן יהיה לייצר באתר אחר טופס שיעדו הוא  http://www.mysite.net/Forum/DelMsg.aspx ומכיל <input type=hidden name=id value=12345> למשל, אבל אז עבודת הפיתוי תהיה קשה יותר).


 


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

הוסף תגובה
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. שדות החובה מסומנים *

2 תגובות

  1. OhadAston2 בדצמבר 2007 ב 8:14

    צודק בהחלט, ומעניין מאוד!

    רעיון לפתרון – ליצור איזשהו Hash שצריך לעבור ב – QS בכדי למחוק הודעה, ה – Hash יווצר מפרטים מסויימים שלא ידועים למשתמשים (נניח ליצור עוד Hash של ה – Salted Password של המנהל שמנסה למחוק את ההודעה), מערכת הניהול תדע ליצור את ה – Hash הזה בעצמה, אבל זה יצטרך להכלל בלינק של המחיקה.

    (לדוגמה הלינק יהיה /Admin/DeleteMessage?ID=10&SecurityCode=SomeHashedValue

    מה שכן עדיין ניתן באמצעות JS לנסות לגשת לדף עם JS אם ניתן להעלות (כמו בתפוז) ולחפש ב – parent שלו לינקים של המנהל.

    הגב
  2. Moshe L2 בדצמבר 2007 ב 9:22

    אוהד – אם זה JS אז אפשר לממש XSS ישר, אבל גם הרעיון שהעלת ניתן לביצוע, ואגב, פשוט הרבה יותר.

    במידה ויש לי לחצן מחיקה בדף ונתמך JS, אפשר לגשת אליו דרך DOM ו
    document.getElementById().click()
    או שימוש בפונקציה שאליה ניגש הלחצן הזה.

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

    ואם אני בצד שרת – אני יכול פשוט להחביא את התיקיה או שם הקובץ (יעיל כל עוד התוקף נטול הרשאות, למשל, שהוא לא מנהל פורום אחר).

    הפיתרון היעיל האמיתי הוא CAPTCHA או HASH כמו שאמרת, אבל לשניהם יש השלכות מאוד רעות על ביצועים, ובמקרה הראשון גם על חווית המשתמש.

    הגב