IDOR בפועל: מה CVE-2025-13526 באמת מלמד מהנדסי אבטחה

אם אתם עובדים בתחום האבטחה מבוססת יישומים או בינה מלאכותית מספיק זמן, "IDOR" מפסיק להיות סתם מילת באזז והופך לדפוס חוזר שאתם רואים בכל מקום: ממשקי API, מערכות אחוריות לניידים, לוחות מחוונים SaaS, לוחות בקרה, ואפילו כלים פנימיים.

CVE-2025-13526 הוא אחד מאותם מקרים שבהם הפניה לא בטוחה לאובייקט ישיר (IDOR) אינו מסתתר עמוק בתוך פרוטוקול אקזוטי, אלא יושב בפרוטוקול נפוץ תוסף וורדפרס, וחושף בשקט את נתוני הלקוחות לכל מי שמוכן לשנות פרמטר בכתובת האתר.wiz.io)

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

IDOR ואישור ברמת האובייקט השבור, ללא ערפל מילות הבאזז

ב-OWASP API Security 2023, הפריט הראשון —API1: אישור ברמת אובייקט שבור—זהו למעשה השם בעידן ה-API למה שרובנו עדיין מכנים IDOR.(OWASP)

המכניקה פשוטה עד כאב:

• היישום חושף סוג כלשהו של מזהה אובייקט בבקשה: מספר הזמנה, user_id, מספר כרטיס, message_id, וכן הלאה.
• ה-backend משתמש במזהה זה כדי לחפש רשומה.
• בין פענוח המזהה והחזרת הנתונים, אף אחד לא שואל "האם למתקשר זה מותר לגשת לאובייקט זה?"

API1 של OWASP ופרסומים של צוותי אבטחת API כגון apisecurity.io ו-Traceable מתארים את אותה הרעיון המרכזי: תוקף מחליף את המזהה של האובייקט שלו במזהה אחר — מספר שלם רציף, UUID, או כל דבר אחר — והיישום מחזיר בשמחה את הנתונים של מישהו אחר.חדשות אבטחת API)

MITRE CWE-639 (עקיפת אישור באמצעות מפתח הנשלט על ידי המשתמש) מתאר דפוס זה באופן פורמלי, ואף מציין כי המונח "IDOR" חופף במידה רבה ל אישור ברמת אובייקט שבור (BOLA).(CWE)

IDOR אינו מתוחכם. הוא אינו דורש תואר דוקטור או שרשרת של גאדג'טים לביטול סדרות. הוא מסוכן מכיוון:

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

CVE-2025-13526 הוא, למרבה הצער, דוגמה קלאסית לכך.

CVE-2025-13526 במבט חטוף: IDOR בתוסף "Chat to Order" של WordPress

על פי Wiz, Wordfence, OpenCVE ומעקבים אחרים, CVE-2025-13526 הוא IDOR ב- צ'אט OneClick להזמנה תוסף עבור WordPress. כל הגרסאות עד וכולל 1.0.8 מושפעים; הבעיה תוקנה ב 1.0.9.(wiz.io)

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

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

CVE-2025-13526: מאפייני מפתח

NVD ו- CVE.org לרשום את הפגיעות כ "חשיפת מידע רגיש לגורם בלתי מורשה" (CWE-200), עם ציון CVSS גבוה של 7.5.NVD) ההמלצה של Wordfence היא אפילו יותר בוטה:

"OneClick Chat to Order <= 1.0.8 – הפניה ישירה לא מאובטחת לאובייקט לחשיפת מידע רגיש ללא אימות." (Wordfence)

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

מאחורי הקלעים: איך IDOR באמת עובד

בואו נניח בצד את המיתוג ונבחן את הדפוס הבסיסי.

דמיינו כתובת URL טיפוסית בסגנון WooCommerce:

<https://shop.example.com/checkout/thank-you/?order_id=12345>

בגרסאות פגיעות של OneClick Chat to Order, כאשר משתמש נכנס לכתובת URL זו:

