ממשקי API (ממשק תכנות יישומים) הם הטכנולוגיה המאפשרת לארגונים לגדול עסקית בקצב מהיר, בפשטות ובשפות שונות. ממשקי API מאפשרים למפתחים ליצור ארכיטקטורה פתוחה לשיתוף פונקציונליות ונתונים בין יישומים. ממשקי API הם כמו חלונות לאפליקציה - צינור ישיר המוביל היישר לפונקציונליות הליבה והנתונים השוכנים בלב האפליקציה.
ממשקי API מעניקים למפתחים בצד הלקוח - מפתחים לגיטימיים וגם האקרים פוטנציאליים - גישה הרבה יותר מדויקת לגישה יישום מאשר WEB אינטרנט טיפוסי. הסיבה לכך היא החיבור הישיר למערכות הפנימיות של הארגון הפנימיות, שמאובטחות יחסית (כאלה השוכנות בביטחה ב- DMZ), כל הדרך אל אפליקציית קליינט באינטרנט.
כיצד ממשקי API מגדילים את הסיכון של ארגון?
הבעיה עם ממשקי API היא שלעיתים קרובות הם מספקים מפת דרכים המתארת את היישום הבסיסי של האפליקציה - פרטים שאחרים יסתירו תחת שכבות של פונקציונליות של אפליקציות באינטרנט. זה יכול להעניק להאקרים רמזים חשובים שיכולים להוביל לווקטורי התקפה שלא היינו מודעים אליהם.
ממשקי API נוטים להיות מאוד ברורים ומתעדים את עצמם במיטבם, תוך שהם מספקים תובנות לגבי אובייקטים פנימיים ואפילו מבנה בסיסי פנימי - הכל מידעים בעלי חשיבות עבור האקרים. הגדלת מספר השיחות הפוטנציאליות מגדילה גם את שטח ההתקפה. כלומר, ככל שיהיו יותר ממשקי API ההאקר ייהנה מעוד הרבה אינפורמציה שבה הוא יוכל להשתמש כדי ליצור את התקיפה האידיאלית. הסיכון גדל עם ההזדמנות.
התקפה באמצעות מניפולציה של פרמטרים
התקפות-פרמטר הנפוצות ביותר הן ניסיון הזרקת קוד (INJECTION SQL) למערכת על-ידי מניפולציה של קריאות, שיאפשרו לתוקף ללמוד על הארכיטקטורה הפנימית ודפוס פעולה של האפליקציה ב- Data Base (מסדי הנתונים). בדרך כלל, אלה נובעים מכך שמפתחים לא בודקים בקפידה קלט ליישום. בניגוד ליישומי אינטרנט רבים, ממשקי API מזהים לעיתים קרובות בבירור את השימוש הבסיסי של הפרמטר בשמו, ומציעים רמזים מפתים, אפילו לתוקף המקרי.
התקפות פרמטרים בהחלט אינן חדשות. האינטרנט מנוצל במשך שנים באמצעות וקטור זה. אבל הם נמצאים במגמת עלייה בממשק ה- API בעולם מכיוון שמפתחים רבים מזניחים את קינפוג הבקשות על חשבון מהירות הפיתוח, מה שהיה מיושם באופן אוטומטי על-ידי פלטפורמות WEB. אותו סיכון קשור לממשקי API, וצריך לנקוט באותם אמצעי זהירות כדי למזער את האיום הנ"ל.
שלב ראשון: אימות פרמטרים
השלב הראשון ליישום ממשק API עמיד הוא סניטציה של כל הנתונים הנכנסים כדי לאשר שהם תקפים ולא יגרמו נזק. ההגנה היעילה היחידה מפני מניפולציה של פרמטרים והתקפות הזרקה היא לאמת את כל הנתונים הנכנסים כנגד "סכמה" קפדנית. סכמה הינה למעשה תיאור של מה שנחשבים לתשומות המותרות למערכת. אימות הסכימה צריך להיות מגביל ככל האפשר של טווחי הנתונים המותרים להכנסה. האפשרות היחידה ליצור סכמות אמיתיות היום הנה בצורה אוטומטית, על ידי לימוד בזמן אמת של ה-API.
סכימות שנבנו בעבודת יד ורשימות לבנות אינן יעילות ומצריכות שעות עבודה אין-סופיות של אנשי הפיתוח. לימוד מבוסס AI הינו הפתרון המועדף במצבים שכאלה.
גילוי איומים בזמן אמת
אימות סכימה בצורה אוטומטית יכול להגן מפני התקפות הזרקה רבות, אך יש לקחת בחשבון גם צורך בהגנה מפני התקפות נפוצות הנכללות ברשימת ה- OWASP 10.
תקיפות עשויות ללבוש צורות אחרות, כגון מניעת שירות (DDoS) ברמת האפליקציה. חייבים לקחת בחשבון שמתקפות DDoS מנצלות פרמטרים, הודעות גדולות מאוד, מבני נתונים שבנויים בכבדות, או מבני נתונים מורכבים מדי, שיכולים לגרום למתקפת מניעת שירות יעילה הצורכת ללא צורך משאבים בשרת API.
גם כאן נדרשות הגנות מבוססות AI המסוגלות להתמודד עם מצבים "אפורים" המאפיינים התקפות מסוג זה.
לסיכום, ממשקי API מייצגים הזדמנות נהדרת עבור הארגון לשלב יישומים במהירות ובקלות. אבל ממשקי API יכולים להיות חרב פיפיות: מבטיחים זריזות, אך בו בזמן מגדילים את הסיכון. ארגון חייב להתייחס לאבטחת API כאתגר ארכיטקטוני הרבה לפני שמתרחש פיתוח כלשהו. כך הוא יוכל לקצור את היתרונות של פריצת דרך טכנולוגית זו בצורה בטוחה. הגנות יעילות מבוססות AI הינן קו החזית החדש.
ישראל גרוס - הכותב הוא שותף-מייסד שלL7 Defense ומנהל קהילת סייבר Israel Cyber Group. הפורום נוסד ב-2015 מתוך מטרה לייצר שיתוף פעולה והעברת מידע בין חוקרים, מנהלי אבט"מ, סטארט-אפים וחברות מובילות בתעשיית הסייבר. חברי הפורום נפגשים אחת לכמה חודשים ומשתפים פעולה בצורה אקטיבית.
