פענוח חתימת json באינטרנט: מדריך למהנדס אבטחה כדי לא להיחשף

בקרת הגישה המודרנית מתבססת על אסימונים מבוססי JSON. כאשר בודקים אסימון גישה OAuth, אסימון OpenID Connect ID או הפעלת API חתומה, בדרך כלל בוחנים את חתימת JSON באינטרנט (JWS) מבנה. מנועי חיפוש יפנו אנשים רבים לכלים ל"פענוח חתימות אינטרנט json" שנראים כממירים באופן קסום מחרוזות בלתי מובנות ל-JSON קריא.

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

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

מהו באמת חתימת JSON Web Signature?

על פי מפרט JWS, חתימת JSON Web Signature מייצגת תוכן שרירותי המוגן על ידי חתימה דיגיטלית או MAC, באמצעות מבנים מבוססי JSON. היא מספקת שלמות ואותנטיות לרצף של בתים, ללא תלות במשמעותם של אותם בתים. (מעקב נתונים של IETF)

בפועל, ברוב המקרים רצף הבתים הזה הוא אובייקט JSON של תביעות — וזה מה שאנו מכנים JSON Web Token (JWT). JWS עצמו מוגדר ב-[RFC 7515], בעוד JWT מוגדר בתקן מקביל המתמקד באופן שבו תביעות אלה בנויות ומפורשות. (בינוני)

הצורה הקומפקטית המוכרת נראית כך:

eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9. eyJzdWIiOiIxMjM0Iiwic2NvcGUiOlsicmVhZCIsIndyaXRlIl0sImV4cCI6MTczNDkxMjAwMH0.
ODU5Y...חתימת-בתים-כאן...

מבחינה קונספטואלית, מדובר בשלושה חלקים המקודדים ב-Base64URL ומחוברים באמצעות נקודות:

פעולת פענוח חתימת אינטרנט json, בין אם היא מבוצעת על ידי כלי מקוון ובין אם בסקריפטים משלך, רק מבטלת את קידוד Base64URL של שני החלקים הראשונים ומדפיסה את ה-JSON בצורה מסודרת. היא עושה זאת לא להוכיח שהחתימה תקפה, אלא אם כן הכלי מבצע אימות מפורש באמצעות מפתח ידוע וקבוצת אלגוריתמים מוגבלת. (developer.pingidentity.com)

כיצד פועלים כלי פענוח חתימות אינטרנט json

רוב מפענחי JWT / JWS — כגון כלי הפיתוח הנפוצים המשמשים בדפדפנים או בסביבות פיתוח מבוססות-אינטרנט — מיישמים את אותו צינור מינימלי:

1. חלק את הנקודות לשלושה קטעים.
2. פענח את שני הקטעים הראשונים באמצעות Base64URL.
3. לנתח אותם כ-JSON עבור הכותרת והנתונים.
4. אם מסופק מפתח אימות, יש לחשב מחדש את החתימה באמצעות האלגוריתם המפורסם בכותרת ולהשוות אותה לקטע השלישי. (developer.pingidentity.com)

מנקודת מבטו של מהנדס אבטחה, שלבים 1–3 בטוחים מספיק לניתוח לא מקוון; שלב 4 הוא המקום שבו מסתתרות מרבית הפגיעויות.

קטע קוד מינימלי לפיענוח ב-Python

להלן קטע קוד פשוט בכוונה, המיועד לפיענוח בלבד ב-Python, שימושי כאשר אתם מחפשים טוקנים שנתפסו במהלך בדיקת חדירות:

import base64 import json def b64url_decode(data: str) -> bytes: # JWT padding handling padding = '=' * (-len(data) % 4) return base64.urlsafe_b64decode(data + padding) def decode_jws(token: str):
    header_b64, payload_b64, signature_b64 = token.split('.') header = json.loads(b64url_decode(header_b64)) payload = json.loads(b64url_decode(payload_b64)) return header, payload, signature_b64

jws = "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9...." h, p, sig = decode_jws(jws) print("Header:", h) print("Payload:", p)

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

קטע קוד Node.js עם אימות

ברגע שעוברים משלב הפענוח לשלב האימות, כל פרט חשוב:

import jwt מ-"jsonwebtoken"; import fs מ-"fs"; const publicKey = fs.readFileSync("public.pem", "utf-8");

