תת־דומיינים משותפים, שני שערים: מי רואה אילו רשומות?

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

ראשית: שם המארח רק נותן שם לדייר

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

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

שנית: החברות מגיעה מהסשן

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

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

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

שלישית: הרשת לא מוכיחה דבר על האדם

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

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

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

רביעית: הריצו את המטריצה בשני השערים

השתמשו בחשבונות מבוקרים כדי לבחון A ב־A, B ב־B, A ב־B, שם מארח לא מוכר וחשבון מאומת בלי חברויות. הרביעי והחמישי אמורים להיכשל סגור, ואסור להם ליפול לדייר ברירת מחדל. הריצו את אותה מטריצה גם דרך שער ה־VPN, עם צנצנת סשן אחת לכל חשבון:

curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-b.example.com/records/42
curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-a.example.com/records/42

אחר כך שנו רשומה ברשימת ההרשאות והריצו שוב. תוצאה שזזה פירושה שבקרת רשת מקבלת החלטת הרשאה.

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