1. התוסף קורא $_GET['order_id'].
2. הוא מבקש מה-backend של המסחר האלקטרוני (למשל, WooCommerce) את ההזמנה. 12345.
3. הוא מציג דף "תודה / סיכום הזמנה" המבוסס כולו על אובייקט ההזמנה.
4. הוא לעולם לא בודק אם המבקר הנוכחי מאומת, או אם הוא בעל ההזמנה. 12345.

גרסה פשוטה יותר של ההיגיון הזה עשויה להיראות כך:

// קוד מדומה פגיע לצורך המחשה בלבד function wa_order_thank_you_override() { $order_id = $_GET['order_id'] ?? null; if (!$order_id) { return; // או הפנה למקום אחר }

    // אחזר את ההזמנה לפי מזהה $order = wc_get_order($order_id);
    if (!$order) { return; // ההזמנה לא נמצאה } // ❌ חסר: בדוק שהמשתמש הנוכחי רשאי לראות הזמנה זו // הצג תצוגת "תודה" עם פרטי ההזמנה render_wa_thank_you_page($order); }

מכאן, הניצול ברור:

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

מכיוון שנקודת הקצה אינה דורשת הפעלת הפעלה מאומתת, הרף נמוך עוד יותר: תוקף שאינו מאומת כלל יכול למנות הזמנות לפי מזהה.

איך נראה התיקון

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

מבחינה קונספטואלית, גרסה חזקה יותר נראית כך:

// Hardened pseudocode for illustration only
function wa_order_thank_you_override() {
    $order_id = $_GET['order_id'] ?? null;
    if (!$order_id) {
        return;
    }

    $order = wc_get_order($order_id);
    if (!$order) {
        return;
    }

    // Enforce ownership: either logged-in customer or verified guest
    if (!current_user_can_view_order($order)) {
        wp_die(__('You are not allowed to view this order.', 'oneclick-chat-to-order'), 403);
    }

    render_wa_thank_you_page($order);
}

function current_user_can_view_order($order) {
    $user_id = get_current_user_id();

    if ($user_id) {
        // Logged-in customer: only allow if this is their order
        return (int) $order->get_user_id() === (int) $user_id
            || current_user_can('manage_woocommerce'); // admin / support staff
    }

    // Guest orders should rely on WooCommerce's order key mechanism
    $key_param = $_GET['key'] ?? null;
    return $key_param && hash_equals($order->get_order_key(), $key_param);
}

בפועל, התיקון 1.0.9 של התוסף מסתמך על המנגנונים הקיימים של WooCommerce לאימות הזמנות אורחים ומוסיף בדיקות אישור נאותות סביב wa_order_thank_you_override.(wiz.io)

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

מדוע IDOR ממשיך להופיע (במיוחד בעידן ה-API וה-AI)

אם תקרא את הניתוחים המודרניים של IDOR/BOLA — בין אם מ-OWASP, apisecurity.io, escape.tech או Traceable — תראה את אותו דפוס חוזר על עצמו.OWASP)

כמה סיבות מבניות:

1. API ו-SPA חושפים מזהים על פי תכנון ממשקי משתמש, אפליקציות סלולריות ושילובים של צד שלישי זקוקים כולם למזהים יציבים. זה טבעי לראות /הזמנות/12345 או {"מספר_הזמנה":12345} בטבע.
2. ההרשאה מטופלת כ"תוספת" צוותים נוטים לחשוב במונחים של "מחובר לעומת אורח" ושוכחים ש שני משתמשים שונים שנכנסו למערכת עדיין זקוקים לגישה שונה לאותו נקודת קצה. BOLA אינו עוסק באימות; הוא עוסק בשאלה האם המתקשר יכול לגשת לאובייקט הספציפי הזה.
3. הלוגיקה מפוזרת בין בקרים ומטפלים במקום מרכזי canAccess(הזמנה, משתמש) מופעל עבור כל נתיב גישה, כל מטפל מבצע בדיקות חלקיות משלו. במוקדם או במאוחר, נתיב אחד שוכח.
4. הבדיקות מוטות לטובת "מסלולים מוצלחים" QA ואפילו חלק ממשימות בדיקת החדירות עדיין מתמקדות ב"משתמש A עושה דברים A, משתמש B עושה דברים B", ולא ב"משתמש A מנסה לגשת לאובייקטים של B על ידי ניחוש מזהים".
5. האוטומציה נוטה להתמקד בנקודות הקצה ולא באובייקטים סורקים רבים מתייחסים לכל כתובת URL כאל נכס נפרד, אך BOLA עוסק ב מערכות יחסים: אותה נקודת קצה, זהויות שונות, אובייקטים שונים.

