אתגרי אבטחה בעולם ה-API

כתב: עודד צור, מנהל תחום אבטחה ב-CA Technologies

לפני מספר שנים כתבתי מאמר שעסק בזהות (Identity) כגבול (Perimeter) חדש. עיקרו היה שאם עד אותו יום, הגבול עליו סמכנו הייתה הרשת, הרי שבעידן העבודה מהבית, ה-BYOD (ר"ת Bring Your Own device) והענן גבול זה טושטש כל כך, עד שמבחינת אבטחה קשה לסמוך רק עליו, ואילו הגבול האמיתי היא הזהות.

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

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

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

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

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

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

ה-API הוא חלון לאפליקציה כולה. פנייה מוגברת אליו ושימוש מופרז בו יכולים להוות סיכון מסוג של DoS – Denial Of Service.

שינוי נוסף הוא Granularity boundary: אם פעם, בעולם ה-Web, הדפדפן פנה לשרת HTTP וזה פנה לשרת אפליקציה פנימי בתוך הארגון, הפנייה ל-API ישירות היא ישירה לשרת האפליקציה, כלומר – גבול הממשק זז לכיוון האפליקציה והמשתמש.

בבואנו להגן על הארגון, יש לקחת בחשבון שלושה וקטורים להתקפה: פרמטרים, זהות ו Man in the Middle.

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

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

Man in the middle: ניצול הצדדים, האפליקציה וה-API, על ידי ניצול התווך שביניהם. גם כאן הסכנה אינה חדשה, אך הסיכון גובר בשל המיקום הבעייתי של ה-API.

מה ניתן לעשות על מנת להקטין את הסיכונים הנ"ל?

ואלידציה של השדר
בדיקה וניקוי של כל שדר API: בדיקות סכימה, בדיקות Type של פרמטרים, תחומי הנתונים ואם אפשר White listing. רצוי לבדוק מול סכימה שנבנתה והותאמה ידנית, במקרה של JSON, שהוא פשוט יותר לבנייה והבנה וקל יותר להגן עליו.

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

שימוש ב-SSL – נושא מובן מאליו.

בדיקות הזדהות והרשאה
בדיקות בהיבט הרחב, הכוללות בדיקות IP, זמנים, זיהוי Device, מיקום גיאוגרפי וכו'…

שימוש ב-OAuth כמודל זיהוי בהתבסס על ספריות קיימות ומובנות במוצרים המתמחים בכך.

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

למידע נוסף לחצו כאן.