באג אבטחה שנובע מארכיטקטורת תוכנה

כשיש לנו פרצת אבטחה, הרבה מהפרצות הן בדרך כלל התקפות מוכרות וידועות מראש כמו XSS, או CSRF או SQL injection. ההתקפות האלו קלות לגילוי ברוב המקרים באמצעות static code analysis. אבל הרבה פעמים יש לנו פרצות אבטחה כתוצאה מארכיטקטורת תוכנה.

נשמע מפוצץ, נכון? כשאני עומד בהרצאות ומדבר על ‘פרצה באמצעות ניצול בעיות בארכיקטורה של האתר’ זה נראה משהו כזה:

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

מדובר במירוץ מושקע ובאתר שנראה על פניו מהוקצע. נכנסתי לרישום. ראיתי שיש שם מקום להכניס קוד קופון. הילד הרע שבתוכי הכניס סתם קוד. לחצתי שיגור וראיתי שקופץ לי alert ג’אווהסקריפט ופשוט שאומר “קוד הקופון אינו תקין”

מה הבעיה? מלבד העובדה שאני מקבל alert מאוד לא ייצוגי ומאוד לא מעוצב? שכשהסתכלתי בקונסולה בזמן ששיגרתי את הטופס, ראיתי שהיא ריקה:

מה זה אומר? זה אומר שעל מנת לוודא שהקופון אינו תקין, האתר לא ביצע שום תקשורת עם השרת. כלומר במקום שיהיה לי שירות שבקשת AJAX אליו בודקת אם הקופון תקין או לא, כל המידע על כל הקופונים שמור בצד הלקוח. במקום שאני יכול לבחון אותו.וזה בדיוק מה שקורה. על מנת להקל עלי, כל קוד הג’אווהסקריפט של האתר נמצא ב-HTML ללא מיניפקציה או אגרגציה. אז אפילו להתאמץ לא הייתי צריך.

שם פשוט חיפשתי את הטקסט של השגיאה וגיליתי שכל הקופונים מאוחסנים במערך ענקי שקל להגיע אליו באמצעות:

document.getElementById("ifrm").contentWindow.couponArray;

זו בעיה בארכיטקטורה. מפוצץ עד כמה שזה נשמע. למה? כי אסור, אסור, אסור לשמור קוד בצד לקוח. כי ללקוח יש גישה לכל הקוד שרץ אצלו.

מניעה

כלים אוטומטיים לא יסייעו לנו על מנת למנוע בעיות אבטחה שנובעות מארכיטקטורה. אלו לא פרצות XSS, פרצות CSRF או פרצות שקל למצוא באמצעות ניתוח סטטי של קוד. בעיות כאלו אפשר למנוע באמצעות שילוב של מחלקת אבטחה בתהליך הפיתוח עצמו או העסקת מתכנתים שיש להם מושג באבטחת מידע. זו אופציה נוחה לחברות, אבל לא למי שמעסיק מתכנתים בקבלנות משנה. מה כן עושים? אפשר לעשות מה שמפעילי אתר נייט ראן עשו, להציג אימייל ברור של שירות לקוחות באתר ולתדרך את הנציגים על מנת שידעו מה לעשות אם יש בעית אבטחת מידע. מהרגע שדיווחתי, לקח פחות משעה עד שחזרו אלי ופחות מ-12 שעות עד שחור האבטחה נסגר. במקרה הזה, סגרו אותו באמצעות העברת קוד הקופונים לשרת חיצוני והוצאתו מצד הלקוח.

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

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

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