טוקן תקף הוא לא הרשאה: ה-scope שאף אחד לא בדק

Read this article in English

נתקלתי לאחרונה באפליקציה שבה נעשה שימוש ב-OAuth בצורה מאוד רשלנית. הלקוח הטמיע זרימת Authorization Code מלאה, והכל נראה בסדר גמור על פני השטח. אבל מה שהוא פספס הוא את ניהול ה-scope. השרת קיבל access token משרת ה-Identity Provider והסתמך עליו באופן עיוור, בלי לוודא אילו scopes הונפקו בפועל למשתמש.

התוצאה הייתה פשוטה: ברגע שקיבלתי טוקן עם scope בסיסי כמו read_profile, הצלחתי להשתמש בו מול endpoint פנימי שהיה אמור לקבל רק טוקנים עם scope של admin_write. בפועל שום בדיקה לא נעשתה בצד השרת – כל מי שיש לו טוקן חוקי, לא משנה באיזה scope, קיבל גישה ל-API רגיש.

הבקשה נראתה ככה:

GET /api/admin/createUser HTTP/1.1
Host: VICTIM_WEB_SITE
Authorization: Bearer eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...

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

מבחינת תוקף זה תרחיש קלאסי של privilege escalation. מספיק לגנוב או להוציא access token כלשהו דרך פישינג או שגיאה בלקוח, ואז להשתמש בו כדי לבצע פעולות ניהוליות שהיו אמורות להיות מחוץ לתחום.

מה הפתרון הנכון

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

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

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