התוצאה היא זרם קבוע של CVE — כולל CVE-2025-13526 — שבו הניצול מסתכם ב"קח את כתובת ה-URL שלך, שנה מספר, וקבל את הנתונים של מישהו אחר".

אסטרטגיות מעשיות: איתור ותיקון IDOR לפני שהוא הופך ל-CVE

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

1. תכנון לאישור ברמת האובייקט באופן מפורש

ברמת הקוד והארכיטקטורה:

• טיפול "מי יכול לגשת לאובייקט זה?" כשאלת מדרגה ראשונה במודל התחום שלך.
• ליישם פונקציות מרכזיות כמו canViewOrder(הזמנה, משתמש) או isAccountMember(חשבון, משתמש) וקרא להם בכל מקום שבו אובייקט נקרא או משתנה.
• הימנע משכפול לוגיקת האישור בין בקרים, תצוגות ועוזרי שירות.

2. הפכו את אישור ברמת האובייקט השבור לחלק ממודל האיומים שלכם

כאשר אתה מעצב או בודק תכונה:

• זהה את כל האובייקטים החשופים באמצעות מזהים (הזמנות, עגלות, צ'אטים, כרטיסים, מסמכים).
• לפרט את כל נתיבי הקוד שקוראים או כותבים את האובייקטים הללו.
• עבור כל נתיב, שאל במפורש: "אם אשנה את המזהה הזה, מה ימנע ממני לראות את הנתונים של מישהו אחר?"

ההנחיות API1:2023 של OWASP והטקסונומיה של CWE-639 מהווים עוגנים שימושיים במקרה זה.OWASP)

3. בדקו כמו תוקף: ריבוי משתמשים, ריבוי הפעלות, אותה נקודת קצה

בבדיקות ידניות:

• השתמש לפחות בשני חשבונות משתמש רגילים (A ו-B), בנוסף למפגש "ללא אימות".
• עבור כל נקודת קצה המתייחסת למזהה בנתיב, בשאילתה, בגוף או בכותרת, שלח את המזהים של A מהפעלה של B ולהפך.
• חפש הבדלים עדינים בקודי סטטוס HTTP, בגודל התגובות ובתוכן הגוף.

בבדיקות אוטומטיות, אתה רוצה כלי עבודה שיכולים:

• למד את הסכימה של המזהים שלך (לדוגמה, מספר הזמנה, messageId, UUIDs).
• הפעל מחדש תעבורה מוקלטת עם מזהים ששונו בהקשרים שונים של הפעלה.
• סמן מקרים שבהם יש דליפת נתונים בין דיירים או משתמשים.

היכן מתאימה הבינה המלאכותית: שימוש ב-Penligent להרחבת גילוי ואימות IDOR

IDOR ו-CVE-2025-13526 הם גם נקודת מבט טובה לחשיבה על בדיקות אבטחה בסיוע בינה מלאכותית.

יישומים מודרניים הם מבולגנים:

• ממשקים מרובים (אינטרנט, מובייל, כלים פנימיים).
• שילוב של REST, GraphQL, WebSocket ונקודות קצה RPC.
• מודלים מורכבים של זהויות (משתמשים, דיירים, ארגונים, "סביבות עבודה").

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

