מה זה API?

 API הוא קיצור של Application Programming Interface או בעברית "ממשק תכנות יישומים".

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

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

למה משמש API

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

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

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

סכנות ל-API

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

Inadequate validation – ממשק יכול להיות מנוצל על ידי חולשת בפרוטוקול האתר. אם תשימו לב, כאשר אתם גולשים באתרי אינטרנט יש לאתרים קידומת של:

• WWW
• HTTP
• HTTPS

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

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

כדי להגן על ממשק ה-API וודאו כי תעודת ה-SSL בתוקף.

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

Lack of Resources & Rate Limiting- פגיעות נפוצה מאוד היא שאין הגבלה לכמות הבקשות שניתן לשלוח, דוגמא לכך היא מתקפת brute force בה אנו יכולים לשלוף שמות משתמשים וסיסמאות, או שליחת אלפי בקשות בשניה מה שיגרום למניעת שירות ו/או קריסת שירות ה-API. 

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

כאשר כן ידוע משהו על הסיסמה, למשל שהיא תאריך, אפשר להריץ את כל התאריכים האפשריים באופן סדרתי. 

אפשר גם להריץ את כל הסיסמאות הכי נפוצות. 

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

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

Lack of security – ללא אמצעי אבטחה כמו Transport layer security) TLS) ואימות מבוקר קיים פתח פגיע עבור התוקפים.

 User and Password Enumeration- לפעמים ממשקי API "מדברים" וחושפים יותר מידע ממה שהם צריכים. בתרחיש זה, כאשר משתמש ישלח בקשה, ה-API יחזיר בתשובה מידע הכולל פרמטרים רבים מעבר לנדרש. 

מבדקי חדירות ל-API

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

הבדיקות נעשות על ידי כלים אוטומטים וידניים, לדוגמא:

Burp suite-ספריית כלים רחבה לבחינת מערך הגנת הסייבר של אפליקציות כשהפ'יצר הראשי בו הוא ה- Burp Proxy שמאפשר לבודקי חדירות לבצע מתקפת MITM- כאשר האקר ממקם את עצמו בין המשתמש לספק השירות, בין אם כדי "להאזין לתקשורת" ביניהם או בין אם כדי להתחזות לאחד מהצדדים. מטרת המתקפה היא לגנוב מידע אישי- פרטי כרטיס אשראי, סיסמאות ומידע על חשבונות- ולרוב מתרחש בתקשורת בין משתמשים לחברות פיננסיות, SaaS, חנויות אינטרנטיות ואתרים שיש בהם צורך בכניסה לחשבון.

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

הבדיקה כוללת ומכסה את:

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

בדיקת Rate Limit בה אנו רואים האם ה-API חסין מפני מתקפות כמו:

• Brute Force
•  DDOS
• מתקפת XSS
• הזרקת SQL

ממצאים מבדיקת חדירות ל- API

Information disclosure

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

בדוגמא הבאה נראה כיצד Misconfiguration פשוט כמו להשאיר את מצב  DEBUG (כלומר מצב של Testing שבו ה-API מחזיר יותר מידע) מופעל יכול להוביל לחשיפת מידע רגיש שנמצא באחד מבדיקות החדירות שלנו.

כאשר משתמש מבצע בקשה ל- endpoint (מכשיר)  של יוזר הוא יקבל חזרה את רשימת המשתמשים.

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

אם נסתכל בקוד המקור של האפליקציה ניתן לראות כי פונקציית הDebug- נשארה בקוד ולא הוסרה כנדרש לפני חשיפה של הAPI חיצונית.

API SQL injection

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

בדוגמא הבאה ניתן לראות קוד המקור שאינו מאובטח וכיצד הוא חשוף ל SQL injection

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

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

---

כותב המאמר עידן חמו, אנליסט סייבר