אחד היתרונות בלהיות מומחה אבטחה הוא עבודה עם צוותים רבים. לאחר ביקורת, למומחי אבטחה תהיה הזדמנות לעבוד עם מנהלי מסדי נתונים ואנליסטים. כדי שאפליקציה תעבוד בצורה תקינה ומאובטחת, הצוותים הללו מנסים להתמודד עם פרצות אבטחה שיש להן בסיס משותף. דיאלוגים בין הצוותים הללו מעלים כמה בעיות עם IP אמיתי.
פרוקסי ומושגי IP אמיתיים
יישומי האינטרנט של היום פועלים על מספר שרתי אפליקציות ומערכות מסד נתונים. תארו לעצמכם שני שרתי יישומים חולקים את אותו קוד מקור. בקשות מהמשתמש מוכנות להיענות על ידי אחד מהשרתים הללו בהתאם למצב העומס. מנגנון איזון העומס, המטפל בבקשות HTTP מול שרתי היישומים, מחליט איזו בקשה להעביר לאיזה שרת יישומים. זה מציב שאלה גדולה למנהלי מערכות מתווך ולמפתחי תוכנה: מהי כתובת ה-IP האמיתית של המשתמש?
פרוקסי אחראים על העברת נתונים בין שתי מערכות. מאזן העומס הוא המנגנון האחראי על ה-proxy. במילים אחרות, מערכת אחת בלבד מתקשרת הן עם המשתמש והן עם שרת היישומים. מבחינת תעבורת רשת, שרתי web A או web B תמיד מתקשרים עם כתובת ה-IP של מאזן העומס. ניתן לומר אותו דבר לגבי משתמשים. עבור אנשי אבטחה, מאזני עומסים גורמים לבעיות חמורות בהתקפות הזרקת SQL מבוססות זמן. אבל ה
הפוקוס העיקרי כאן הוא זיוף IP.X-Forwarded-For ויחסי IP
שקול את הקשר בין X-Forwarded-For, מפתח ותוכנה. לדוגמה, נניח שהמשימה של מפתח אפליקציה היא לתעד את כל הפעילויות, כמו ניסיונות סיסמא שגויים של משתמשים, עם כתובות ה-IP שלהם. בתחילה, המפתח יקבע את כתובת ה-IP של המשתמש כאשר בקשת ה-HTTP נענתה ב- הזדמנות שמספקת שפת התכנות שבה הוא משתמש וינסה להמשיך להשתמש בנתונים אלה ב- יישום.
מכיוון שכתובת ה-IP שלו תתוקן לאורך כל תהליך הפיתוח, היא תמיד תראה את אותה כתובת במהלך הבדיקות מכיוון שבדרך כלל, מחשבי משתמש ב רשתות ארגוניות עובדות עם IP סטטי מעל כתובת MAC. היחידה תבצע כמה מבחני קבלה; עם זאת, יהיו בעיות עם אלה. יחידת הבדיקה תעביר בעיה זו למפתח התוכנה.
בשלב זה, המפתח עשוי לכתוב בקר בסביבת הפיתוח ולראות את בקשת ה-HTTP המועברת לאפליקציה בצורה גולמית, שכן לכולם יש אותה כתובת IP. זה יביא לעבודה עם X-Forwarded-For.
מידע על כותרת שנקרא X-Forwarded-For יישלח לשרת היישומים. בשלב זה, מפתח התוכנה יראה את כתובת ה-IP שלו, בה הם שולטים באמצעות ipconfig, ולא את מאזן העומס שהם רואים ביומנים. מתכנתים רבים חושבים שהם יכולים לפתור בעיה זו עם בלוק קוד כמו זה:
פוּנקצִיָהgetIPaddress() {
$ipKeys = מַעֲרָך(
'HTTP_CLIENT_IP',
'HTTP_X_FORWARDED_FOR',
'HTTP_X_FORWARDED',
'HTTP_X_CLUSTER_CLIENT_IP',
'HTTP_FORWARDED_FOR', 'HTTP_FORWARDED',
'REMOTE_ADDR'
);
לכל אחד ($ipKeys כפי ש $key) {
אם (array_key_exists($key, $_SERVER) נָכוֹן) {
לכל אחד (לְהִתְפּוֹצֵץ(',', $_SERVER[$key]) כפי ש $ip) {
$ip = trim($ip);
אם (validate_ip($ip)) {
לַחֲזוֹר $ip;
}
}
}
}
לַחֲזוֹרisset($_SERVER['REMOTE_ADDR'])? $_SERVER['REMOTE_ADDR']: שֶׁקֶר;
}
זה לא יספיק - המפתח צריך לבדוק אם הערך הנכנס הוא כתובת IP חוקית.
כל מה שלמעלה היה שייך לחלק שטופל על ידי היזם. אבל כדי שאפליקציה תעבוד בצורה נכונה ובטוחה, צוותים - עובדים יחד בתיאוריה, אבל בתוך המציאות, בנקודות קיצון אחת מהשנייה - נסו להתמודד עם פרצות אבטחה שיש להן א בסיס משותף. כעת נסו להסתכל על הנושא מנקודת מבטו של האחראי על תצורת מאזן העומס.
מנהלי מערכת עשויים לחשוב שמפתחים מתעדים מידע כגון X-Forwarded-For מכיוון שלא ניתן לסמוך על הנתונים בבקשת ה-HTTP. מנהלי מערכת אלה משדרים לעתים קרובות X-Forwarded-For; עם זאת, הם גם משדרים את כתובת מקור ה-TCP של המערכת ששלחה את הבקשה כערך כותרת שני. מבנה True-Client-IP הוא דוגמה טובה לכך.
כאשר אתה מחבר את כל הדברים האלה יחד, שתי יחידות שונות עוקבות אחר נתיבים שונים לאותה בעיה, המכונה זיוף IP של הלקוח. התוצאה היא בעיה קריטית שבה שום רישום IP והרשאה מבוססת IP לא יפעלו.
כיצד מזוהה זיוף IP של הלקוח בבדיקות חדירה?
רוב בודקי החדירה משתמשים בפיירפוקס לבדיקות האבטחה שלהם. הם מגדירים את Firefox עם תוסף פשוט, X-Forwarded-For: 127.0.0.1 עבור כל בקשות ה-HTTP. וכך, עולה האפשרות לזהות פגיעויות כאלה בכל בדיקות החדירה. ביצוע ביקורת לפי רשימת OWASP מבטיח שתבדוק פגיעויות כאלה. עם זאת, כדי לזהות את הפגיעות של X-Forwarded-For, אתה צריך מודול באפליקציה שמציג את כתובת ה-IP שלך או את הפעולות שננקטו.
כיצד לפתור את הפגיעות של X-Forwarded-For
ארגונים זקוקים למסמך פיתוח יישומים מאובטח חובה עבור כל צוותי התוכנה וחברות מיקור חוץ. לדוגמה, אם אתה צריך כתובת IP של משתמש, החברה צריכה לתכנן מראש ולהפוך אותה לכלל לגבי מידע הכותרת שבו היא תשתמש כאן. אחרת, צוותים שונים יפיקו פתרונות שונים. אם לא ניתן להתמודד עם מצב כזה, יישומי מיקור חוץ יכנסו לפעולה, מה שיקשה על מדידת קודי מקור. באופן כללי, חברות לא רוצות ללכת בדרך כזו.
אבל כדי לפתור בעיה זו, אתה יכול להשתמש בכלל F5 הבא:
כאשר HTTP_REQUEST {
HTTP:: כותרת הסר X-Forwarded-ל
HTTP:: header insert X-Forwarded-ל [IP:: remote_addr]
}
זה מסיר את השדה X-Forwarded-For בבקשת HTTP מהעולם החיצון. לאחר מכן הוא משדר את הבקשה על ידי הוספת כתובת ה-IP של המערכת ששלחה אליה את הבקשה. כך נוצרת רשימה אמינה לתוכנות הפועלות לפי X-Forwarded-For.
לסיכום, המטרה הגדולה ביותר כאן היא לבצע כמה בדיקות על בקשות HTTP וליצור סביבה אמינה. בלוק הקוד שלמעלה הוא דוגמה טובה שתוכל להשתמש בה.
מסגרות אבטחת סייבר ותיעוד לארגונים
היחידות שנראות בלתי תלויות זו בזו הן למעשה חלקים ממכלול. לכן הכל צריך לעבוד בצורה שיטתית. יש ליישם את הכללים שנקבעו מראש בין כל יחידה. אם מערכת עבודה כזו לא מאומצת, עלולות להתרחש בעיות רבות כגון פגיעות X-Forwarded-For. לשם כך יש לשקול הכל מראש ולהשתמש בתיעוד מקיף ככל האפשר.
וכל יחידה במערכת הגדולה הזו צריכה לאמץ וליישם מסגרות אבטחת סייבר. נקודת המוצא שלך צריכה להיות לחקור וללמוד את ההיגיון הפועל של מסגרות אלו.
