fbpx

איך לאבטח אפליקציות ולנהל ממשק API?

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

ע"פ Akamai, קריאות API היוו 83% מכלל תעבורת האינטרנט ב-2019, מכאן ניתן לומר שהאינטרנט של היום שייך ל-API, כלומר, אבטחת יישומי האינטרנט היא כעת גם אבטחת API. על פי דו"ח של גרטנר ליישומי אינטרנט, כ-40% מההתקפות על Web Applications מגיעות דרך ממשקי API במקום ממשקי משתמש. אנליסטים שונים צופים שמספר זה יגדל ל-90% בשנת 2021, ולפי גרטנר עד 2022 השימוש לרעה ב-API יהפוך לווקטור ההתקפה השכיח ביותר.

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

גיא חורש_צילום_בינת
בתמונה: גיא חורש, כותב המאמר. צילום: בינת

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

נקודת תורפה נוספת מצויה בשכבת הנתונים. פורמט היישום עבור כל API הוא פורמט של סידור נתונים מ-XML ל-gRPC (open source high performance Remote Procedure Call ) בינארי. המשמעות היא שניתן לתאר כיצד ניתן להמיר אובייקטים, כגון בקשות יישומים למחרוזות.

בנוסף להתקפות סריאליזציה (serialization attack), המתרחשות כאשר תוקף עובר אובייקט שפרץ בסדרה, שהפכו נפוצות יותר עם ממשקי API, משום שבאבטחת יישומים קיימת פגיעות של XXE (ישות חיצונית XML). פגיעות בביצוע קוד מרחוק ידועה ביישומי Dot Net, אבל מתקיימת גם -GraphQL ו-gRPC. מכאן שהמשמעות היא שפתרונות אבטחה מבוססי חתימה כגון: WAFs, המשמשים להגנת שרתי אינטרנט יתקשו לתת מענה מתאים למקרים המתוארים.

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

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

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

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

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

דילוג לתוכן