כשיש לנו פרצת אבטחה, הרבה מהפרצות הן בדרך כלל התקפות מוכרות וידועות מראש כמו XSS, או CSRF או SQL injection. ההתקפות האלו קלות לגילוי ברוב המקרים באמצעות static code analysis. אבל הרבה פעמים יש לנו פרצות אבטחה כתוצאה מארכיטקטורת תוכנה.
נשמע מפוצץ, נכון? כשאני עומד בהרצאות ומדבר על 'פרצה באמצעות ניצול בעיות בארכיקטורה של האתר' זה נראה משהו כזה:
בפועל כמובן זה פשוט הרבה יותר. אפילו עד כדי גיחוך. אני אסביר באמצעות פירצה שמצאתי באתר של נייט ראן 2017. למי שלא יודע, מדובר במירוץ הלילה הגדול של תל אביב שמתקיים בחודשי הסתיו כבר שנים ארוכות.
מדובר במירוץ מושקע ובאתר שנראה על פניו מהוקצע. נכנסתי לרישום. ראיתי שיש שם מקום להכניס קוד קופון. הילד הרע שבתוכי הכניס סתם קוד. לחצתי שיגור וראיתי שקופץ לי alert ג'אווהסקריפט ופשוט שאומר "קוד הקופון אינו תקין"
מה הבעיה? מלבד העובדה שאני מקבל alert מאוד לא ייצוגי ומאוד לא מעוצב? שכשהסתכלתי בקונסולה בזמן ששיגרתי את הטופס, ראיתי שהיא ריקה:
מה זה אומר? זה אומר שעל מנת לוודא שהקופון אינו תקין, האתר לא ביצע שום תקשורת עם השרת. כלומר במקום שיהיה לי שירות שבקשת AJAX אליו בודקת אם הקופון תקין או לא, כל המידע על כל הקופונים שמור בצד הלקוח. במקום שאני יכול לבחון אותו.וזה בדיוק מה שקורה. על מנת להקל עלי, כל קוד הג'אווהסקריפט של האתר נמצא ב-HTML ללא מיניפקציה או אגרגציה. אז אפילו להתאמץ לא הייתי צריך.
שם פשוט חיפשתי את הטקסט של השגיאה וגיליתי שכל הקופונים מאוחסנים במערך ענקי שקל להגיע אליו באמצעות:
document.getElementById("ifrm").contentWindow.couponArray;
זו בעיה בארכיטקטורה. מפוצץ עד כמה שזה נשמע. למה? כי אסור, אסור, אסור לשמור קוד בצד לקוח. כי ללקוח יש גישה לכל הקוד שרץ אצלו.
מניעה
כלים אוטומטיים לא יסייעו לנו על מנת למנוע בעיות אבטחה שנובעות מארכיטקטורה. אלו לא פרצות XSS, פרצות CSRF או פרצות שקל למצוא באמצעות ניתוח סטטי של קוד. בעיות כאלו אפשר למנוע באמצעות שילוב של מחלקת אבטחה בתהליך הפיתוח עצמו או העסקת מתכנתים שיש להם מושג באבטחת מידע. זו אופציה נוחה לחברות, אבל לא למי שמעסיק מתכנתים בקבלנות משנה. מה כן עושים? אפשר לעשות מה שמפעילי אתר נייט ראן עשו, להציג אימייל ברור של שירות לקוחות באתר ולתדרך את הנציגים על מנת שידעו מה לעשות אם יש בעית אבטחת מידע. מהרגע שדיווחתי, לקח פחות משעה עד שחזרו אלי ופחות מ-12 שעות עד שחור האבטחה נסגר. במקרה הזה, סגרו אותו באמצעות העברת קוד הקופונים לשרת חיצוני והוצאתו מצד הלקוח.
אימייל ברור ונהלים ברורים של מה שעושים אם פונה אלינו מישהו שגילה חור אבטחה באתר הם די חשובים. למשל, דביר שמעון ששון מצא חורי אבטחה באתר תל אופן. לקח בערך שבועיים עד שהגיבו לפניות שלו וענו לו. אדם אחר היה מתייאש ומפרסם את זה מיידית. הרבה מאוד חורי אבטחה מתגלים באופן משפיל וחמור כי מישהו פשוט לא ענה למייל המתריע בזמן והעניין הגיע לתקשורת. במקרה הזה, גם אם יש פשלה, נוהל ברור ותשומת לב יכולים לסגור את הסיפור.
אם האתר שלכם ציבורי או מושך אש, אפשר גם לעשות bug bounty, תחרות שבמסגרתה מציעים לאנשים פרסים כספיים תמורת גילוי באגים הקשורים לאבטחה. הפרסים לא צריכים להיות גדולים במיוחד וזו דרך אפקטיבית וזולה יחסית למצוא בעיות עוד לפני הפרסום.
לסיכום, המשפט 'פרצת אבטחה כתוצאה מארכיטקטורת תוכנה' נשמע מפוצץ, אבל בפועל הרבה פעמים מדובר במשהו הרבה יותר פשוט להבנה ולמניעה. וגם אם לא, תדרוך נכון של נציגי השירות יכול למנוע הרבה כאבי ראש.
זה שקוד כזה שולב באתר זו תקלה חמורה, ועצם כך שמישהו טיפל בזה באופן די מהיר לא מקטין מחומרת התקלה. דווקא בגלל מהירות התיקון, אני לא אתפלא אם האתר בנוי בטכנולוגיה שמאפשרת להפעיל חלק מהלוגיקה בצד הלקוח וחלק אחר בצד השרת בלי הרבה שינויי קוד ובלי שהמתכנתים מבינים בכלל מה הם עושים או מה ההבדל בין פיתוח למובייל, לווב, או בכלל לדסקטופ – במילים אחרות, טכנולוגיה של מיקרוסופט.
איך נמנעים מתקלות מביכות? להציע פרס לאדם שמוצא את התקלה זה נחמד, אבל לפעמים יכול לגרום לכך שבכל יום יזוהו מספר ”ניסיונות פריצה” של אנשים המנסים לזכות בפרס או בכבוד, ותמיד יש סיכוי שהאדם שימצא את הפריצה יעדיף לשמור אותה לעצמו (או להעביר אותה לגורם שיציע תמורתה סכום כספי גבוה יותר), או שסתם הוא יפרסם אותה בפומבי ויגרום להפסדים למפעילי האתר. לדעתי הרבה יותר חשוב מלכתחילה להעסיק אנשים רציניים, כאלה שמבינים דבר או שניים במה שהם עושים.
לא יודע אם שמת לב! אבל גם אתה פרסמת את הטלפון שלך ואת התעודת זהות שלך
אל דאגה. אלו נתונים לא נכונים שהכנסתי מתוך ידיעה שאני אצלם את המסך 🙂 אבל יפה ששמת לב!
זה תקלה מסוג טמטום
ילד בגן יודע לא לעשות קשקוש כזה, זה כמו לפרסם שם משתמש וסיסמא 🙂