שלום.
קראתי בכמה ימים האחרונים על בעיית הCSRF וההגנה מפניה.
יש לי כמה שאלות שאשמח לקבל עליהן תשובה:
1. האם הtoken חייב להיות חד-פעמי? כלומר, האם צריך להחליף אותו לאחר שימוש בו?
2. האם הtoken חייב להיות יחידני? כלומר, האם הtoken חייב להיות בשימוש רק אצל קליינט אחד בלבד? אם כן, האם אפשר לאחר מסגרת זמן מסויימת [24 שעות לדוגמא] לתת את הtoken למישהו אחר? [כמובן שזה יהיה token רנדומלי, אבל למקרה שיצא פעמיים אותו דבר ברנדומליות..]
3. האם אורך הtoken משפיע על הבטיחות? כלומר, אם אני מוציא לדוגמא מחרוזת מוצפנת בmd5 [בת 32 תווים], היא תהיה פחות בטוחה לעומת מחרות מוצפנת בsha1 [בת 40 תווים]?
4. איחסון הtoken - במידה ואני משתמש במערכת session-ים, האם כדאי יותר לשמור את הtoken בתא נוסף במסד הנתונים [גם ככה יש שורה לsession] או שמא לאחסן את הtoken ב$_SESSION?
5. במידה ויש דברים שאני מעוניין להשתמש בהם בajax, האם זה נכון לשמור את מידע הtoken במשתנה javascript בעמוד שמריץ את הסקריפט ואז לשלוח ביחד עם הajax?

שאלה נוספת לגבי עיבוד xml:
שוב, במידה ואני מעוניין להשתמש בajax, כדאי לי להשתמש בתגובת xml ואז לפענח אותו בעזרת javascript [כמו שנעשה במערכת vbulletin]?

תודה רבה לכם

ציטוט:

במקור נכתב על ידי Koritza שאלה נוספת לגבי עיבוד xml: שוב, במידה ואני מעוניין להשתמש בajax, כדאי לי להשתמש בתגובת xml ואז לפענח אותו בעזרת javascript [כמו שנעשה במערכת vbulletin]?

לדעתי זה ממש כדאי.
כך אפשר לקבל מידע ולסווגו.
אתן לך דוגמא: נניח ואתה משתמש ב-AJAX כדי לחפש שם משתמש ולקבל אותו בתשובת ה-AJAX.
איך תדע אם התשובה מכילה שם משתמש אמיתי, או שהיא מכילה הודעת שגיאה (או איזשהו סימן שיגיד לך שהייתה שגיאה) ?
תשובה: הפרדת מידע בעזרת XML.
לחלופין אפשר להשתמש ב-JSON, טכניקת הפרדת וסיווג מידע שמשתמשים בה גם ב-FF כאשר אתה מייצא את ה-bookmarks שלך (אם הם משתמשים בטכניקה הזו, אז כנראה שהיא טובה בשביל הפרדת וסיווג מידע).

תודה רבה, אני חושב שאני באמת אשתמש בזה.
ולגבי הCSRF?

ציטוט:

לגבי הCSRF?

חכה למומחים

על מנת למנוע CSRF תשתמש במשפטי SWITCH

היי,
שמי דן , ואשמח לעזור לכם בכל פנייה שהיא
ניתן ליצור איתי קשר באיימיל (DanDan@walla.com) במסנג'ר (DanDan@walla.com) ובאיסיקיו (12348188)

גלישה נעימה...

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

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

אז אתה אומר שאין לנו (מתכנתי PHP שבונים אתר רגיל) בעצם מה לעשות נגד CSRF?

קראתי על זה באנגלית אבל לא ממש הבנתי

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

