יומן אבטחה

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

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

המאמר הראשון עוסק ב-Request Token. זהו פתרון אחר ומעניין לבעיה של session hijacking, שמבוצע בנוסף לשימוש במזהה session. המשמעות היא שלכל בקשה שמגיש המשתמש מתלווה token מזהה המונפק במענה לכל בקשה מחדש. במצב כזה, היישום צריך לבצע רישום של ה-token הנוכחי והקודם ובכל הגשת בקשה על ידי דפדפן לבדוק האם ה-token תקף. במידה ונעשה שימוש פעמיים באותו ה-token ניתן לדעת כי יש כאן מקרה של גניבת session ולנתק באופן אוטומטי את המשתמש ולהעביר אותו לחלון ההזדהות להזדהות מחודשת.

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