למה בכל מערכת עם תורי הודעות יש חורי אבטחה

Read this article in English

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

במערכת שראיתי, כל microservice קיבל credentials של publish ו-subscribe לאותו ערוץ – בלי הגבלת ACL, בלי סינון נושאים. תוקף שהצליח לחדור ל-VM אחת, אפילו עם הרשאות מאוד בסיסיות, הצליח לשלוח הודעות מזויפות ולעקוף את כל ה-business logic שבנו בחזית.

ולפעמים זה אפילו מתקבל מצד הלקוח. רואים את זה לרוב במערכות IoT, שבהן device מתחבר לערוץ מסוים ושולח את ההודעות.

דוגמה: שירות של Billing הקשיב ל-queue בשם billing_events. המתקפה:

{
 "event": "issue_refund",
 "userId": "12345",
 "amount": 100000
}

ה-Billing microservice לא בדק את מקור ההודעה, רק את המבנה שלה. ברגע ששיגרתי הודעה, התבצע refund – גם בלי authorization.

איך פותרים?

• לכל service, credentials נפרדים ו-ACL ספציפי – publish/subscribe על ערוצים מסוימים בלבד.
• אימות מבנה ומקור של כל הודעה, לא לסמוך על תוכן בלבד.
• audit log לכל הודעה משמעותית.
• שימוש ב-message signing וב-nonce – הגנה כפולה.
• הקפדה על hardening – גם ברמת firewall וגם IAM, ולא רק ב-queue עצמו.

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

פוסט זה פורסם לראשונה בלינקדאין בתאריך 2025-09-01. — ארז מטולה