אבטחת כניסות מקבילות
כניסות ללא הגבלה עלולות להסתיר פגמים חמורים בלוגיקה העסקית.
משתמש מתחבר דרך מחשב נייד. שניות לאחר מכן, אותו חשבון מתחבר בדפדפן אחר. לאחר מכן ממכשיר נייד. ואז מלקוח API. הכל עובד בצורה מושלמת.
זה נראה תקין מכיוון שיישומים רבים תומכים במספר מכשירים. אך עליכם לשאול: האם כל אפליקציה צריכה לאפשר מספר בלתי מוגבל של סשנים (sessions)?
במערכות מסוימות, מספר סשנים הוא תכונה (feature). באחרות, זהו פגם שתוקפים משתמשים בו כדי להישאר חבויים. זוהי פגיעות בלוגיקה העסקית. הקוד עובד כמתוכנן, אך התכנון עצמו חלש.
ההבדל: • באגים מסורתיים מנצלים טעויות קידוד. • באגים בלוגיקה עסקית מנצלים החלטות תכנון.
חשבו על שירות סטרימינג של סרטים. אם מנוי אחד מאפשר לעשרה אנשים לצפות בו בו-זמנית, מערכת ההתחברות עובדת. הכלל העסקי נכשל.
זה תקף לבנקאות, פאנלים של מנהלים (admin panels) ומוצרי SaaS.
איך לבדוק זאת:
- התחברו דרך דפדפן א' והשאירו אותו פעיל.
- פתחו חלון גלישה בסתר (incognito) בדפדפן ב'.
- התחברו עם אותם פרטי גישה.
- בדקו אם הסשן הראשון עדיין עובד.
- בדקו אם ניתן לבצע פעולות רגישות בשניהם.
אפליקציות בעלות רמת אבטחה גבוהה אוכפות לעיתים קרובות את הכללים הבאים:
- סשן פעיל אחד לכל חשבון.
- התנתקות מסשנים ישנים כאשר מתבצעת התחברות חדשה.
- בקרות לניהול מכשירים.
- התראות על התחברויות חדשות.
אם תוקף גונב פרטי גישה, הוא יכול להישאר מחובר לנצח אם אתם מאפשרים סשנים ללא הגבלה. הוא נשאר פעיל בזמן שהמשתמש האמיתי נשאר פעיל. אף אחד מהם לא מבחין בפורץ.
ההקשר הוא הכל. אפליקציות הזקוקות למספר רב של סשנים:
- אפליקציות מסרים.
- רשתות חברתיות.
- שירותי אימייל.
אפליקציות הזקוקות לבקרה קפדנית:
- מערכות בנקאיות.
- לוחות בקרה של מנהלים (admin dashboards).
- פלטפורמות בריאות.
איך לתקן זאת:
- שמרו מזהי סשן (session IDs) פעילים במסד נתונים.
- כאשר מתרחשת התחברות חדשה, סגרו את הסשן הישן.
- אפשרו למשתמשים לראות מכשירים ומיקומים פעילים.
- הוסיפו כפתור "התנתק מכל המכשירים".
- שלחו התראות אימייל או SMS על התחברויות חדשות.
אל תחפשו רק באגים בקוד כמו SQL injection. חפשו פערים בין מה שהאפליקציה שלכם עושה לבין מה שהעסק שלכם דורש.
עברו על מדיניות הסשנים שלכם היום. הסיכון הגדול ביותר שלכם עשוי שלא להיות קוד שבור, אלא לוגיקה שבורה.