function verifyJws(token) { // קריטי: נעל במפורש את האלגוריתמים הנתמכים return jwt.verify(token, publicKey, { algorithms: ["RS256"], }); }

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

פענוח הוא פעולה בלתי מזיקה, אך אין לסמוך על נתונים מפוענחים

דפוס מסוים חוזר על עצמו שוב ושוב בדוחות תאונות וב-CVE: מפתחים מתייחסים פוענח נתוני JWT / JWS כאילו כבר היו קיימים מאומת. מספר מאמרים מודרניים העוסקים בסוגיות אבטחה של JWT מדגישים כי פענוח Base64URL הוא פעולה פשוטה וכי סודיותו של אסימון אינה נובעת מכך שהוא "קשה לקריאה". (PortSwigger)

שלוש קטגוריות חוזרות של באגים בולטות במיוחד:

1. שדה "alg" מטופל כמקור אמת. אם קוד האימות שלך שולף את האלגוריתם לשימוש מהכותרת — הנשלטת על ידי המשתמש — אתה מזמין התקפות של בלבול אלגוריתמי.
2. ה אף אחד האלגוריתם מתקבל בטעות. תקן JWT דרש בעבר תמיכה ב- "אין" כאלגוריתם שמשמעותו "ללא הגנה על שלמות". הניתוח הקלאסי של Auth0 הראה כיצד מספר ספריות כיבדו בתמימות את הבחירה הזו, ואפשרו לאסימונים לא חתומים לעבור את הבדיקות. (Auth0)
3. רמזים חשובים (ילד, מוטמע jwk, x5u) אינם מאומתים. ה-JWS RFC ומדריכי הבדיקה מדגישים כי מתן אפשרות לאסימון לבחור את מפתח האימות שלו ללא רשימת אישור קפדנית מאפשר לתוקפים להבריח מפתחות ציבוריים שרירותיים או לכפות חיפושים אחר מפתחות במיקומים הנמצאים בשליטת התוקפים. (PortSwigger)

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

כאשר פענוח נתקל ב-CVE: מצבי כשל JWS קונקרטיים

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

CVE-2015-9235 – בלבול בין מפתחות HS/RS ב- jsonwebtoken

ב-Node.js jsonwebtoken בגרסאות של המודול שקדמו לגרסה 4.2.2, שגיאת תכנון אפשרה לעקוף את אימות החתימה על ידי מעבר מאלגוריתם א-סימטרי (משפחות RS256 / ES256) לאלגוריתם סימטרי (HS256). נתיב הקוד הפגיע השתמש באותו ערך — המפתח הציבורי RSA — כמו הסוד HMAC כאשר התוקף שינה את אלג כותרת ל-HS256. (nvd.nist.gov)

מנקודת המבט של התוקף, תהליך העבודה הוא פשוט:

1. פענח את האסימון המקורי ובדוק את הכותרת.
2. חלץ את המפתח הציבורי של השרת (לדוגמה, מנקודת קצה JWK או מתעודה).
3. יצירת אסימון חדש עם כותרת HS256, תוך שימוש במפתח הציבורי כסוד HMAC.
4. הצג את האסימון המזויף; השרת מתייחס אליו בטעות כאל אסימון תקף.

במקרה זה, פענוח נתן לתוקף את חומר הגלם (כותרת, אלגוריתם, מיקומי מפתחות); לוגיקת האימות עשתה את השאר.

CVE-2018-1000531 – קבלת ה- אף אחד אלגוריתם

פגיעות זו עקבה אחר מקרים שבהם ספריות קיבלו אסימונים חתומים עם אף אחד אלגוריתם, ומתייחס אליהם כאל תקפים למרות היעדר חתימה. דפוס הניצול פשוט עד כדי גיחוך: שינוי "alg": "RS256" אל "alg": "אין", הסר את חלק החתימה ובדוק אם ה-API היעד מקבל את האסימון. (0xn3va.gitbook.io)

CVE-2023-48238 – בלבול באלגוריתם ב- json-web-token

ה json-web-token ספריית JavaScript נמצאה פגיעה להתקפת בלבול אלגוריתמים נוספת. הבעיה המרכזית: האלגוריתם ששימש לאימות נלקח ישירות מכותרת האסימון, שהייתה באותו שלב לא אמינה. הדבר איפשר לתוקפים לבחור אלגוריתם נוח יותר מזה שמפעיל השרת חשב שהוא אוכף. (nvd.nist.gov)

CVE-2024-54150 – בלבול ביישום C JWT

לאחרונה, ה cjwt ספריית C סבלה מפגם קריטי של בלבול באלגוריתם, המכונה כעת CVE-2024-54150. בדיקת קוד גילתה כי היישום לא הבחין כראוי בין אלגוריתמים מבוססי HMAC לאלגוריתמים מבוססי RSA / EC בעת אימות אסימונים, מה שפתח שוב את הדלת לבלבול מפתחות. (nvd.nist.gov)

מקרים אלה אינם סקרנות היסטורית; הם מראים שגם ב-2023–2024, טעויות עדינות בנתיב האימות של JWS נותרות מקור פעיל לפגיעויות חמורות.

כדי לשמור על סדר במהלך ההערכה, צוותים רבים יוצרים דף עזר כמו זה המוצג להלן:

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

זרימת עבודה מעשית של פענוח-ראשון עבור בודקי חדירות

כאשר אתם מעריכים מערכת API או SSO המסתמכת על JWS, תהליך עבודה מסודר של פענוח תחילה ימנע נקודות עיוורות והשערות רועשות.

1. לכידת וקיטלוג אסימונים. השתמש בפרוקסי או במערך הבדיקה שלך כדי ללכוד את כל האסימונים: כותרות אישור, קובצי Cookie, פרמטרי URL. קבץ אותם לפי מנפיק וקהל יעד.
2. פענוח כותרת ותוכן במצב לא מקוון. השתמש בסקריפטים כמו קטע הקוד ב-Python שלעיל או jwt_tool לצורך פענוח בלבד; לעולם אל תסתמך על שירות מקוון עבור אסימונים רגישים במשימות אמיתיות. (GitHub)
3. בנה מטריצת כותרת. עבור כל משפחת אסימונים, רשום אלג, ילד, נוכחות של jku / jwk / x5u, וכל שדות הכותרת המותאמים אישית. זה המקום שבו ההנחיות של PortSwigger בנוגע ל-JWKs משובצים ומפתחות המסופקים על ידי התוקף הופכות לישימות באופן ישיר. (PortSwigger)
4. הסקת דפוסי ניהול מפתחות. בהתבסס על שדות כותרת ונקודות קצה ידועות (/.well-known/jwks.json), לתאר בקצרה כיצד המפתחות מחולקים ומוחלפים.
5. בדוק אם יש סוגים ידועים של באגים.
   • נסה חתימה ריקה / אף אחד גרסאות אם הספרייה או הערימה תמכו בהן בעבר.
   • בצע ניסיונות בלבול מפתחות HS/RS כאשר האלגוריתמים אינם נעולים.
   • בדיקה ילד טיפול בהתנהגות של מעבר בין ספריות או הכללת קבצים.
   • נסה להטמיע הזרקת JWK במקומות שבהם המפרט מאפשר זאת, אך היישום אינו מגביל זאת.
6. ואז, ורק אז, עברו לניסיונות ניצול מלאים. בשלב זה, עליך לדעת בדיוק מה אתה מנסה להוכיח, במקום פשוט לזרוק מטענים על קופסה שחורה.

בתהליך זה, פענוח חתימת json web הוא שכבת הנראות עבור שאר מתודולוגיית ההתקפה שלך.

שילוב פענוח חתימות אינטרנט json בצינור בדיקות חדירות מונחה AI (Penligent.ai)

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

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

לאחר בניית בסיס זה, מנוע ההתקפה של Penligent יכול להפעיל באופן אוטומטי תסריטי JWT / JWS שנבחרו בקפידה: ניסיונות חתימה ריקה, תרחישי בלבול אלגוריתמים, JWK מוטמע או jku התעללות, ובדיקות ידועות בהשראת CVE. במקום להשאיר את הבדיקות הללו לזיכרונו של האדם, המערכת מתייחסת אליהן כאל מקרי בדיקה חוזרים ונשנים המבוצעים על כל יעד, ומזינה את התוצאות לרשימת סיכונים המבוססת על ראיות ולדוח הניתן לקריאה על ידי מחשב.

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

רשימת בדיקה להקשחה וקריאה נוספת

אם העבודה היומית שלך כוללת הנפקת או אימות אסימוני JWS / JWT, אתה יכול להתייחס לזה כאל רף מינימום:

• אכוף רשימה קפדנית של אלגוריתמים מותרים בצד השרת; לעולם אל תקרא אלג מאותו אסימון לא מהימן כמדיניות.
• הפרידו בין מפתחות חתימות א-סימטריות וסודות HMAC; לעולם אל תשתמשו במפתח ציבורי RSA כמפתח HMAC.
• השבת לצמיתות אף אחד בספריות הייצור ולדחות כל אסימון שמפרסם אותו.
• טפל בכל שדות הכותרת (ילד, jku, jwk, x5u) כקלט לא מהימן ולאמת אותם מול קבוצת מפתחות קבועה או רשימת היתרים.
• עדכן את ספריות JWT שלך; בדוק מעת לעת את ה-CVE כגון CVE-2015-9235, CVE-2018-1000531, CVE-2023-48238 ו-CVE-2024-54150 כדי לראות אם הסטאק שלך מושפע. (המעבדה של סוויסקי)
• הוסף בדיקות רגרסיה המפעילות במפורש תרחישים של אי-בלבול/בלבול אלגוריתמים.

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

• הליבה [JSON Web Signature (JWS) RFC 7515] מ-IETF. (מעקב נתונים של IETF)
• הפרק של OWASP בנושא [בדיקת אסימוני JSON Web] במדריך לבדיקות אבטחת אינטרנט. (קרן OWASP)
• מעבדות האקדמיה לאבטחת אינטרנט של PortSwigger בנושאי [התקפות JWT] ו[בלבול אלגוריתמים]. (PortSwigger)
• המאמר הקלאסי של טים מקלין ב-Auth0 על [פגיעויות קריטיות בספריות JSON Web Token]. (Auth0)
• הטיוטה המתפתחת של [JWT Best Current Practices] בקבוצת העבודה OAuth של IETF. (IETF)

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