אנסה להסביר בקצרה:
נניח אתה פותח 2 חלונות (או 2 טאבים), באחד אתה מתחבר לאתר הבנק שלך ובשני אתה מתחבר לאיזה פורום.
עכשיו, באתר הבנק שלך אתה מכניס שם משתמש וסיסמא, ולאחר מכן אתה תהיה מזוהה כמשתמש ספציפי שמחובר לאתר.
כיוון שאתה כבר מזוהה, כל פעולה שאתה תבצע יכולה לעשות\לגשת לדברים רגישים.
ונניח אתה נכנס לחלון של הפורום, לוחץ על כפתור, והכפתור הזה מפנה אותך אל location אחר, כאשר ה-location הזה הוא אתר הבנק שלך, ופרמטרי ה-URL מבצעים פעולה של העברת כספים בחשבון שלך.
מבחינה טכנית אין עם זה שום בעיה - הרי אתה כבר מזוהה בבנק שלך, ומבחינתם זה אתה שביקשת את זה.
אבל אתר הבנק לא יודע שבוצעה הפנייה לאתר הזה עם הפרמטרים האלה, ולכן הוא מבצע את הפעולה הזו.

לכן במקרה הזה פיתרון של captcha לדוגמא יהיה טוב
או לדוגמא בדיקה של ה-referrer

פשוט לעשות במערכת משהו כזה:

קוד PHP:

<?php
class myFancyFreamWork
{
    function myFancyFreamWork() {
        // Bla Bla Bla... fancy shit..
        $this->referrer = $_SESSION['referrer'];
        $_SESSION['refferer'] = $_SERVER["REQUEST_URI"];
    }
}

// Check referrer
if($FancyFreamWork->referrer != 'fancypage.php/fancy/mod/rewrite/thing')
    die('CSRF Attack!.. or something else..');
?>

אני חושב שאתה צריך לוודא את הכתובת של האתר שלך כולל ה-host name, ולא את ה- request uri ...

כלומר אם האתר שלך הוא www.myWeb.com אז תוודא שה-referrer מכיל את האתר הזה בתחילתו.

אז מה זה אותו הtoken שמדברים עליו כל כך הרבה בעצם?

אוקי עשיתי עוד קצת קוראים ו-token מחרוזת שמשתמשים בה כאחת הטכניקות למניעת CSRF.

קודם אראה לך את הקישור מאיפה קראתי וקיבלתי דוגמא (מעולה): http://shiflett.org/articles/cross-...quest-forgeries
אני ממליץ לשים את הבלוג שלו במועדפים. אחלה בלוג, אחלה מאמרים ואחלה הסברים.

ה-token זו מחרוזת hash או כל מחרוזת שרירותית אחרת שאתה שם אותה בטופס (form) פעם אחת בלבד, וכאשר יתבצע submission של הטופס, אתה תבדוק את התקינות של ה-token, מה שאומר לך שאכן המשתמש שלח (אלא אם בוצעה XSS attack בעמוד) את הטופס.
ה-token חייב להיות מתחלף עבור כל טופס שאתה שם אותו, ועבור כל פעם שמבצעים submission לטופס.
להבדיל מ-captcha, ה-token לא מחייב את המשתמשים להדפיס אותיות מתמונה שהם רואים, אלא הוא מיושם כבר בטופס עצמו בצורה "עיוורת" למשתמש (כאשר הוא צופה בקוד מקור) על ידי המתכנת\צד-השרת, וזאת הסיבה שהוא הרבה יותר נוח לשימוש עבור משתמשי הקצה. לכן ה-token הוא דומה ל-captcha מלבד העובדה העיקרית שהוא לא מונע ממשתמשי קצה "רובוטיים" לבצע פעולות.

ציטוט:

במקור נכתב על ידי dorM אוקי עשיתי עוד קצת קוראים ו-token מחרוזת שמשתמשים בה כאחת הטכניקות למניעת CSRF. קודם אראה לך את הקישור מאיפה קראתי וקיבלתי דוגמא (מעולה): http://shiflett.org/articles/cross-...quest-forgeries אני ממליץ לשים את הבלוג שלו במועדפים. אחלה בלוג, אחלה מאמרים ואחלה הסברים. ה-token זו מחרוזת hash או כל מחרוזת שרירותית אחרת שאתה שם אותה בטופס (form) פעם אחת בלבד, וכאשר יתבצע submission של הטופס, אתה תבדוק את התקינות של ה-token, מה שאומר לך שאכן המשתמש שלח (אלא אם בוצעה XSS attack בעמוד) את הטופס. ה-token חייב להיות מתחלף עבור כל טופס שאתה שם אותו, ועבור כל פעם שמבצעים submission לטופס. להבדיל מ-captcha, ה-token לא מחייב את המשתמשים להדפיס אותיות מתמונה שהם רואים, אלא הוא מיושם כבר בטופס עצמו בצורה "עיוורת" למשתמש (כאשר הוא צופה בקוד מקור) על ידי המתכנת\צד-השרת, וזאת הסיבה שהוא הרבה יותר נוח לשימוש עבור משתמשי הקצה. לכן ה-token הוא דומה ל-captcha מלבד העובדה העיקרית שהוא לא מונע ממשתמשי קצה "רובוטיים" לבצע פעולות.

