IDOR — כשמספר ב-URL פותח דלת לנתונים של אחרים
צוות CyberHub · לפני 22 ימים · 1 דק׳ קריאה
TL;DR · בקצרה
IDOR היא חולשה פשוטה ומסוכנת: שינוי מזהה ב-URL (כמו id=123) חושף נתונים של משתמש אחר, כי השרת לא בודק הרשאות.
דמיינו שאתם צופים בחשבונית שלכם בכתובת:example.com/invoice?id=1043
מה יקרה אם תשנו ל-id=1044? אם פתאום אתם רואים את החשבונית של מישהו אחר — זו IDOR (Insecure Direct Object Reference).
למה זה קורה?
האפליקציה משתמשת בקלט (המזהה) כדי להביא נתון — אבל לא בודקת אם המשתמש מורשה לראות אותו. היא סומכת על כך שלא תשנו את המספר.
למה זה מסוכן?
- חשיפת נתונים אישיים של משתמשים אחרים.
- לפעמים גם שינוי/מחיקה של נתוני אחרים.
- קל לניצול — לא צריך כלים מתוחכמים, רק לשנות מספר.
איך מתגוננים?
- בדיקת הרשאות בצד השרת בכל גישה למשאב: "האם המשתמש המחובר באמת הבעלים של פריט 1044?"
- שימוש במזהים לא-צפויים (UUID במקום 1,2,3) — מקשה, אבל לא מחליף בדיקת הרשאה.
הלקח: לעולם אל תסמכו שהמשתמש "לא ישנה את המספר". בדקו הרשאה תמיד, בכל בקשה.
📚 מקורות והפניות
💬 תגובות (0)
התחברו כדי להגיב.
אין עדיין תגובות. היו הראשונים! 🙂
🔴 עוד התקפה
SQL Injection מוסבר בפשטות
SQL Injection היא אחת החולשות הוותיקות והמסוכנות ב-web: התוקף 'מזריק' פקודות לבסיס הנתונים דרך שדה תמים. נסביר איך זה עובד ואיך מתגוננים.
XSS מוסבר — כשאתר מריץ קוד של תוקף בדפדפן שלכם
XSS (Cross-Site Scripting) היא חולשה שבה תוקף מזריק קוד JavaScript לאתר, והקוד רץ אצל משתמשים אחרים. נסביר את הסוגים ואיך מתגוננים.
Brute Force ו-Credential Stuffing — ניחוש סיסמאות בקנה מידה
תוקפים מנסים אינסוף סיסמאות (brute force) או משתמשים בסיסמאות שדלפו מאתרים אחרים (credential stuffing). נסביר ואיך עוצרים.