12383 מאמרים - מנוע לחיפוש מאמרים - פרסום מאמרים חינם

נושא המאמר: אבטחת אפליקציות – החוליה החלשה באבטחת המידע
מאת: ארז מטולה   שמור מאמר למועדפים

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


רקע

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

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

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

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

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

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



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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מה עושים?

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