תודה לך על הקישור [הוספתי למועדפים] ועל ההסבר, עזרת לי מאוד. אני חושב שהבנתי איך להשתמש בזה

ציטוט:

במקור נכתב על ידי ישראל K יש להשים לב לכך שהנקודה העיקרית של בעיה זו, היא שניתן להפנות לקישור ה"בעייתי" אפילו מתוך דף אחר תחת אותו שם מתחם (לדוגמה, פורום, מערכת תגובות או אחר). לכן, סתם לבדוק שהמפנה הוא מאותו אתר, לא ממש יועיל, חשוב לבדוק שהוא הופנה מדף לגטימי - כשכמובן אותו דף חסין מפגיעה זו. בעיה נוספת בבדיקת המפנה, היא שיתכן ובמקרים מסויימים המפנה לא יוצג (לפי בחירת הגולש, מניעה של תוכנת אבחה או במקרה הפחות מצוי, דפדפן שאינו תומך בשליחת נתון זה). מס' פתרונות לדעתי: 1. captcha הוא פתרון טוב, אך הוא פחות נח למשתמש. או לחילופין, מדי פרוץ (אם הוא נח מדי למשתמש...). 2. פתרון פשוט נוסף יכול להיות ביצוע הפעולה באמצעות שיטת POST בלבד ולא באמצעות GET. 3. אבל נראה לי שיצירת קוד יחודי לפי אלגוריתם לא ידוע, לכל פעולה משמעותית, תהיה הפתרון הטוב יותר.

1. אני אשתמש גם בcaptcha אבל יש מקרים מסויימים [לדוגמא פעולות בעזרת ajax] שבהם השימוש בcaptcha לא יעיל או לא נכון.
2. זה גם תלוי במקרים, בכל מקרה נתונים חשובים מועברים בשיטת POST, אך נתונים פחות חשובים [כמו לדוגמא במערכת vbulletin, עמוד הmember.php?u=XXX] מועברים בכל זאת בGET.
3. מה הכוונה? מן הסתם, הכנסת שורה למסד לדוגמא, היא אותו דבר [פלוס מינוס] אצל כולם.
תודה לך

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

מס' פתרונות לדעתי:
1. captcha הוא פתרון טוב, אך הוא פחות נח למשתמש. או לחילופין, מדי פרוץ (אם הוא נח מדי למשתמש...).
2. פתרון פשוט נוסף יכול להיות ביצוע הפעולה באמצעות שיטת POST בלבד ולא באמצעות GET.
3. אבל נראה לי שיצירת קוד יחודי לפי אלגוריתם לא ידוע, לכל פעולה משמעותית, תהיה הפתרון הטוב יותר.

ציטוט:

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

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

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

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

ציטוט:

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

וגם הנוח ביותר למשתמש קצה

יש פיירוולים שחוסמים referrer כמו OutPost המעצבן... (או, לפחות, כך עשה לפני שנים רבות...)

נמאס לכם לזכור סיסמאות? לחצו כאן!

יכול להיות שבאמת לא הבנתי S:
לפי מה שהבנתי, token זאת מחרוזת רנדומלית שמתקבלת לכל קליינט, אותה בודקים בכל טפוס שנשלח על מנת לוודא שהטופס נשלח על ידי קליינט תקין.
הבנתי נכון?

csrf זה לשנות לדוגמא את הגבלת התווים וכל מיני שינויים שהמתכנת אסר בHTML
וניתן למנוע את זה בערך SWITCH

היי,
שמי דן , ואשמח לעזור לכם בכל פנייה שהיא
ניתן ליצור איתי קשר באיימיל (DanDan@walla.com) במסנג'ר (DanDan@walla.com) ובאיסיקיו (12348188)

גלישה נעימה...