בואו נתכנן את הצעד הבא באבטחת הארגון
השאירו פרטים לשיחה
בדיקות חדירות: המדריך והשירות המרכזי / מבדקי חדירות ל-API
מבדקי חדירות ל-API בוחנים את שכבת הממשקים שמחברת משתמשים, אפליקציות ושירותים. ממשק יכול להחזיר מידע תקין מבחינה טכנית ובכל זאת לחשוף משאב למי שאינו מורשה לראות אותו. לכן הבדיקה מתייחסת לזהות, לבעלות על המידע, לפעולות העסקיות ולגבולות האמון בין רכיבים. המטרה היא להבין את החשיפה בפועל ולתת לצוות הפיתוח דרך ברורה לטפל בשורש הבעיה.
מיפוי הממשקים: מה באמת כלול בבדיקה?
מסמך תיעוד הוא נקודת התחלה, אך הוא לא תמיד מייצג את כל הממשקים הפעילים. כדאי לכלול גרסאות, ממשקים פנימיים, נקודות קצה של ניהול וקריאות שמשמשות אפליקציות ישנות. רשימת הכתובות לבדה אינה מתארת את ההיקף: לכל פעולה צריך להבין את סוג המשתמש, הנתונים שהיא מקבלת, התוצאה והמערכת שמושפעת ממנה. גם webhook או חיבור של שותף הם חלק ממפת האמון כאשר הם נכללים בהיקף. לפני המבדק מבררים מה פעיל בסביבה, מי הבעלים של כל רכיב ומה ניתן לבדוק במסגרת ההרשאה שסוכמה.
הרשאה ברמת אובייקט, פעולה ושדה
גישה לממשק אינה בהכרח הרשאה לכל המידע שהוא מטפל בו. הבדיקה מבחינה בין הרשאה למשאב, הרשאה לפעולה והרשאה לשדות מסוימים. למשל, משתמש עשוי להיות מורשה לראות רשומה אבל לא לשנות את הבעלות עליה. בתרחיש אחר, משתמש של ארגון אחד יכול לקבל תוצאה של ארגון אחר אם הבדיקה מסתמכת רק על מזהה שנשלח בבקשה. הדוגמאות האלה ממחישות למה צריך חשבונות ונתוני בדיקה שמייצגים כמה תפקידים וכמה לקוחות. האכיפה צריכה להתבצע בצד השירות ולא להתבסס על ההנחה שכל הקריאות יגיעו ממסך מוכר.
אימות, אסימונים והפרדת סוגי לקוחות
ממשקי API עשויים לשרת דפדפן, אפליקציה לנייד ושירות אוטומטי. לכל סוג לקוח יכול להיות מנגנון זהות אחר, ואין להניח שכולם מקבלים אותן הרשאות. במבדק נבחנים הקשר בין הזהות לבין הפעולות, טיפול באסימונים, תוקף גישה והתנהגות לאחר שינוי הרשאות. חשוב להבין מה קורה כאשר משתמש מתנתק, כשהחשבון מושבת או כשהמפתח מתחלף. אם התהליך משתמש בספק זהות חיצוני, ההרשאה לבדיקה מתייחסת למערכת שלכם ואינה מתירה לבדוק את הספק עצמו. זהות תקפה היא רק חלק מהתמונה; נדרש גם קשר נכון למשאב ולארגון.
לוגיקה עסקית, שימוש חוזר ומגבלות צריכה
ממשק שמבצע פעולה עסקית צריך לאכוף את כללי הפעולה גם כאשר היא נקראת ישירות. בוחנים כיצד המערכת מטפלת בקריאות חוזרות, בשינוי סדר הפעולות ובמצבי ביניים. נושאים כמו מגבלות קצב וצריכת משאבים נבדקים בזהירות ובהתאם לספי הפעילות שסוכמו. אין לבצע בדיקת עומס או מניעת שירות כחלק אוטומטי ממבדק API. אפשר לעיתים לבדוק את מנגנוני ההגבלה באמצעות פעילות מצומצמת וראיות מהתצורה. אם נדרש מבחן ביצועים או עומס, צריך להגדיר לו מטרות, תשתית ותנאי עצירה נפרדים.
מידע עודף ואינטגרציות בין שירותים
תשובת API עשויה לכלול שדות שהמסך אינו מציג, ולכן יש לבחון גם את המידע שחוזר מהשרת. ייצוא, חיפוש ותוצאות שגיאה צריכים להתאים להרשאות המשתמש. בחיבורים בין שירותים חשוב להבין איזה רכיב מאמת את הקריאה, מי בודק הרשאות וכיצד מוגבלת הגישה למערכות המשך. שירות פנימי אינו בטוח מעצם היותו פנימי. ממצא בחיבור אחד יכול להשפיע על כמה אפליקציות, ולכן הדוח צריך להצביע על הרכיב האחראי ועל המקומות שבהם יש לבדוק דפוס דומה. כך נמנע תיקון שמתייחס רק ללקוח אחד שמשתמש בממשק.
כיצד הופכים את הדוח לבדיקות רגרסיה?
לצוות הפיתוח נדרשים תיאור פעולה, תפקיד משתמש, מצב הרשאות ותוצאה צפויה. לאחר התיקון אפשר לבנות בדיקות שמוודאות שמשתמש מורשה מקבל גישה ושמשתמש אחר נחסם. חשוב לכלול גם מצבים שבהם מידע שייך ללקוח אחר, ולא להסתפק בבקשה ללא התחברות. הדוח צריך לתעד גרסה וסביבה כדי שיהיה אפשר לשחזר את התוצאה. סקירת אבטחה ייעודית של API משלימה את מבדק ה-Web כאשר קיימים ממשקים שאינם נגישים דרך המסכים. אם השירות פועל בענן, יש לבחון בנפרד אם נדרשת גם בדיקה של הרשאות ותצורת התשתית.
איך מתכננים מבדק שאפשר לפעול לפי התוצאות שלו?
מבדק מועיל מתחיל בהגדרת השאלות שהארגון רוצה לקבל עליהן תשובה. האם משתמש יכול להגיע למידע של לקוח אחר? האם גישה מוגבלת מאפשרת התקדמות למערכת קריטית? האם צוות האבטחה מסוגל לזהות פעולה חשודה בזמן? את השאלות האלה מתרגמים להיקף עבודה, לתרחישים ולתוצרים. כך אפשר להבין מה נבדק בפועל, מה נשאר מחוץ לתחום ואילו מגבלות משפיעות על המסקנות. הצעת עבודה טובה מציגה את ההנחות האלה מראש, במקום להשאיר אותן לפרשנות בסיום הפרויקט.
גבולות, הרשאות ותיאום
לפני תחילת הפעילות מגדירים רשימת נכסים, בעלות על המערכות, חשבונות בדיקה, חלון פעילות ואנשי קשר. מגדירים גם פעולות אסורות, ספי עומס ותהליך עצירה במקרה של השפעה לא צפויה. שירות של צד שלישי אינו הופך לחלק מהבדיקה רק מפני שהוא מחובר למערכת שלכם. לכל רכיב נדרשת הרשאה מתאימה. בסביבה פעילה עדיף להשתמש בנתוני בדיקה ובחשבונות ייעודיים, ולתאם מראש כיצד יישמרו ראיות בלי להעתיק מידע אישי או עסקי מעבר לנדרש.
הוכחת השפעה בלי לגרום נזק
הבדיקה מתקדמת ממיפוי להבנת מנגנוני ההגנה ולבחינה מבוקרת של חולשות. כאשר נמצא נתיב אפשרי, המטרה היא לאסוף ראיות שמספיקות כדי להסביר את הסיכון ולתקן אותו. אין צורך להרחיב גישה או להוציא מאגר שלם כדי להראות שבעיית הרשאות קיימת. אפשר להגדיר מראש דוגמת מידע בטוחה ותנאי הצלחה מוסכמים. אם מתגלה ממצא חמור במהלך העבודה, דרך הדיווח וההסלמה צריכה להיות ברורה, כדי שהצוות האחראי יוכל להגיב בלי להמתין לדוח הסופי.
תיעדוף, תיקון ובדיקה חוזרת
בסיום חשוב לחבר בין חומרת הממצא לבין ההקשר של המערכת: רגישות המידע, חשיפה לאינטרנט, הרשאות נדרשות והשפעה תפעולית אפשרית. רשימת חולשות לבדה אינה מספיקה. צוותי הפיתוח והתשתיות צריכים לדעת מהו שורש הבעיה, אילו רכיבים מושפעים ואיך יוכלו לוודא שהתיקון יעיל. בדיקה חוזרת מתייחסת לגרסה ולתצורה המעודכנות, ומבדילה בין ממצא שנסגר, ממצא שנסגר חלקית וממצא שלא ניתן לאמת בגלל שינוי בהיקף או בהנגשת הסביבה.
מה להכין לקראת שיחת תיחום?
כדאי להכין תיאור קצר של המערכת, תרשים רכיבים, רשימת ממשקים ותפקידים, מידע על סביבת הבדיקה ומועד היעד העסקי. אין צורך לשלוח סיסמאות או מידע רגיש בטופס פנייה. בשיחה אפשר לברר אילו חומרים יועברו בערוץ מוסכם, מי מאשר את הפעילות ומי אחראי לתיקונים. אם קיימים ממצאים קודמים, אפשר להשתמש בהם לתכנון העבודה ולזיהוי אזורים שדורשים תשומת לב. אין להסיק מהיעדר ממצאים שהמערכת חסינה; התוצאה משקפת את ההיקף, התנאים והזמן שהוגדרו לבדיקה.
איך מודדים התקדמות לאחר המבדק?
כדאי להגדיר לכל ממצא גורם אחראי, מועד יעד והחלטה מתועדת. לפעמים אפשר לתקן מיד, ולפעמים נדרש שינוי במערכת או תיאום עם ספק. גם במקרה כזה חשוב להבחין בין טיפול בשורש הבעיה לבין אמצעי זמני שמקטין חשיפה. החלטה לדחות תיקון צריכה לכלול הסבר, מגבלה מפצה ומועד בחינה מחדש. כך נשמר הקשר בין הדוח לבין העבודה בפועל, גם כאשר כמה צוותים חולקים אחריות על אותו תהליך.
לאורך הזמן אפשר לעקוב אחר מספר הממצאים הפתוחים לפי חומרה, משך הזמן עד לתיקון וחזרת בעיות מאותו סוג. המדדים האלה מסייעים לזהות צורך בהדרכה, בבקרות פיתוח או בשינוי תצורה. הם אינם מבטיחים שלא יימצאו חולשות חדשות. כאשר מתחלפת גרסה, נוסף ממשק או משתנה מודל ההרשאות, צריך לבחון אם ההיקף הקודם עדיין מייצג את המערכת. בדיקה תקופתית מועילה יותר כאשר היא מתבססת על השינויים שהתרחשו ועל הסיכונים שהארגון רוצה להקטין.
בשיחת הסיכום רצוי להפריד בין מסר להנהלה לבין פירוט לצוותים הטכניים. ההנהלה צריכה להבין את המשמעות ואת סדר העדיפויות; אנשי המקצוע צריכים לקבל ראיות והמלצות שאפשר ליישם. לפני סגירת הפרויקט כדאי לוודא שהדוח הועבר בערוץ מוסכם ושברור מי שומר את החומרים, מי מקבל גישה אליהם ואילו ראיות יימחקו לפי ההסכם. ההנחיות האלה מגינות גם על המידע שנאסף במהלך הבדיקה.
תחומים משלימים שכדאי להכיר
לעיון במסגרת המקצועית: OWASP API Security Top 10. מסגרת מקצועית מסייעת לתכנון; הכיסוי בפועל מוגדר בהצעת העבודה.
נגדיר יחד היקף שמתאים למערכת שלכם
לתמונה הרחבה ולבחירת סוג המבדק, עברו אל שירות בדיקות החדירות של ExploiX. לתיאום שיחת תיחום אפשר לפנות לצוות עם תיאור קצר של המערכת והצורך העסקי.
שאלות נפוצות
האם מבדק API מחייב תיעוד OpenAPI?
תיעוד מסייע לתכנון, אך אינו תנאי יחיד. אפשר לעבוד גם עם דוגמאות קריאה ותיאור פונקציות. יש להגדיר את כל הממשקים והגרסאות שבהיקף כדי שלא להסתמך רק על מסמך שאינו מעודכן.
מה ההבדל בין API לבין בדיקת Web?
בדיקת Web מתמקדת באפליקציה ובזרימות המשתמש. מבדק API מתייחס לממשקים, גם כשהם משמשים לקוחות אחרים או אינם מופיעים במסך. ההיקפים יכולים לחפוף ויש לתאם אותם מראש.
איך בודקים הפרדה בין לקוחות?
מכינים חשבונות ונתונים השייכים ללקוחות נפרדים ובוחנים את הגבולות המוסכמים. הפעילות מתבצעת עם מידע ייעודי לבדיקה, כך שאפשר לאמת הרשאות בלי להסתמך על נתוני לקוחות אמיתיים.
האם בדיקת API כוללת בדיקת עומס?
לא באופן אוטומטי. מגבלות קצב וצריכת משאבים הן נושאי אבטחה, אך הפעלת עומס מחייבת תיאום נפרד. ספי פעילות ותנאי עצירה צריכים להופיע בכללי הבדיקה.
אפשר לבדוק גם REST וגם GraphQL?
ההיקף יכול לכלול טכנולוגיות שונות, בכפוף לתיחום ולהנגשת הסביבה. חשוב להבין את מודל הנתונים, ההרשאות והפעולות המותרות בכל ממשק במקום להסתפק בשם הטכנולוגיה.
מה להכין לפני תחילת העבודה?
רשימת גרסאות וממשקים, תפקידים, דוגמאות קריאה, נתוני בדיקה ותיאור חיבורים לשירותים אחרים. פרטי גישה מועברים בערוץ מוסכם לאחר תיאום ההרשאה, ולא בטופס ציבורי.