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

מאת: ארז מטולה
CISSP
Application Security Department Manager
Security Training Academic Director
Security Software Engineer
, מצויה בדרך כלל דווקא בשכבה העליונה - שכבת האפליקציה - ולא בשכבות "המסורתיות", כגון תקשורת או מערכת ההפעלה.

רקע
נקודת התורפה העיקרית במערכות המחשוב של ארגונים

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

מהי אבטחת אפליקציות ומדוע היא שונה מאבטחת מידע "רגילה"?

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

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

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

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

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

דוגמאות לבעיות אפליקטיביות

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

מתקפת Cross Site Scripting (XSS) מהווה דוגמא נוספת לבעיית אבטחה אפליקטיבית. מתקפה זו מתקיימת כאשר המערכת מחזירה למשתמשים קלט שהתקבל בעבר ואשר נכתב לפלט. לדוגמא, מערכת פורום המקבלת הודעות ממשתמשים ולאחר מכן מציגה את ההודעות לכולם. המערכת בונה דף HTML על סמך ההודעות, ושולחת אותו למשתמשים. אם אחד המשתמשים יתחכם ובמקום לשלוח הודעת טקסט רגילה הוא ישלח קוד HTML או Javascript, אז תוכן ההודעה שלו ייכנס לתוך דף ה-HTML המוחזר לדפדפן של המשתמשים האחרים. בכך בעצם תהיה לאחד המשתמשים השפעה ישירה על התוכן אותו יקבלו שאר המשתמשים במערכת. באופן זה, ניתן למעשה לשנות את תוכן הדף, להחליף תמונות ואף לבצע מתקפות הרסניות יותר, כגון השתלטות מלאה על דפדפן המשתמש. כל זאת, כאמור, בחסות האפליקציה, שהיא זו שבפועל גרמה לשליחת הקוד בעקיפין אל משתמשיה. המעניין במתקפה זו, הוא בכך שבעוד מרבית המתקפות מכוונות כלפי צד השרת, מתקפה זו מכוונת כלפי המשתמשים. צד השרת משמש רק כ"מתווך" המפיץ את המתקפה ללקוחותיו.

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

מיתוסים נפוצים

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

המיתוס הנפוץ, אשר לשמחתי הולך ונעלם מן העולם, הוא ש- firewall network מגן על אפליקציות. כאמור, firewall network  לא יכול לספק הגנה ברמת האפליקציה, זה לא ייעודו. תפקידו הוא רק לאכוף את כיוון התקשורת, לפי חוקים בסיסיים מהסוג "מאיפה באת, לאן אתה הולך ובאיזה port". זה הכל. כלומר המקסימום ש Network firewall יודע זה שהמשתמש פונה לפורט של האפליקציה, אבל לא מה נשלח אליה.

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

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

אז מה עושים - בדיקת קוד או מבדק חדירה (penetration test)?

הדרך המקובלת לטפל בבעיות אבטחה מגיעה ברוב המקרים מאוחר מדי, כאשר המערכת כבר בסביבת הייצור. אז, בדרך כלל, מבקש הארגון לבצע בדיקת חדירה (penetration test) על מנת לבחון את רמת האבטחה של המערכת. מה קורה כאשר מוצאים ממצא הדורש תיקון? במקרה הטוב, נידרש לבצע שינויים בהגדרות המערכת בלבד. במקרה הפחות טוב, נידרש לאתר את הבעיה בקוד, לכתוב קוד חדש במקומו ולעבור כמובן שוב בדיקות QA (עלול להיווצר מצב של רגרסיה - תיקון במקום מסוים עלול לקלקל משהו טוב במקום אחר), לפני המעבר לסביבת הייצור. במקרה הגרוע, שהוא למרבה הצער, אינו נדיר, תיקון הבעיה דורש גם שינוי תכן (design) אשר ידוע בכל פרויקט הנדסי (ובהנדסת תוכנה בפרט) כחלופה שיש להימנע ממנה בכל מחיר. הסיבה לכך היא ששינוי תכן גורר שינוי מסיבי של הקוד ומכאן נגזרת השפעה על רכיבים אחרים במערכת. ככל שהליקוי מתגלה בשלב מאוחר יותר, עלויות התיקון שלו גבוהות יותר, ולעיתים אף עלולות להגיע למחירים גבוהים מאוד אשר ניתן הה לחסוך על ידי טיפול מקדים. בדיוק כמו בטיפול שיניים...

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

שינוי תפיסה - פיתוח מאובטח כחלק מתהליך הפיתוח

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

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

מה עושים?

כפי שהובן, אבטחת אפליקציות הינה נושא שיש לייחס לו את החשיבות הראויה כבר בשלבי הפרויקט הראשוניים ולהקצות לו משאבים בהתאם. יש לאפיין ולנתח את צרכי האבטחה ולשלב את טכניקות האבטחה -בין אם זה מבדק חדירה, בדיקת קוד, ליווי לפי SDL או אחר, על פי הצרכים שאופיינו. בהעדר הידע הנדרש וללא הכוונה מתאימה, מפתח המערכת לא תמיד יודע בדיוק מה עליו לעשות כדי להתמודד עם הנושא. הסיבה העיקרית לכך היא, שנושא אבטחת המידע האפליקטיבית, פחות מוכר לאנשי המחשוב, לאנשי פיתוח ולמנהלי אבטחת מידע בפרט ומקורות הידע לנושא מצומצמים (הנושא לא נלמד במסגרת אקדמית כגון אוניברסיטה או מכללה). אני מאמין שהדרכה נכונה באבטחת מידע למפתחים יכולה לשפר את המצב בצורה משמעותית. ולכן, הדגש אשר ניתן היום ואשר הוכח כאפקטיבי ביותר לפתרון הבעיה הינו מתן ידע ויצירת המודעות הנדרשת על מנת להתמודד עם אתגרים אלו על הצד הטוב ביותר. ובמקביל לקורסים, על מנת להשאר מעודכן מומלץ למתענינים בנושא להכנס לאתרים כגון אתר הפורום הישראלי לאבטחת מידע וכן באתר www.applicationsecurity.co.il.