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

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

Daniel Rubery
Daniel Rubery
José Luis Zapata

מבוא

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

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

איך DBSC עובד

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

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

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

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

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

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

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

שלבי ההטמעה

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

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

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

1. שינוי תהליך הכניסה

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

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

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

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

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

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

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

  • משייכים את המפתח הציבורי שהתקבל לסשן של המשתמש.
  • התשובה תהיה הגדרת סשן.
  • מחליפים את קובץ ה-cookie לטווח ארוך בקובץ 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-Secure-Session-Id: session_id

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

    HTTP/1.1 403 Forbidden
Secure-Session-Challenge: "challenge_value"

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

    POST /RefreshEndpoint HTTP/1.1
Sec-Secure-Session-Id: session_id
Secure-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.