פרטי כניסה לסשן לפי מכשיר (DBSC)

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

Daniel Rubery
Daniel Rubery
José Luis Zapata

מבוא

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

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

איך פועל DBSC

ברמה גבוהה, DBSC מציג זוג מפתחות קריפטוגרפיים שמשויך למכשיר של המשתמש. Chrome יוצר את זוג המפתחות הזה במהלך ההתחברות, ומאחסן את המפתח הפרטי בחומרה מאובטחת, כמו Trusted Platform Module‏ (TPM), אם הוא זמין. בסשנים נעשה שימוש בקובצי cookie לטווח קצר. כשפג התוקף של אחד מקובצי ה-Cookie האלה, Chrome מוכיח שהוא הבעלים של המפתח הפרטי לפני שהוא מרענן אותם. התהליך הזה מקשר את המשך הסשן למכשיר המקורי.

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

סקירה כללית על ההטמעה

כדי לשלב את DBSC באפליקציה, צריך לבצע את השינויים הבאים:

  • משנים את תהליך הכניסה כך שיכלול כותרת Sec-Session-Registration.
  • מוסיפים נקודת קצה לרישום סשנים:
    • משייך מפתח ציבורי לסשן של המשתמש.
    • הגדרת הסשן.
    • מעבר לקובצי cookie לטווח קצר.
  • מוסיפים נקודת קצה לרענון כדי לטפל בחידוש של קובצי cookie ובהוכחת החזקה במפתח.

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

אם קובץ cookie לטווח קצר נדרש וחסר או שפג התוקף שלו, Chrome משהה את הבקשה ומנסה לרענן את קובץ ה-cookie. כך האפליקציה תמשיך להשתמש בבדיקות הרגילות של קובצי ה-cookie של הסשן כדי לוודא שהמשתמש מחובר. מכיוון שהתהליך הזה תואם לתהליכי אימות רגילים, DBSC פועל עם שינויים מינימליים בלוגיקה של הכניסה.

שלבי ההטמעה

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

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

תרשים שבו מוצג תהליך DBSC

1. שינוי תהליך ההתחברות

אחרי שהמשתמש מתחבר, צריך להשיב עם קובץ cookie לטווח ארוך וכותרת Sec-Session-Registration. לדוגמה:

כותרת התגובה הבאה של HTTP מוחזרת אחרי רישום מוצלח של הסשן:

HTTP/1.1 200 OK
Sec-Session-Registration: (ES256 RS256); path="/StartSession"
Set-Cookie: auth_cookie=session_id; max-age=2592000; Domain=example.com; Secure; SameSite=Lax

אם המכשיר תומך באחסון מאובטח של מפתחות, Chrome יוצר קשר עם נקודת הקצה /StartSession עם מפתח ציבורי באסימון JWT (JSON Web Token).

הערך auth_cookie בדוגמה הזו מייצג את אסימון הסשן. אתם יכולים לתת לקובץ ה-Cookie הזה שם כלשהו, כל עוד הוא תואם לשדה name בהגדרת הסשן, ונעשה בו שימוש עקבי בכל האפליקציה.

2. הטמעת נקודת הקצה של רישום הסשן

בשדה /StartSession, השרת צריך:

  • משייכים את המפתח הציבורי שהתקבל לסשן של המשתמש.
  • משיבים עם הגדרת סשן.
  • מחליפים את קובץ ה-cookie לטווח ארוך בקובץ לטווח קצר.

בדוגמה הבאה, תוקף קובץ ה-cookie לטווח קצר מוגדר לפוג אחרי 10 דקות:

HTTP/1.1 200 OK
Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; # Expires after 10 minutesSet-Cookie: Domain=example.com; Secure; SameSite=Lax

{
  "session_identifier": "session_id",
  "refresh_url": "/RefreshEndpoint",
  "scope": {
    "origin": "https://example.com",
    "include_site": true,
    "scope_specification": [
      { "type": "exclude", "domain": "*.example.com", "path": "/static" }
    ]
  },
  "credentials": [{
    "type": "cookie",
    "name": "auth_cookie",
    "attributes": "Domain=example.com; Secure; SameSite=Lax"
  }]
}

3. הטמעה של נקודת הקצה לרענון

כשפג התוקף של קובץ ה-cookie לטווח קצר, Chrome מתחיל תהליך רענון כדי להוכיח שהוא מחזיק במפתח הפרטי. התהליך הזה כולל פעולות מתואמות של Chrome ושל השרת:

  1. Chrome מעביר את הבקשה של המשתמש לאפליקציה שלכם ושולח בקשת רענון אל /RefreshEndpoint:

    POST /RefreshEndpoint HTTP/1.1
Sec-Session-Id: session_id

  2. השרת מגיב עם אתגר:

    HTTP/1.1 401 Unauthorized
Sec-Session-Challenge: "challenge_value"

  3. Chrome חותם על האתגר באמצעות המפתח הפרטי שנשמר ומנסה שוב את הבקשה:

    POST /RefreshEndpoint HTTP/1.1
Sec-Session-Id: session_id
Sec-Session-Response: <JWT proof>

  4. השרת מאמת את ההוכחה החתומה ומנפיק קובץ cookie מעודכן לטווח קצר:

    HTTP/1.1 200 OK

Set-Cookie: auth_cookie=short_lived_grant; Max-Age=600; Domain=example.com; Secure; SameSite=Lax

  5. Chrome מקבל את קובץ ה-cookie המעודכן וממשיך את הבקשה המקורית שהועברה זמנית.

דפוס שילוב חלופי

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

  • קובץ ה-cookie לטווח ארוך נשאר גם אם ה-DBSC נכשל.
  • קובץ ה-cookie לטווח קצר מתעדכן באמצעות DBSC והוא נדרש לפעולות רגישות.

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

אזהרות והתנהגות חלופית

Chrome עשוי לדלג על פעולות של DBSC ולשלוח בקשות בלי קובץ ה-cookie לטווח קצר שמנוהל על ידי DBSC בתרחישים הבאים:

  • אי אפשר לגשת לנקודת הקצה לרענון בגלל שגיאות ברשת או בעיות בשרת.
  • ה-TPM עסוק או נתקל בשגיאות חתימה. מאחר שה-TPM משותף בין תהליכי המערכת, רענונים מוגזמים עלולים לחרוג ממגבלות הקצב שלו.
  • קובץ ה-cookie לטווח קצר שמנוהל על ידי DBSC הוא קובץ cookie של צד שלישי, והמשתמש חסמ קובצי cookie של צד שלישי בהגדרות הדפדפן שלו.

במקרים כאלה, Chrome חוזר להשתמש בקובץ ה-cookie לטווח ארוך, אם הוא עדיין קיים. חלופה זו פועלת רק אם ההטמעה כוללת גם קובץ cookie לטווח ארוך וגם קובץ cookie לטווח קצר. אם לא, Chrome שולח את הבקשה בלי קובץ cookie.

סיכום

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

מידע נוסף זמין במפרט של DBSC.