Insecure Direct Object Reference (IDOR)¶

מבוא¶

חולשת IDOR (Insecure Direct Object Reference) הוא פגיעות אבטחה המאפשרת לתוקף לגשת למידע או משאבים שאינם מיועדים לו, על ידי שינוי מזהים ישירים (Identifiers) בבקשות לשרת. פגיעות זו היא תוצאה של הרשאות לא תקינות ובקרת גישה לא מספקת.

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

כיצד פועלת הפגיעות?¶

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

דוגמאות לפגיעות IDOR¶

דוגמה 1: שינוי מזהה בפרמטר URL¶

משתמש נכנס למערכת וצופה במסמך שלו דרך הקישור:

https://example.com/documents/12345

אם השרת לא בודק את ההרשאות כראוי, תוקף יכול לשנות את המספר ל- 12346 ולצפות במסמך של משתמש אחר:

https://example.com/documents/12346

דוגמה 2: שינוי מזהה בבקשת API¶

בקשה רגילה לשרת נראית כך:

GET /api/user/123/profile

אם השרת אינו מוודא שהמשתמש מחזיק בהרשאות המתאימות, שינוי ה-ID למזהה של משתמש אחר (/api/user/456/profile) יאפשר לתוקף לגשת לפרטי חשבון שאינם שלו.

השלכות של IDOR¶

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

כיצד ניתן להגן על המערכת?¶

בקרת גישה חזקה – וידוא שהמשתמש מורשה לגשת לכל אובייקט שהוא מבקש.
אימות מזהים בצד השרת – המערכת צריכה לבדוק האם למשתמש יש הרשאות למידע שהוא מבקש.
שימוש במזהים אקראיים (UUID) – שימוש במזהים שלא ניתן לנחש (כגון UUID במקום מספרים סדרתיים). מי שלא מכיר הUUID הוא ערך רנדומלי שלא ניתן לנחש- 2^122 קומבינציות אפשריות. https://fusionauth.io/dev-tools/uuid-generator

סיכום¶

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