ממפים את כיוון החיבור לפני בחירת ההגנה
Webhook הוא הודעת אירוע שנשלחת לכתובת שהוגדרה מראש. בחנות, לדוגמה, מערכת חיצונית יכולה להודיע שהשתנה מצב הזמנה; בחיבור אחר האתר הוא השולח אל CRM. קבלת הודעה ושליחה לכתובת שהלקוח מזין הן שתי נקודות בדיקה שונות, ולכן לא מסיקים שאישור החיבור בכיוון אחד מכסה את שניהם.
רשמו מי השולח, מי המקבל, אילו אירועים נחוצים ואיזו פעולה עסקית כל אחד מפעיל. הפרידו סביבת ניסיון וחשבונות אמת. הודעה שהתקבלה אינה אישור גורף לבצע פעולה על כל לקוח או הזמנה. כשמקור הנתונים או מזהה החשבון אינם ברורים, עוצרים לפני שינוי מצב במערכת עסקית.
אימות מסירה צריך להתאים לתיעוד הספק
ב-GitHub, לדוגמה, אימות המסירה משתמש בסוד משותף ובחתימת HMAC על תוכן ההודעה. המקבל מחשב ומשווה את החתימה בדרך שהספק מגדיר לפני עיבוד. אין להעתיק שם כותרת או אלגוריתם מספק אחד לאחר. יש לשמור על תוכן הבקשה הנדרש לאימות ולהשתמש בספרייה או במימוש נתמך ובהשוואה המתאימה.
בפועל חשוב לזהות אם המנגנון חותם על גוף הבקשה הגולמי או על מבנה אחר. שינוי סדר שדות או עיבוד JSON לפני האימות עלולים לשנות את החומר שנבדק. אחרי אימות בוחנים גם מבנה ושדות צפויים, גודל בקשה והגבלת עומס, בהתאם למוצר. אלו בדיקות נפרדות מתעודת TLS תקינה.
בדקו חוזה, הרשאות וכפילויות בנפרד מהחתימה
גם אחרי אימות מקור צריך לוודא שסוג האירוע, החשבון והמזהה מתאימים לתהליך המורשה. חתימה תקינה אינה מבטיחה שהפעולה העסקית עדיין נחוצה. מסירה חוזרת יכולה להיות לגיטימית אחרי כשל, ולכן המערכת צריכה להבחין בין קבלת ההודעה לבין ביצוע הפעולה בפועל.
הטבלה היא רשימת קבלה מקורית לחיבור עסקי. משלימים אותה לפי חוזה המסירה של הספק, לרבות סדר אירועים וזמן תגובה. אישור קבלה לפני שהמידע נשמר באופן אמין עלול לאבד עבודה, ואישור רק אחרי עיבוד ארוך עלול לגרור ניסיונות חוזרים.
| שכבה | מה מאמתים | תוצאה צפויה בניסוי מורשה |
|---|---|---|
| זהות ושלמות | מנגנון האימות של הספק | מסירה שאינה מאומתת אינה מפעילה פעולה |
| תחום עסקי | חשבון, סוג אירוע ומזהה משאב | אירוע מחוץ להיקף אינו משנה נתונים |
| כפילויות | מזהה אירוע וכלל עיבוד עקבי | מסירה חוזרת אינה יוצרת רשומה נוספת |
| כשל זמני | שמירה, ניסיון חוזר ומעקב | הפעולה ניתנת לבירור בלי לנחש |
| מידע אישי | שדות ולוגים הנחוצים לתפעול | אין תיעוד מלא של סודות ותוכן לקוחות |
מסירה חוזרת, replay וסדר אירועים
מזהה אירוע או מסירה יכול לסייע בזיהוי חזרה, אך אופן השימוש תלוי בספק. ב-GitHub מתועד מזהה מסירה שנשאר זהה בשליחה חוזרת של אותה מסירה. אצל ספק אחר ייתכן מודל אחר. אם יש חותמת זמן חתומה וכלל תוקף נתמך, בודקים אותם לפי התיעוד; אין להמציא חלון שרירותי שעלול לפסול הודעות תקינות.
מניעת כפילות צריכה להיות עקבית גם כששני עיבודים מתחילים כמעט יחד. בתכנון בוחנים תיעוד מצב, תור או מנגנון שמונע ביצוע חוזר של אותה פעולה. אם הודעות יכולות להגיע בסדר שונה, קובעים איך מבררים את המצב העדכני. חתימה לבדה אינה פותרת replay, סדר אירועים או התאוששות מכשל.
מזהה שמגיע בכותרת שאינה מכוסה בחתימה אינו הוכחה קריפטוגרפית לייחוד האירוע. אין להציג שמירת מזהים בלבד כהגנת replay מלאה. משלבים מידע מאומת וכללי מצב של הפעולה, ובודקים את המגבלות של פרוטוקול הספק לפני שמבטיחים מה החיבור מונע.
דוגמה: אותה פנייה מגיעה ל-CRM פעמיים
בתרחיש להמחשה בלבד, טופס יוצר אירוע, המקבל שומר את הפנייה אך התשובה לשולח מתעכבת. הספק מנסה למסור שוב. בלי זיהוי עקבי נוצרים שני כרטיסים, ושני אנשי מכירות יכולים לפנות לאותו אדם. הבעיה אינה בהכרח תקיפה; היא יכולה לנבוע מתכנון חלקי של הטיפול החוזר.
בדיקת הקבלה משתמשת בנתוני ניסיון ובמנגנון בדיקה או מסירה חוזרת שהספק מאפשר. מצפים לפנייה עסקית אחת ולתיעוד מסירות שניתן לקשר אליה. לא משחזרים הודעת סליקה אמיתית ולא מפעילים חיוב כדי לבדוק כפילות. במקרה של אי התאמה משווים מזהים ופעולות לפני שמוחקים רשומות.
כתובות יעד, לוגים ותנאי סיום
אם המערכת שולחת הודעות לכתובות שמשתמשים מגדירים, יש לבחון גם SSRF, הגבלת יעדים, הפניות ורשתות פנימיות. אישור HTTPS של יעד אינו מוכיח שמותר לשרת לפנות אליו. זו בדיקה נפרדת מהחתימה על ההודעה שמתקבלת אצלכם.
לצורכי תפעול שמרו מזהה מעקב, זמן, מצב ותיאור שגיאה מצומצם, בלי סוד חתימה ובלי גוף הודעה מלא כברירת מחדל. הגדירו מי בוחן מסירות שלא הושלמו ואיך מתאמים ניסיון חוזר. טיפול אינו סגור עד שיש ראיה למסירה תקינה, למצב כפול ולכשל שניתן לברר, בהיקף הבדיקה המוסכם.
