Authentication ו-Authorization נכון

📚 אבטחת מידע עם Claude ⏱️ 12 דק׳ 🎓 בינוני ✓ חינם לגמרי
Authentication ו-Authorization נכון

כשהמנעול פתוח, למה Authentication ו-Authorization הם עדיין הבעיה מספר 1

OWASP Top 10:2025 פורסם בתחילת 2025. המקום הראשון, Broken Access Control, שוב. המקום השביעי, Authentication Failures. שניהם יחד אחראיים לרוב פריצות הנתונים המשמעותיות שקרו בשנים האחרונות. זה לא כי הפתרונות לא קיימים, JWT, OAuth2, RBAC כולם תיעוד ב-open source. זה כי מפתחים שוב ושוב עושים את אותן שלוש טעויות. Claude יכול לשמש כ-security reviewer שקורא את הקוד שלך, מוצא את הפרצות, ומסביר בדיוק מה לתקן.

Authentication לעומת Authorization, שני מושגים שמתבלבלים כל הזמן

ההבחנה פשוטה אבל קריטית: Authentication = מי אתה? (login, JWT verification, session check). Authorization = מה מותר לך לעשות? (האם מותר לך לגשת ל-/api/reports/42? לעדכן חשבון משתמש אחר?). הכישלון הנפוץ: מפתחים בודקים את ה-Authentication ("האם המשתמש מחובר?") אבל שוכחים את ה-Authorization ("האם המשתמש הזה מורשה ל-resource הזה?").

זו הבעיה הקלאסית של IDOR (Insecure Direct Object Reference): endpoint /api/orders/1234 מחזיר הזמנה לכל משתמש מחובר, גם אם ההזמנה שייכת למשתמש אחר. סטארטאפ ישראלי בתחום ה-fintech גילה ב-2023 שכל לקוח יכול לראות את הזמנות הלקוחות האחרים פשוט על ידי שינוי ה-ID ב-URL. 40,000 לקוחות נחשפו.

מושגשאלה שנשאלתדוגמהכלי נפוץ
Authenticationמי אתה?האם ה-JWT תקף?JWT, Sessions, OAuth2
Authorizationמה מותר לך?האם מותר לך ל-/admin?RBAC, ABAC, Middleware
IDOR Protectionהאם זה שלך?order.userId === req.user.id?Ownership check ב-DB query

JWT, שלוש הטעויות שעושים שוב ושוב

JWT (JSON Web Token) הוא הסטנדרט הנפוץ ביותר ל-stateless authentication. הוא מורכב מ-Header, Payload, ו-Signature. הבעיות לא ב-JWT עצמו, הן ב-implementation.

כתוב לי JWT authentication ב-Node.js
בצע security review על JWT middleware הבא. בדוק: 1) האם algorithm מוגדר explicitly ולא נלקח מה-token? 2) האם יש exp claim סביר (פחות מ-24 שעות)? 3) האם ה-token מאוחסן ב-httpOnly cookie ולא localStorage? 4) האם ה-secret ארוך מספיק (256 bits)? 5) האם יש jti + blacklist לrevocation? לכל בעיה: חומרה, סיכון, קוד מתוקן. [הדבק קוד כאן]

RBAC, בניית מערכת הרשאות שלא תישבר

RBAC (Role-Based Access Control) הוא הגישה הנפוצה ביותר לניהול הרשאות. העיקרון: הגדר roles, הגדר permissions לכל role, בדוק בכל request. שלושה כללים שחייבים לאמץ:

  1. Fail Secure, ברירת מחדל: deny. כל resource חדש שנוסף אוטומטית חסום לכולם עד שמגדירים explicitly מי מורשה. הגישה ההפוכה (ברירת מחדל: allow) היא פצצת זמן.
  2. Least Privilege. כל role מקבל רק את ההרשאה המינימלית הדרושה. אל תיתן ל-manager הרשאות שרלוונטיות ל-super_admin.
  3. Logging של כל ניסיון גישה. גם מורשה וגם לא-מורשה. בלי audit trail אי אפשר לחקור incident.

