ארבע גישות לאבטחת יישומי האינטרנט של הארגון

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

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

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

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

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

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

כבעלים של אתר או יישום, אנו אחראים על אמון המשתמשים, ושנעשה כל שביכולתנו לוודא שנתוניהם יטופלו בצורה בטוחה ומאובטחת

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

גישת ה-Bug Bounty Program – במסגרתה מציעות חברות התוכנה, ארגונים ובעלי עסקים, תמריצים כספיים למוצאי באגים, פרצות אבטחה ופגיעויות בשירותים שאותם הם מציעים, בתמורה לתשלום.

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

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

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

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

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

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

הכותב הוא מהנדס פרה-סייל בבינת תקשורת מחשבים.