קישורים זמניים של רשימת כתובות IP מותרות: מה ההיתר באמת מתיר

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

החליטו על איזו שאלה ההיתר עונה

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

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

תחמו את הבקשה בשרת

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

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

הצגו את ההיתר לפני התקנתו

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

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

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

הכתובת משותפת גם כשההיתר חי

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

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

בדקו ארבעה מקרים ושתי משפחות הכתובות

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

לאחר מכן בדקו כל משפחה בנפרד, כי כתובת המקור שהשירות רואה עשויה להיות שונה ביניהן.

dig +short A service.example.com
dig +short AAAA service.example.com
curl -4 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com
curl -6 -sS -o /dev/null -w "%{http_code}\n" https://service.example.com

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