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

אם אתם משתמשים בdjango עדכני ולפתע מקבלים שגיאת 403 לקריאות הajax שלכם ולא מבינים למה, כדאי שתקראו את זה.

ב8 בפברואר שוחרר תיקון אבטחה בdjango שכלל גרסאות 1.1, 1.2 וגרסת הקוד האחרונה. הסיפור הוא די פשוט, אבל כדי להבין אותו כדאי לדעת כמה פרטים כללים על CSRF, למה משתמשים בזה ואיך. אם אתם יודעים אתם יכולים לקפוץ על הפסקאות הבאות הישר לפתרון.

מה זה CSRF

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

דוגמא פשוטה מתוך וויקיפידיה היא שתילת קוד בתוך כתובת של תמונה. הדפדפן של הקורבן ניגש להביא את התמונה, מזדהה כקורבן ומפעיל פעולה שאינה קשורה כלל לתמונה:

<img src="http://bank.example.com/withdraw?account=bob&amount=1000000&for=mallory">

השיטה הפופלרית ביותר להתמודדות (זו שdjango משתמשת בה, וכן wordpress וruby) היא הוספת קוד סודי לפני קריאות אפשריות לשרת. אם הקוד לא שם אז השרת מתיחס לקריאה כפריצת אבטחה ומחזיר קוד 403.

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

מהי ההתקפה האפשרית החדשה

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

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

$.ajaxSetup({
    beforeSend: function(xhr, settings) {
        function getCookie(name) {
            var cookieValue = null;
            if (document.cookie && document.cookie != '') {
                var cookies = document.cookie.split(';');
                for (var i = 0; i < cookies.length; i++) {
                    var cookie = jQuery.trim(cookies[i]);
                    // Does this cookie string begin with the name we want?
                    if (cookie.substring(0, name.length + 1) == (name + '=')) {
                        cookieValue = decodeURIComponent(cookie.substring(name.length + 1));
                        break;
                    }
                }
            }
            return cookieValue;
        }
        if (!(/^http:.*/.test(settings.url) || /^https:.*/.test(settings.url))) {
            // Only send the token to relative URLs i.e. locally.
            xhr.setRequestHeader("X-CSRFToken", getCookie('csrftoken'));
        }
    }
});

תיאור הפתרון:

בעזרת jquery אנחנו תופסים כל בקשת ajax, ובודקים אם יש לנו עוגיה המכילה את המילה csrftoken, ומוסיפים אותה לבקשה.