לפני כמה שבועות בוצע עדכון לעשרת החולשות הנפוצות במערכות מבוססות Web של OWASP.
בעצם חולשות היא לא המילה הנכונה. יהיה נכון יותר לומר קטגוריות של חולשות. החלוקה לקטגוריות מבוססת על CWE. בכל עדכון של OWASP, הארגון לוקח מספר CWE ומאחד אותן לקטגוריות. אלו הקטגוריות המדורגות בעשרת החולשות הנפוצות. הרכב הקטגוריות משתנה מגרסה לגרסה.
OWASP הוא ארגון ללא מטרות רווח שמקדם אבטחת מידע. הארגון נותן חסות לפרויקטים בתחום ומפרסם משאבים. אחד מפרויקטי הדגל של הארגון הן רשימות עשרת הראשונים. כל רשימה מתייחסת לנושא מסוים. הרשימה שנסקרת בכתבה זו היא רשימת עשרת קטגוריות החולשות למערכות Web. כלומר מערכות שהמשתמש מתחבר אליהן דרך האינטרנט או דרך תוכנה לקוח (אפליקצייה למשל).
רשימת עשרת החולשות נחשבת לתקן מינימלי שתוכנה מאובטחת חייבת לעמוד בה. לכן הרשימה היא מקום טוב להתחיל את המסע שלכם באבטחת מידע.
עשרת הקטגוריות החדשות
הערה: תרגמתי בעצמי (אלא אם היה משהו שהסכמתי איתו בוויקיפדיה העברית או בתרגום העברי לרשימה של 2017).
- בקרה גישה שבורה: עלתה ממקום 5. מתייחסת למקרים שבהם התוכנה לא בודקת האם למשתמש יש מספיק הרשאות כדי לגשת לרכיב מסויים או שהגישה אינה מאובטחת דיה (כמו במקרה שבו רמת ההרשאה מועברת ב-POST ללא קידוד).
- כשלי הצפנה: עלתה ממקום 3. מתייחסת למידע רגיש לא מוצפן. למשל פרטים מזהים שלפי תקנות הגנת הפרטיות צריכים להיות מוצפנים, נשמרים כטקסט.
- הזרקות: איחוד של מקום 1 ו-7. מתייחסת להזרקות קוד למיניהן. בין אם סוגי ה- XSS ובין אם SQL.
כדי לטפל בהזרקות נוודא שכל מידע שמגיע מהמשתמש עובר סינון כך שלא יכלול תווים שלא אמורים להימצא שם (למשל פקודות בשדה שאמור להכיל טקסט). - עיצוב לא מאובטח: קטגוריה חדשה. מתייחסת לעיצוב תוכנה לא מאובטחת. אם בעת אפיון המערכת לא מתייחסים לאבטחת מידע, יהיו בעיות בתוצר הסופי.
מומלץ לממש Shift left בתהליך הפיתוח. כלומר נבצע בדיקות אבטחת סטטיות ודינמיות תוך כדי הפיתוח ולא נמתין למבדק החדירה שנעשה לפני העלייה לסביבת ייצור. המונח Shift left מתייחס להעברה של תהליך האבטחה שמאלה בתרשים פיתוח התוכנה (התרשים מתחיל מצד שמאל בלעז).
מונחים מקצועיים: בדיקות סטטיות – SAST, בדיקות דינאמיות – DAST. לעיתים הכלים תלויים בשפת התכנות בה משתמשים.
פרויקט SAMM של OWASP מתייחס לאבטחת תהליכי פיתוח.
- טעויות הגדרה: עלתה ממקום 6. חולשות XXE אוחדו לתוך קטגוריה זו. מתייחסת לכל אותם מקרים שבהם המערכת לא הוקשחה כהלכה, בין אם כתוצאה מטעות או מחוסר מודעות לקיומה של אפשרות כזו. יש כלים אוטומטיים שבודקים הגדרות ולכל הפחות מבדק חדירה אמור להתייחס לנושא הזה (כתלות בתכולה המבדק).
- רכיבים לא מעודכנים: עלתה ממקום 9. מתייחסת לשימוש ברכיבי תוכנה או חומרה לא מעודכנים או כאלו שידוע שיש בהן חולשות שלא טופלו. למשל: גרסת PHP לא מעודכנת או כזו שכבר לא מקבלת תיקונים. כדי להתמודד עם קטגורייה זו, אני מציע לכם לתעד את כל רכיבי התוכנה והחומרה בהם אתם משתמשים (שרתים, מערכות הפעלה, מסדי נתונים, תשתיות אפליקטיביות, שרתי Web, ספריות וכו') ולנסות להבין אם הם עדיין מקבלים עדכונים. אם לא, אנחנו בדיוק בתחילת נובמבר וזה אחלה זמן להתחיל להיערך לכתיבת תוכנית עבודה ל-2022.
המצב מסתבך עוד יותר כשמשתמשים בספריות תוכנה שלהן רכיבים משלהן. המונח המקצועי הוא SCA – Software Composition Analysis ויש מערכות שמבצעות את הסריקה הזו אוטומטית. מתישהו ב-2022 אני מתכנן לעשות את זה בעבודה ואז אני אכתוב גם פוסט בנושא. - הזדהות שבורה: ירדה ממקום 2. מתייחסת לכל אותם מצבים שבהם ההתחברות למערכת אינה מאובטחת דייה. למשל: סיסמאות שקל לנחש, אין הגבלה על מספר החיבורים השגויים לפני נעילה (זמנית או קבועה), סיסמאות שנשמרות כטקסט, אין הזדהות רב שלבית וכו'.
- כשלים בבדיקת אמינות המידע: מאחדת מספר 8 עם קטגוריה חדשה. מתייחסת למשבר שחווינו בשנה האחרונה בתחום ה- CI/CD. למשל הפריצה הידועה לשרתי Solar Winds שבה הוזרק קוד לתוכנה לפני האריזה לייצור בשרשרת ה- CI/CD בעוד בדיקות האבטחה נעשו על הקוד לפני תהליך האריזה.
קטגוריה 8 לשעבר עסקה בנושא של סִדרות – serialization ו- deserialization. כלומר במקרים שבהם התוכנה לא בדקה האם הנתונים הגיעו ממקור אמין או אם הם מכילים מידע שלא אמור להימצא שם. - ניטור חסר: עלתה ממספר 10 והתווספו אליה תכנים מהסקר האחרון. מתייחסת לחסרונו של ניטור. הדרך היחידה לבדוק אם הניטור תקין היא לבצע בדיקת חדירות או בדיקות דינאמיות (DAST) ולראות האם קופצות התראות במערכות הניטור. בנוסף כדאי לוודא שצוות הניטור מוכשר להבדיל בין אירועים לגיטימיים לתקיפות. כלומר שניתן לבצע אבחנה מבדלת.
נשים לב שמהירות התגובה לאירועים חשובה גם היא. אין משמעות להתראה שמגיעה לצוות הרלוונטי יומיים אחרי האירוע. אם קרה משהו בזמן הזה, סביר להניח שהארגון כבר קיבל את בקשת הכופר מהתוקף.
הניטור חשוב גם לתחקור אירועים ולכן יש לוודא ששומרים יומני תיעוד של כל מה שצריך לתחקור.
יש לשים לב למצב שבו צוות הניטור מקבל יותר מדי התראות ומפתח אדישות להתראות.
ישנן מערכות שמשתמשות בבינה מלאכותית כדי לסנן התראות או לקשר בין אירועים או לנסות להבין מהי פעולה תקינה של המערכות ומה לא. תחום הניטור הוא תחום מקצועי בפני עצמו. - זיוף בקשות צד שרת (SSRF): קטגוריה חדשה שהגיעה מהסקר האחרון. מתייחסת למצב שבו תוקף יכול לאלץ את המערכת לשלוף מידע או להריץ קוד שנמצא בשרת פנימי של החברה (וכביכול מוגן כי הוא לא נגיש מבחוץ) או משרת חיצוני. בצורה כזו התוקף יכול להריץ קוד זדוני על המערכת או לשלוף נתונים שאמורים להיות מוגנים.
ניתן למנוע על ידי בדיקה של קלט מהמשתמש או קלט שמגיע משיטות כמו POST.
