Skip to content
עברית

אושרה הוצאת אלגוריתמים משימוש ב־JOSE: בדקו מה שירות ה־JWT מקבל

Read in English

עדכון תקינה · המקורות נבדקו ב־7 בנובמבר 2026

ה־IESG אישר ב־6 בנובמבר את מסמך הוצאת האלגוריתמים משימוש ב־JOSE. במועד הבדיקה הוא נמצא בתור של עורך ה־RFC וממתין לתשובת המחבר. הוא עדיין לא פורסם כ־RFC. האישור הוא הזדמנות לבדוק את הקוד שמטפל באסימונים, לפני ששדרוג ספרייה ישנה את ההתנהגות בהפתעה. היסטוריית האישור והתאריכים.

אילו אלגוריתמים מושפעים?

הטיוטה שאושרה עוסקת ב־none עבור JWS וב־RSA1_5 עבור JWE. הראשון אינו מספק הגנת חתימה; השני הוא הצפנת RSA עם ריפוד PKCS#1 v1.5. חתימות RSA מסוג RS256, RS384 ו־RS512 אינן משתנות במסגרת הטיוטה הזו.

הטיוטה מסירה את החובה לממש את שני האלגוריתמים ב־JWT. יישומים אמורים להשבית אותם כברירת מחדל; צורך מסוים במערכת ותיקה יכול לקבל חריג מצומצם, ולא הפעלה כללית. הסיווג המוצע במרשם האלגוריתמים הוא Deprecated, ולא Prohibited. חריג מצומצם אינו מבטל את סיכוני האבטחה. הטיוטה והסטטוס העדכניים.

מתחילים בצד שמקבל את האסימון

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

הנחיות האבטחה הקיימות ב־RFC 8725 דורשות קבוצת אלגוריתמים שהיישום מגדיר, אימות של כל הפעולות הקריפטוגרפיות ובדיקות מתאימות של המנפיק וקהל היעד. השבתת שני אלגוריתמים אינה מחליפה את הבקרות האלה.

תוכנית קצרה לבדיקות קבלה

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

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

איך נראית בדיקה שהושלמה?

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

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

קריאה נוספת

Post a Comment

Previous Post Next Post