במהלך סקירת אבטחה של פריסת ה-Discourse המותאמת אישית שלנו, מצאנו חשיפה פוטנציאלית של מידע רגיש בממשק Admin > Settings בנוגע לסודות לקוח OAuth2.
פרטים
בדף תצורת הניהול, סוד הלקוח של OAuth2 (ואולי אסימונים/מפתחות רגישים אחרים) מוצגים בטקסט רגיל, במקום להיות מוסתרים (למשל עם כוכביות).
מנהלים נדרשים להזין ישירות את הסוד הגלוי להגדרות. כל מי שיש לו גישה לממשק הניהול יכול לראות את הסוד המלא.
אם תוקף משיג גישה (אפילו זמנית) להפעלת מנהל, הוא יכול בקלות להשיג את סוד הלקוח ולהשתמש בו לבקשות אסימון OAuth2 לא מורשות או לזיוף בקשות לשירותי צד שלישי.
השפעת אבטחה
חשיפת סודות בטקסט רגיל בממשק הניהול מגבירה את הסיכון לדליפת פרטי הזדהות.
היעדר הסתרה אינו עולה בקנה אחד עם שיטות עבודה מומלצות לאבטחה בטיפול בסודות.
ניתן לנצל לרעה את הסודות/אסימונים להסלמת הרשאות, התחזות או התקפות נוספות נגד שירותים משולבים.
שאלות
האם יש תוכנית להסתיר שדות רגישים כמו סודות OAuth2 בממשק הגדרות הניהול (למשל, להציג כ-****** עם אפשרות לחשוף במידת הצורך)?
האם יש גישות מומלצות או תוספים להגברת ההגנה על פרטי הזדהות רגישים בפריסות Discourse?
האם הנושא נדון בעבר? האם קיימים פתרונות עוקפים עד לתיקון רשמי?
Hey @Evie_Tao
You are reporting lots of security concerns. Have you thought about reporting them on HackerOne, as it’s explained in the GitHub repository?
We don’t consider information disclosure to administrators a problem, but yes it should be marked as sensitive to avoid showing up unnecessariliy, the same as e.g. google_oauth2_client_secret.
This is a simple fix:
There’s a tradeoff of secrecy vs. convenience; not allowing the secrets to be unmasked in the UI would only provide an illusion of inaccessibility, there’s other ways for an admin to easily read it from the database.
However, any secrets (any site setting really) can be specified via the environment, then they won’t show up in the admin UI.