ממשק API או בשמו היהודי "ממשק תכנות יישומים" (Application Programming Interface) הינו ממשק המאפשר אינטראקציה (קריאה, כתיבה, מחיקה וכדו') בין מערכות שונות. ממשק API מגדיר את סוגי הבקשות / הקריאות שניתן לבצע, כיצד ניתן לבצע, באיזו שפה ובאילו פרמטרים נדרש להשתמש על מנת לבצע את הפניה למערכת המבוקשת ועוד.
דוגמא קטנה בשביל להקל על ההבנה של הדברים:
נניח שאנחנו רוצים לדעת מה מזג האוויר בלונדון, אנחנו נכנסים לגוגל ורושמים "מזג האוויר בלונדון" ומיד מקבלים את התוצאה הבאה:
גוגל אמנם חולשת על תחומים רבים אבל בנושא מזג האוויר גוגל עדיין נעזרת בחברות צד ג', בשביל לדעת מה מזג האוויר בלונדון גוגל פונה לשירות API של אתרי מזג האוויר שונים ומבקשת מהם את המידע, דוגמא לאחד מהאתרים המספק מידע על מזג האוויר באמצעות API הוא https://openweathermap.org/.
קריאת API מאתר https://openweathermap.org/ עבור תחזית יומית תתבצע באמצעות הפרמטרים הבאים:
Cityid- המזהה של העיר עבורה אנו רוצים לקבל את המידע (מזהה יכול להתקבל בצורת מספר, שם עיר וכדו', בהתאם למה שהוגדר בפרמטרים של ה-API).
API Key- הזיהוי של מבקש השירות.
עבור העיר לונדון לדוגמה, הפניה תתבצע בצורה הבאה:
https:// openweathermap.org/data/2.5/weather?id=2643743&appid=439d4b804bc8187953eb36d2a8c26a02
התשובה תתקבל במבנה שהוגדר מראש ותכיל את הנתונים המבוקשים.
בדרכים דומות ניתן לעשות שימוש ב-API עבור פעולות שונות כגון כתיבת נתונים למערכת (Post), מחיקת נתונים (Delete) ועוד, היכולות רבות ואיתן גם הסכנות.
שירותי API שלא מנוהלים בצורה מאובטחת מהווים איום מהותי לארגון, באמצעות שירותי API לא מאובטחים ניתן לגנוב מידע מהארגון, לשנות מידע, לבצע הונאות, להשבית שירותים ועוד שאר נזקים שנשמח להשאיר מחוץ לפתח ביתנו.
במאמר הזה אני רוצה להציג את הדרכים השונות בכדי לעלות את רמת האבטחה בשירותי API אותם הארגון שלנו מספק ללקוחות, משתמשים ואזרחים. בדרכים אלו אני אציג את ה"מה" ולא את ה"איך", כמו במאמרים הקודמים שלי, אני לא נכנס לפן הטכני של הדברים, המידע במאמר מיועד בעיקר למנהלי אבטחת מידע וכדו' על מנת שיכירו את הטכנולוגיה ואת הדרכים לנהל את הסיכון.
נתחיל:
1. מיפוי- לפני שאנחנו רצים קדימה עם הגדרות אבטחה, בדיקות וכו' וכו' אנחנו חייבים לדעת אילו שירותי API קיימים אצלנו בארגון, לאחר מיפוי של כלל השירותים ההמלצה שלי היא לבצע חלוקה ל-2 קבוצות עיקריות: שירותים פנימיים (לשימוש פנימי בלבד), שירותים חיצוניים (לשימוש על ידי לקוחות, משתמשים, אזרחים).
כמובן שאפשר להמשיך ולקטלג את השירותים השונים לפי פרמטרים נוספים כגון, רמת קריטיות, גישה למערכות עם מידע מזוהה, דרכי גישה לשירות (אתרי אינטרנט, אפליקציות, וכו') ועוד, הכל לפי הצורך הארגוני.
2. הזדהות- ראוי ונכון לספק שירות API למשתמשים מזוהים ולא להשאיר ללא צורך שירותי API המספקים שירות ללא הזדהות, לאחר שמיפיתם את כל השירותים שלכם בהתאם לסעיף הקודם מומלץ לבדוק את נושא ההזדהות לשירותים השונים, להלן נקודות חשובות שראוי ליישם:
- ממשו מנגנון הזדהות בגישה לשירות כך שכל קריאת API תספק את השירות רק למשתמשים מזוהים. (הזדהות באמצעות טוקן, סיסמה וכדו')-
- הגבילו את מספר הניסיונות לביצוע הזדהות מול השירות.-
- הגבילו את מספר הפניות לשירות המגיעות ממשתמש מזוהה (נעילת משתמש לאחרX פניות, שימוש ב-Re-captcha וכדו'), כך תמנעו משיכה של מאגרי נתונים וכדו'.-
- אל תעבירו נתוני הזדהות באופן גלוי על גבי הקריאה של ה-API, אם נחזור לדוגמא הראשונה בנושא מזג האוויר, העברת פרטי הזדהות בצורה לקויה תיראה כך:-
https://openweathermap.org/data/2.5/weather?id=2643743&user=Erez&password=1234
3. הרשאות- לא כל משתמש מזוהה רשאי לגשת לכל המידע המונגש ע"י שירות API, ניהול הרשאות הוא הכרחי בניהול קריאות API, עלינו לוודא כי המשתמש המזוהה אכן רשאי לגשת לנתונים בין אם זה לקריאת נתונים וקל וחומר לכתיבת נתונים או מחיקתם.
ניהול ההרשאות לנתונים המונגשים באמצעות API צריך להתבצע עד למינימום האפשרי ובדיקת הרשאות צריכה להיות ברמת האובייקט הנדרש (Object Level Authorization).
חשוב לשים לב להמלצות הבאות בנושא זה:
- עיקרון מינימום ההרשאות
- ניהול הרשאות לא לאובייקטים ולמאגרים ספציפיים אלא גם על אופן השימוש במאגר, משתמש שצריך לבצע רק קריאת נתונים (Get) לא יוכל לבצע כתיבת נתונים (Post)
- שימוש בשירותי API צריך להיות מוגדר כאסור עבור כולם (Deny) למעט אלו שיש להם הרשאה.
- שירותי API המיועדים לפעולות ניהול כגון (יצירת אובייקטים חדשים, מחיקת אובייקטים קיימים וכדו') יהיו נגישים רק מכתובות פנימיות או לאחר זיהוי חזק (זיהוי רב שלבי-MFA). או גם וגם :)
4. חשיפת מידע רגיש- ישנן שירותי API שניגשים למאגרי מידע רגישים על מנת לבצע את הפעולה הנדרשת (קריאה, כתיבה וכו'), חשוב לוודא כי המידע הרגיש מסונן עוד בצד השרת ולא בצד הקליינט, לדוגמא, משתמש מבקש לקבל נתונים אודות טיפולים שרכב מסוים ביצע במוסך "רכב בענן", מוסך "רכב בענן" הינו מוסך מתקדם טכנולוגית ומנגיש שירות API ללקוחות רשומים המאפשר בהקשת מספר רכב לקבל את תאריכי הטיפולים האחרונים של הרכב. שימו לב, רק תאריכים, ללא מידע מזוהה רגיש.
ה-API פונה למאגר של הרכבים ושולף את נתוני הרכב המבוקש, אבל, לא רק את תאריכי הטיפולים הוא שולף אלא את כל הנתונים על הרכב הכוללים מידע מזוהה על בעל הרכב, עלויות טיפולים, תאונות וכו', לפני שהמידע מגיע למשתמש, בצד הקליינט, המידע מסונן ומציג למבקש השירות רק את תאריכי הטיפולים האחרונים.
לכאורה הכל בסדר, המשתמש רואה מה שהוא צריך לראות אבל מתחת למכסה המנוע מסתתר מאגר מידע שלם שעם קצת ידע ורצון יהיה חשוף לגורמים שונים עוד לפני הסינון שבוצע בצד הקליינט.
ההמלצות בנושא זה הן:
- אין לבצע סינון נתונים בצד הקליינט, כל בקשת API צריכה לעבור סינון בצד השרת ורק אז לצאת לכיוון הקליינט.
- ניטור המידע שעובר לכיוון המשתמש, יש לוודא שהמידע שעובר הוא המידע המינימלי בהתאם לבקשה ולהרשאות המשתמש.
5. Ddos- בקשות API צורכות משאבים, זיכרון, מעבד, תקשורת ועוד, צריכת המשאבים משתנה כמובן בהתאם לסוג הבקשה, גודל הבקשה, כמות הבקשות וכו', כמות גדולה של בקשות API בו זמנית יכולה לגרום לשיבוש הפעילות ולעיתים אף להשבתה של השירות. בכדי למנוע מצב זה עלינו להגדיר הגבלה (Rate limit) על שירותי ה-API שלנו.
ההגבלה יכולה להתבצע ברמות שונות, לדוגמא:
- הגבלת משאבים (צריכה מקסימלית של כח עיבוד, זיכרון וכו')
- הגבלת פניות של משתמש ל-X פניות ב-Y זמן.
- הגבלת כמות וגדלי הנתונים שה-API מחזיר למשתמש.
6. שינוי נתונים- לשירותי API יש תבנית יחסית ברורה ומוגדרת, גם למשתמש הממוצע יהיה קל להבין פחות או יותר את התבנית בה נשלחים הנתונים לשירות. לרוב, בקשות API נשלחות בתבנית דומה הכוללת את הכתובת של השירות, סוג הקריאה והפרמטרים הנדרשים.
אם נחזור רגע לדוגמא של הרכבים שהבאתי בסעיף 4, כשאני מבצע קריאה עבור מספר רכב אני אזין כפרמטר את מספר הרכב המבוקש (נניח ששם הפרמטר הוא CarID) ואקבל בתמורה את הנתונים על הרכב. אבל מה קורה אם משתמש שמכיר את התבנית של שירות ה-API שלי משנה את הבקשה מקריאת Get לקריאת Post ומשנה את ה-CarID? מספר הרכב במאגר הרכבים ישתנה, ואם נלך צעד קדימה, אותו משתמש משנה את ה-CarID למספר הרכב הפרטי שלו ומוסיף פרמטר נוסף הקיים בשירות בשם CashBalacnce=10,000 המגדיר את סכום האשראי הקיים עבורו במוסך (מוסך מתקדם טכנולוגית, כבר אמרנו....)
מה שקרה כאן הוא שאותו גורם עושה שימוש בשירות ה-API שנועד במקור למשיכת נתוני רכב, הוא משנה ומוסיף פרמטרים בהתאם ובכך כותב נתונים חדשים למערכת שלא היו קיימים לפני כן.
אז נכון, זה לא כזה פשוט כי צריך להכיר את הפרמטרים של ה-API שלנו ואת התבנית בה הנתונים נשלחים אבל היי, להאקר יש את כל הזמן שבעולם ופרצה קוראת לגנב אז אל תהיו אופטימיים מדי.
ההמלצות בכדי למנוע מקרים מעין אלו הן:
- הגדירו פרמטרים ככאלו שאינם ניתנים לעריכה מצד הקליינט- Blacklist (או במונח העכשווי - Denylist)
- הגדירו Whitelist (או במונח העכשווי - Allowlist) של פרמטרים הניתנים לעריכה ע"י המשתמש.
- אם אפשרי הגדירו סכמה המגדירה כיצד צריכה להתקבל קריאה מהמשתמש ואכפו את תבנית הסכמה בכל קריאה.
7. הזרקת מידע זדוני- המתקפה הידועה לשמצה שצועדת איתנו כבר שנים רבות ולא רק ב-SQL זו מתקפת הזרקה (Injection). בשירותי API כמו בהרבה שירותים אחרים מידע מגיע מצד הקליינט לצד השרת ועם הידע המתאים תוקף יכול להזריק קוד זדוני דרך שירות ה-API שאנו מספקים.
פוטנציאל הנזק הוא נרחב, החל מגניבת נתונים ועד שיבוש מערכות, השבתת שירותים ועוד, אם נחזור שוב לדוגמא הראשונה שהצגתי בהתחלה בנושא מזג האוויר, השרת מצפה לקבל CityID כמספר המייצג את המדינה עבורה אנו רוצים לקבל תחזית, אבל אם לא מתבצע אימות לנתונים המועברים לשרת אז התוקף יכול להזין במקום את מספר המדינה סקריפט זדוני על מנת שזה ירוץ בצד השרת וישבש את השירות, יגנוב נתונים וכו'
בכדי להימנע ממצבים כאלו בשירות ה- API שלנו ההמלצות הן:
- בצעו אימות לנתונים שמתקבלים מקריאות ה-API השונות.
- הגבילו את הפרמטרים השונים בהתאם לסוג הנתון (מספרים, אותיות, וכו')
- הגבילו את כמות התווים המגיעים בפרמטרים השונים.
- הגדירו Denylist לתווים חריגים כגון "> <" וכדו', או לכל הפחות בצעו קידוד לתווים אלו לפני קליטתם בשרת.
8. תחזוקה, ניטור ובקרה- הסעיף הזה נכון לכל שירות ולא רק לשירותי API, אני לא ארחיב כאן על החשיבות של הנושא כי המאמר הפך להיות ארוך ממה שתכננתי גם ככה:
ההמלצות בנושא זה הן:
- צרו לוג המכיל פרטים רבים ככל האפשר לכל קריאת API, מי ניגש, לאן ניגש, איזה שירות הוא ביקש, מתי, מאיפה, וכו'.
- נטרו את הלוגים האלו באמצעות כלים חכמים שידעו להתריע במידת הצורך (הזדהות חוזרת שגויה לשירות, קריאה שנופלת בשל אימות נתונים לקוי וכו')
- אם שירות API יצא משימוש, הוחלף בשירות חדש, קיבל עדכון גרסה וכדו', אל תשאירו את השירות הישן נגיש למשתמשים, לא בצורה גלויה כמובן אך גם לא בצורה מוסתרת. שירות שיצא לפנסיה יוצא מהרשת הארגונית או נמחק.
מה הלאה?
אז איך מיישמים את כל ההמלצות האלה תכלס? ברוב הארגונים אין שירות API בודד, כמות ה-API בארגון גדול יכולה להגיע לעשרות ואף מאות שירותים שונים, להתחיל ליישם את כל ההמלצות האלה בכל שירות זו גזירה שאין הארגון יכול לעמוד בה, אז מה כן עושים?
API Gateway
בכדי להקל על הניהול של כל שירותי ה-API מומלץ להשתמש ב-Api Gateway, התפקיד של API Gateway הוא להוות שער הכניסה לכל קריאות ה-API בארגון ולנתב אותן בהתאם, בהיותו שער לכל פניות ה-API ניתן לנהל את כל הגדרות האבטחה (הזדהות, הרשאות וכו') במיקום מרכזי אחד.
מלבד הגדרות אבטחה ניתן לעשות שימוש ב-Api Gateway לדברים נוספים כגון לספק מידע סטטי למשתמשים, לשמש כ-Load Balancer עבור השירותים השונים, להחזיק Cache בשביל לספק מידע באופן מהיר יותר, להמיר פרוטוקולים נכנסים ויוצאים ועוד שימושים רבים.
כיום, כל ספקי הענן הגדולים מספקים שירות API Gateway שניתן להגדיר בקלות, כמובן שניתן לממש את Api gateway לא רק בענן אלא גם On-Premise והשירות ניתן על ידי מספר ספקים (IBM, CA ועוד)
בהצלחה!
מאת: ארז דסה, Chief Information Security Officer רשות המסים בישראל
ממשק API או בשמו היהודי "ממשק תכנות יישומים" (Application Programming Interface) הינו ממשק המאפשר אינטראקציה (קריאה, כתיבה, מחיקה וכדו') בין מערכות שונות. ממשק API מגדיר את סוגי הבקשות / הקריאות שניתן לבצע, כיצד ניתן לבצע, באיזו שפה ובאילו פרמטרים נדרש להשתמש על מנת לבצע את הפניה למערכת המבוקשת ועוד.
דוגמא קטנה בשביל להקל על ההבנה של הדברים:
נניח שאנחנו רוצים לדעת מה מזג האוויר בלונדון, אנחנו נכנסים לגוגל ורושמים "מזג האוויר בלונדון" ומיד מקבלים את התוצאה הבאה:
גוגל אמנם חולשת על תחומים רבים אבל בנושא מזג האוויר גוגל עדיין נעזרת בחברות צד ג', בשביל לדעת מה מזג האוויר בלונדון גוגל פונה לשירות API של אתרי מזג האוויר שונים ומבקשת מהם את המידע, דוגמא לאחד מהאתרים המספק מידע על מזג האוויר באמצעות API הוא https://openweathermap.org/.
קריאת API מאתר https://openweathermap.org/ עבור תחזית יומית תתבצע באמצעות הפרמטרים הבאים:
Cityid- המזהה של העיר עבורה אנו רוצים לקבל את המידע (מזהה יכול להתקבל בצורת מספר, שם עיר וכדו', בהתאם למה שהוגדר בפרמטרים של ה-API).
API Key- הזיהוי של מבקש השירות.
עבור העיר לונדון לדוגמה, הפניה תתבצע בצורה הבאה:
https:// openweathermap.org/data/2.5/weather?id=2643743&appid=439d4b804bc8187953eb36d2a8c26a02
התשובה תתקבל במבנה שהוגדר מראש ותכיל את הנתונים המבוקשים.
בדרכים דומות ניתן לעשות שימוש ב-API עבור פעולות שונות כגון כתיבת נתונים למערכת (Post), מחיקת נתונים (Delete) ועוד, היכולות רבות ואיתן גם הסכנות.
שירותי API שלא מנוהלים בצורה מאובטחת מהווים איום מהותי לארגון, באמצעות שירותי API לא מאובטחים ניתן לגנוב מידע מהארגון, לשנות מידע, לבצע הונאות, להשבית שירותים ועוד שאר נזקים שנשמח להשאיר מחוץ לפתח ביתנו.
במאמר הזה אני רוצה להציג את הדרכים השונות בכדי לעלות את רמת האבטחה בשירותי API אותם הארגון שלנו מספק ללקוחות, משתמשים ואזרחים. בדרכים אלו אני אציג את ה"מה" ולא את ה"איך", כמו במאמרים הקודמים שלי, אני לא נכנס לפן הטכני של הדברים, המידע במאמר מיועד בעיקר למנהלי אבטחת מידע וכדו' על מנת שיכירו את הטכנולוגיה ואת הדרכים לנהל את הסיכון.
נתחיל:
1. מיפוי- לפני שאנחנו רצים קדימה עם הגדרות אבטחה, בדיקות וכו' וכו' אנחנו חייבים לדעת אילו שירותי API קיימים אצלנו בארגון, לאחר מיפוי של כלל השירותים ההמלצה שלי היא לבצע חלוקה ל-2 קבוצות עיקריות: שירותים פנימיים (לשימוש פנימי בלבד), שירותים חיצוניים (לשימוש על ידי לקוחות, משתמשים, אזרחים).
כמובן שאפשר להמשיך ולקטלג את השירותים השונים לפי פרמטרים נוספים כגון, רמת קריטיות, גישה למערכות עם מידע מזוהה, דרכי גישה לשירות (אתרי אינטרנט, אפליקציות, וכו') ועוד, הכל לפי הצורך הארגוני.
2. הזדהות- ראוי ונכון לספק שירות API למשתמשים מזוהים ולא להשאיר ללא צורך שירותי API המספקים שירות ללא הזדהות, לאחר שמיפיתם את כל השירותים שלכם בהתאם לסעיף הקודם מומלץ לבדוק את נושא ההזדהות לשירותים השונים, להלן נקודות חשובות שראוי ליישם:
- ממשו מנגנון הזדהות בגישה לשירות כך שכל קריאת API תספק את השירות רק למשתמשים מזוהים. (הזדהות באמצעות טוקן, סיסמה וכדו')-
- הגבילו את מספר הניסיונות לביצוע הזדהות מול השירות.-
- הגבילו את מספר הפניות לשירות המגיעות ממשתמש מזוהה (נעילת משתמש לאחרX פניות, שימוש ב-Re-captcha וכדו'), כך תמנעו משיכה של מאגרי נתונים וכדו'.-
- אל תעבירו נתוני הזדהות באופן גלוי על גבי הקריאה של ה-API, אם נחזור לדוגמא הראשונה בנושא מזג האוויר, העברת פרטי הזדהות בצורה לקויה תיראה כך:-
https://openweathermap.org/data/2.5/weather?id=2643743&user=Erez&password=1234
3. הרשאות- לא כל משתמש מזוהה רשאי לגשת לכל המידע המונגש ע"י שירות API, ניהול הרשאות הוא הכרחי בניהול קריאות API, עלינו לוודא כי המשתמש המזוהה אכן רשאי לגשת לנתונים בין אם זה לקריאת נתונים וקל וחומר לכתיבת נתונים או מחיקתם.
ניהול ההרשאות לנתונים המונגשים באמצעות API צריך להתבצע עד למינימום האפשרי ובדיקת הרשאות צריכה להיות ברמת האובייקט הנדרש (Object Level Authorization).
חשוב לשים לב להמלצות הבאות בנושא זה:
- עיקרון מינימום ההרשאות
- ניהול הרשאות לא לאובייקטים ולמאגרים ספציפיים אלא גם על אופן השימוש במאגר, משתמש שצריך לבצע רק קריאת נתונים (Get) לא יוכל לבצע כתיבת נתונים (Post)
- שימוש בשירותי API צריך להיות מוגדר כאסור עבור כולם (Deny) למעט אלו שיש להם הרשאה.
- שירותי API המיועדים לפעולות ניהול כגון (יצירת אובייקטים חדשים, מחיקת אובייקטים קיימים וכדו') יהיו נגישים רק מכתובות פנימיות או לאחר זיהוי חזק (זיהוי רב שלבי-MFA). או גם וגם :)
4. חשיפת מידע רגיש- ישנן שירותי API שניגשים למאגרי מידע רגישים על מנת לבצע את הפעולה הנדרשת (קריאה, כתיבה וכו'), חשוב לוודא כי המידע הרגיש מסונן עוד בצד השרת ולא בצד הקליינט, לדוגמא, משתמש מבקש לקבל נתונים אודות טיפולים שרכב מסוים ביצע במוסך "רכב בענן", מוסך "רכב בענן" הינו מוסך מתקדם טכנולוגית ומנגיש שירות API ללקוחות רשומים המאפשר בהקשת מספר רכב לקבל את תאריכי הטיפולים האחרונים של הרכב. שימו לב, רק תאריכים, ללא מידע מזוהה רגיש.
ה-API פונה למאגר של הרכבים ושולף את נתוני הרכב המבוקש, אבל, לא רק את תאריכי הטיפולים הוא שולף אלא את כל הנתונים על הרכב הכוללים מידע מזוהה על בעל הרכב, עלויות טיפולים, תאונות וכו', לפני שהמידע מגיע למשתמש, בצד הקליינט, המידע מסונן ומציג למבקש השירות רק את תאריכי הטיפולים האחרונים.
לכאורה הכל בסדר, המשתמש רואה מה שהוא צריך לראות אבל מתחת למכסה המנוע מסתתר מאגר מידע שלם שעם קצת ידע ורצון יהיה חשוף לגורמים שונים עוד לפני הסינון שבוצע בצד הקליינט.
ההמלצות בנושא זה הן:
- אין לבצע סינון נתונים בצד הקליינט, כל בקשת API צריכה לעבור סינון בצד השרת ורק אז לצאת לכיוון הקליינט.
- ניטור המידע שעובר לכיוון המשתמש, יש לוודא שהמידע שעובר הוא המידע המינימלי בהתאם לבקשה ולהרשאות המשתמש.
5. Ddos- בקשות API צורכות משאבים, זיכרון, מעבד, תקשורת ועוד, צריכת המשאבים משתנה כמובן בהתאם לסוג הבקשה, גודל הבקשה, כמות הבקשות וכו', כמות גדולה של בקשות API בו זמנית יכולה לגרום לשיבוש הפעילות ולעיתים אף להשבתה של השירות. בכדי למנוע מצב זה עלינו להגדיר הגבלה (Rate limit) על שירותי ה-API שלנו.
ההגבלה יכולה להתבצע ברמות שונות, לדוגמא:
- הגבלת משאבים (צריכה מקסימלית של כח עיבוד, זיכרון וכו')
- הגבלת פניות של משתמש ל-X פניות ב-Y זמן.
- הגבלת כמות וגדלי הנתונים שה-API מחזיר למשתמש.
6. שינוי נתונים- לשירותי API יש תבנית יחסית ברורה ומוגדרת, גם למשתמש הממוצע יהיה קל להבין פחות או יותר את התבנית בה נשלחים הנתונים לשירות. לרוב, בקשות API נשלחות בתבנית דומה הכוללת את הכתובת של השירות, סוג הקריאה והפרמטרים הנדרשים.
אם נחזור רגע לדוגמא של הרכבים שהבאתי בסעיף 4, כשאני מבצע קריאה עבור מספר רכב אני אזין כפרמטר את מספר הרכב המבוקש (נניח ששם הפרמטר הוא CarID) ואקבל בתמורה את הנתונים על הרכב. אבל מה קורה אם משתמש שמכיר את התבנית של שירות ה-API שלי משנה את הבקשה מקריאת Get לקריאת Post ומשנה את ה-CarID? מספר הרכב במאגר הרכבים ישתנה, ואם נלך צעד קדימה, אותו משתמש משנה את ה-CarID למספר הרכב הפרטי שלו ומוסיף פרמטר נוסף הקיים בשירות בשם CashBalacnce=10,000 המגדיר את סכום האשראי הקיים עבורו במוסך (מוסך מתקדם טכנולוגית, כבר אמרנו....)
מה שקרה כאן הוא שאותו גורם עושה שימוש בשירות ה-API שנועד במקור למשיכת נתוני רכב, הוא משנה ומוסיף פרמטרים בהתאם ובכך כותב נתונים חדשים למערכת שלא היו קיימים לפני כן.
אז נכון, זה לא כזה פשוט כי צריך להכיר את הפרמטרים של ה-API שלנו ואת התבנית בה הנתונים נשלחים אבל היי, להאקר יש את כל הזמן שבעולם ופרצה קוראת לגנב אז אל תהיו אופטימיים מדי.
ההמלצות בכדי למנוע מקרים מעין אלו הן:
- הגדירו פרמטרים ככאלו שאינם ניתנים לעריכה מצד הקליינט- Blacklist (או במונח העכשווי - Denylist)
- הגדירו Whitelist (או במונח העכשווי - Allowlist) של פרמטרים הניתנים לעריכה ע"י המשתמש.
- אם אפשרי הגדירו סכמה המגדירה כיצד צריכה להתקבל קריאה מהמשתמש ואכפו את תבנית הסכמה בכל קריאה.
7. הזרקת מידע זדוני- המתקפה הידועה לשמצה שצועדת איתנו כבר שנים רבות ולא רק ב-SQL זו מתקפת הזרקה (Injection). בשירותי API כמו בהרבה שירותים אחרים מידע מגיע מצד הקליינט לצד השרת ועם הידע המתאים תוקף יכול להזריק קוד זדוני דרך שירות ה-API שאנו מספקים.
פוטנציאל הנזק הוא נרחב, החל מגניבת נתונים ועד שיבוש מערכות, השבתת שירותים ועוד, אם נחזור שוב לדוגמא הראשונה שהצגתי בהתחלה בנושא מזג האוויר, השרת מצפה לקבל CityID כמספר המייצג את המדינה עבורה אנו רוצים לקבל תחזית, אבל אם לא מתבצע אימות לנתונים המועברים לשרת אז התוקף יכול להזין במקום את מספר המדינה סקריפט זדוני על מנת שזה ירוץ בצד השרת וישבש את השירות, יגנוב נתונים וכו'
בכדי להימנע ממצבים כאלו בשירות ה- API שלנו ההמלצות הן:
- בצעו אימות לנתונים שמתקבלים מקריאות ה-API השונות.
- הגבילו את הפרמטרים השונים בהתאם לסוג הנתון (מספרים, אותיות, וכו')
- הגבילו את כמות התווים המגיעים בפרמטרים השונים.
- הגדירו Denylist לתווים חריגים כגון "> <" וכדו', או לכל הפחות בצעו קידוד לתווים אלו לפני קליטתם בשרת.
8. תחזוקה, ניטור ובקרה- הסעיף הזה נכון לכל שירות ולא רק לשירותי API, אני לא ארחיב כאן על החשיבות של הנושא כי המאמר הפך להיות ארוך ממה שתכננתי גם ככה:
ההמלצות בנושא זה הן:
- צרו לוג המכיל פרטים רבים ככל האפשר לכל קריאת API, מי ניגש, לאן ניגש, איזה שירות הוא ביקש, מתי, מאיפה, וכו'.
- נטרו את הלוגים האלו באמצעות כלים חכמים שידעו להתריע במידת הצורך (הזדהות חוזרת שגויה לשירות, קריאה שנופלת בשל אימות נתונים לקוי וכו')
- אם שירות API יצא משימוש, הוחלף בשירות חדש, קיבל עדכון גרסה וכדו', אל תשאירו את השירות הישן נגיש למשתמשים, לא בצורה גלויה כמובן אך גם לא בצורה מוסתרת. שירות שיצא לפנסיה יוצא מהרשת הארגונית או נמחק.
מה הלאה?
אז איך מיישמים את כל ההמלצות האלה תכלס? ברוב הארגונים אין שירות API בודד, כמות ה-API בארגון גדול יכולה להגיע לעשרות ואף מאות שירותים שונים, להתחיל ליישם את כל ההמלצות האלה בכל שירות זו גזירה שאין הארגון יכול לעמוד בה, אז מה כן עושים?
API Gateway
בכדי להקל על הניהול של כל שירותי ה-API מומלץ להשתמש ב-Api Gateway, התפקיד של API Gateway הוא להוות שער הכניסה לכל קריאות ה-API בארגון ולנתב אותן בהתאם, בהיותו שער לכל פניות ה-API ניתן לנהל את כל הגדרות האבטחה (הזדהות, הרשאות וכו') במיקום מרכזי אחד.
מלבד הגדרות אבטחה ניתן לעשות שימוש ב-Api Gateway לדברים נוספים כגון לספק מידע סטטי למשתמשים, לשמש כ-Load Balancer עבור השירותים השונים, להחזיק Cache בשביל לספק מידע באופן מהיר יותר, להמיר פרוטוקולים נכנסים ויוצאים ועוד שימושים רבים.
כיום, כל ספקי הענן הגדולים מספקים שירות API Gateway שניתן להגדיר בקלות, כמובן שניתן לממש את Api gateway לא רק בענן אלא גם On-Premise והשירות ניתן על ידי מספר ספקים (IBM, CA ועוד)
בהצלחה!
מאת: ארז דסה, Chief Information Security Officer רשות המסים בישראל
לפרטים נוספים ויצירת קשר עם נציג אורקל
הודעתך לא התקבלה - נסה שוב מאוחר יותר