זה המקום שבו פלטפורמות כמו Penligent כנסו.

מתעבורה מוקלטת להשערת IDOR

Penligent נבנה כפלטפורמת בדיקות חדירה מבוססת בינה מלאכותית, המסוגלת:

1. קלט תיאורי API ותעבורה חיה
   • משוך מפרטי OpenAPI/Swagger, אוספי Postman או לכידות פרוקסי.
   • השתמש בניתוח מבוסס LLM כדי לזהות מזהי אובייקטים אפשריים (מספר הזמנה, user_id, chat_id, וכו') ולמפות אותם למשאבים.
2. יצירת תוכניות בדיקה IDOR באופן אוטומטי
   • עבור כל נקודת קצה מועמדת, יש לסנתז מקרי בדיקה שבהם:
     • ה-ID של משתמש A מושמע מחדש תחת ההפעלה של משתמש B.
     • הפעלות אורח משחזרות מזהי הפעלות מאומתות.
   • חפש הבדלים בתגובות המעידים על גישה בלתי מורשית לנתונים.
3. לאמת ולתעד את ההשפעה האמיתית
   • כאשר חשוד ב-IDOR מתנהג כמו CVE-2025-13526 — ומחזיר נתוני הזמנות של משתמשים אחרים — Penligent יכולה:
     • תעד את הבקשות והתגובות המדויקות כראיות.
     • חלץ את השדות הרגישים שנחשפו (שמות, כתובות דוא"ל, כתובות).
     • הפק דוח ידידותי למפתחים המקשר את ההתנהגות למטפל או לבקר הספציפי.

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

מ-CVE-2025-13526 ל-"האם זה יכול לקרות בסטאק שלנו?"

CVE-2025-13526 הוא באג בתוסף WordPress, אך הדפוס חל באותה מידה על:

• לוחות מחוונים SaaS ("/api/v1/reports/{reportId}").
• כלי ניהול פנימיים ("/tickets/{id}/details").
• ממשקי API בין מכונות במיקרו-שירותים.

זרימת עבודה בסגנון Penligent מאפשרת לך לשאול שאלה בעלת ערך גבוה יותר:

"הראה לי בכל מקום בסטאק שלנו שבו משהו מתנהג כמו CVE-2025-13526."

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

מסקנות עבור צוותי אבטחה והנדסת בינה מלאכותית

CVE-2025-13526 הוא כותרת נאה לדיווחי הפגיעות של השבוע, אך הלקחים העמוקים יותר הם בעלי השפעה ארוכת טווח:

• IDOR הוא ריח אדריכלי, לא רק חוסר אם אם לוגיקת ההרשאה מפוזרת ואופציונלית, בסופו של דבר תשלח CVE-2025-13526 משלך, בין אם ב-WordPress, Python, Go או Rust.
• יש להתייחס ל-BOLA כאל "באג עיצובי" ולא כאל מקרה קיצון. API1 של OWASP נמצא בראש הרשימה מסיבה טובה: קל לפספס אותו, והנזק שהוא גורם כאשר הוא מדליף מידע אישי בין דיירים הוא הרסני.OWASP)
• בדיקות אוטומטיות חייבות להיות מודעות לאובייקטים, ולא רק לנקודות קצה. לא מספיק להקליד כל כתובת URL פעם אחת. בדיקת IDOR אמיתית פירושה לשחזר את זהה כתובת URL תחת שונה זהויות עם שונה מזהי אובייקטים.
• בינה מלאכותית יכולה וצריכה לעזור פלטפורמות כמו Penligent יכולות לקחת על עצמן את העבודה החוזרת ונשנית של יצירת מקרי בדיקה, שינוי מזהים והשוואת תגובות, כך שהמהנדסים האנושיים יכולים להקדיש את זמנם למודלים של סיכונים ולבניית הגנות במקום לבצע התאמות ידניות. מספר הזמנה בדפדפן.

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

• wiz.io
• Wordfence
• OWASP