לאחרונה נתקלתי במספר פוסטים בנושא timing attack. מתקפה זו אינה חדשה וגם לא מתוחכמת מדי. לטעמי היא גם לא שימושית לרוב, אך אני רוצה להשתמש בה כדוגמה לאחת הסיבות לעובדה, שמרבית המערכות אינן secure by design.
מה זה timing attack
מתקפת תזמון זו מתקפה מסוג side channel, המנצלת את אופן פעולת אלגוריתם אבטחה, על מנת לגלות מידע שימושי או סוד כלשהו. במילים פשוטות, לדוגמה, לגלות סיסמה תו אחר תו, בהתבסס על זמני תגובת המערכת. נניח שהמתכנת מימש מנגנון tokens באתר כחלק מתהליך הזדהות משתמשים. זו פיסת הקוד PHP שהוא כתב, הבודקת את ערך ה- token שהמשתמש שלך לאתר:
$token = get_user_token_from_db();
return ($token === $_SESSION["token"]);
עם שימוש בקוד זה, זמן תגובת השרת ישתנה בהתאם לכמות התווים הנכונים שהמשתמש שלך בערך ה- token (אורך המחרוזת ידוע מראש). זה מכיוון שהשוואת מחרוזות מתבצעת תו מול תו, או יותר נכון בית מול בית, מכיוון שב- PHP השוואת המחרוזות בפועל עובדת עם memcmp. לכן, ההשוואה צריכה להתבצע בצורה הבאה:
$token = get_user_token_from_db();
$len = strlen($token);
if ($len !== strlen($_SESSION["token"])) {
return false;
}
$result = 0;
for ($i = 0; $i < $len; $i++) {
// ord returns ASCII value of a char
$result |= (ord($token[$i]) ^ ord($_SESSION["token"][$i]));
}
return 0 === $result;
או במקרה של PHP עם פונקציה hash_equals הממומשת בדיוק כך. קוד זה יבטיח שזמן תגובת השרת לא יושפע מאורך התווים הנכונים.
מתכנת אבטחה
מימוש אבטחה חייב להתבצע עם חשיבה שונה מפיתוח כל פונקציונליות אחרת. במקרה של timing attack, המתכנת צריך לממש בדיקת ערך קריפטוגרפי כלשהו ואינו חושב על זה בצורה שונה מהשוואה רגילה של מחרוזות. תיקון פערי אבטחה עולה יותר כסף וזמן ככל שהתיקון מתבצע מאוחר יותר, בדיוק כמו עם באגים. אמנם רמת המודעות של המתכנתים עלתה ונהיה יותר קשה לנצל XSS או SQLi (לא באמת… למי אני משקר?), אבל אם אנשי אבטחה אינם מעורבים בתהליך הפיתוח ואינם מבצעים סקירות קוד, פערים כמו timing attack יישארו וקטור תקיפה לא מבוטל.
לכן, מימוש מנגנוני אבטחה חייב להתבצע ע"י מתכנת אבטחה, בדיוק כמו שיש מתכנת צד לקוח, מתכנת צד שרת, מתכנת API ומתכנת בסיס נתונים.