מה זה IDOR - החולשה שכל אחד יכול למצוא, ולכן היא כל כך מסוכנת

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

אז מה זה בעצם IDOR

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

דוגמה שכל אחד יכיר

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

https://example.com/claims?id=4521

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

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

למה זה קורה

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

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

זה לא רק מספרים בכתובת

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

למה זה נחשב לאחת החולשות המסוכנות ביותר

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

איך מגנים על אתר מפני IDOR

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

איך לומדים למצוא IDOR בעצמכם

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

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

לסיכום

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

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