כשלונות ב-RBAC של אגף ה-IT בחברות גדולות בישראל נובעים לרוב מ"role bloat": כל עובד מקבל role חדש כי "זה יותר קל", עד שיש 47 roles שאף אחד לא מבין. Claude יכול לנתח permissions matrix קיים ולזהות overlaps, redundancies, ו-privilege escalation paths.

OAuth 2.1 ו-PKCE, מה השתנה ב-2025

RFC 9700 פורסם בינואר 2025, עשר שנות לקחים מ-OAuth 2.0 בפורמט Best Current Practice. ה-takeaway המרכזי: OAuth 2.1 עושה PKCE חובה לכל client, כולל server-side web apps, לא רק mobile. ו-Implicit Flow הוסר לחלוטין מהספציפיקציה.

למה PKCE חשוב? בלי PKCE, authorization code שנגנב באמצע (man-in-the-middle) יכול להחלף ב-token. PKCE מוסיף code_verifier ו-code_challenge שמבטיחים שרק הclient שהתחיל את ה-flow יכול לסיים אותו.

בקש מ-Claude: "הסבר מה ההבדל בין Authorization Code Flow עם PKCE לבין Implicit Flow שהוסר מ-OAuth 2.1. כתוב Node.js implementation מלא של PKCE flow עם state parameter, nonce, ו-CSRF protection."

כי localStorage עובד רק ב-HTTP, לא ב-HTTPS
כי JavaScript יכול לקרוא localStorage, ולכן XSS attack יוכל לגנוב את ה-token
כי localStorage מוגבל בגודל ולא יכול להכיל token ארוך
כי localStorage חשוף ל-CORS attacks מ-domains אחרים
לאפשר גישה לכל endpoint שלא הוגדר explicitly כחסום
לחסום כל resource חדש כברירת מחדל, לאפשר רק מה שהוגדר explicitly
להציג הודעת שגיאה גנרית כדי לא לחשוף מידע למשתמש
לרשום כל ניסיון גישה לא-מורשה ל-audit log
RFC 6749, ה-OAuth 2.0 המקורי
RFC 7636, שהגדיר PKCE לראשונה
RFC 9700, Best Current Practice ל-OAuth 2.0, ינואר 2025
RFC 8725, JWT Best Practices
להאריך את ה-expiry time כדי שהמשתמש יצטרך להתחבר מחדש לעיתים רחוקות
לשמור את ה-token בצד השרת ולבדוק אותו בכל request
להוסיף jti claim לכל token ולשמור blacklist של ה-jti values של tokens שבוטלו
להחליף את ה-JWT secret ולחייב התחברות מחדש לכולם

איך לבקש מ-Claude security review על auth code

Claude מצוין בניתוח authentication code כשנותנים לו הקשר מספיק. Anthropic עצמה השתמשה ב-Claude Code לסריקת open-source codebases ומצאה מעל 500 vulnerabilities שהיו שם עשרות שנים. הגישה הטובה ביותר:

  1. הדבק את ה-auth middleware המלא, לא קטעים. Claude צריך לראות את כל ה-flow.
  2. תן context על הארכיטקטורה, "זה Node.js + Express + Postgres, JWT stateless, SPA בצד הלקוח".
  3. בקש role-play כ-attacker, "תנסה לפרוץ את ה-auth שלי. מה תנסה ראשון?"
  4. בקש קוד מתוקן, לא רק רשימת בעיות, גם הפתרון המלא.

טעויות נפוצות ואיך להימנע מהן

סיכום, מה לזכור

מקורות: OWASP Top 10:2025 | RFC 9700, OAuth 2.0 Security Best Current Practice | OAuth 2.1, What's New | Claude Code Security, Anthropic

רוצה ללמוד עם מעקב התקדמות, קוויזים ותעודה?

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