ארכיטקטורת ניהול משתמשים עם רמות גישה שונות

[צדיק תמים]

@avi-rz כתב בארכיטקטורת ניהול משתמשים עם רמות גישה שונות:

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

מה המשמעות האבטחתית לזה שמבינים את מבנה הטבלאות במערכת?
כנ"ל כתובת ההתחברות של המנהל. עדיף להתמקד באבטחה ולא באבטחה באמצעות הסתרה

[dovid]

אדגיש קודם שבמקרה הזה התשובות שאני אומר הם לא דעתי האישית או נטיית דעה/לב, אלא עקרונות מאוד חד משמעיים שמקובלים בכל מערכת נורמלית.
א. טבלת users אחת. role בטבלה או בטבלה נפרדת, אני מעדיף נפרדת עם אפשרות של יותר מrole אחד למשתמש.
ב. הסתרת נקודת קצה לא מועילה כלום באבטחה. זה נכון שיהיה קשה לתוקף לדעת, אבל זה לא נחשב שעשית אפילו מילמטר מבחינת אבטחה.
אם האבטחה שלך היא ללא פגם, לא היית מרגיש צורך בסניף המסכן הזה, ולהיפך, אם יש לך קצת הישענות על הסתרת נקודת הקצה של המנהל, יש פגם באבטחה שלך. זה צריך להיות מאה אחוז גם אם כל העולם יודע.
(יש אמנם עיקרון של ערפול כאבטחה (Security through obscurity ראה פה), אבל הוא עיקרון מצומצם שאף פעם לא צריך לעמוד בשיקולי ארכיטקטורה, ובשום אופן לא להיות אפילו סניף לאבטחה. זה אולי אולי תוספת להוסיף למהדרים אחרי שהמערכת 100 אחוז, אני בעד לוותר על ההידור שמביא לידי קולות).
אם אתה רוצה להתייעץ על איך ניתן לפרוץ למערכת שלך והאם האבטחה שלך מספיקה, זה נושא מעולה לדיון.

[dovid]

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

[avi rz]

תודה למשיבים!
אציין, שאני מבחינתי יעשה את האבטחה שאני חושב שהיא מספיקה - או שהתייעץ עליה עוד.
לשם הדוג' ניקח את express-session וחסימה אחרי 3-5 כניסות שגויות של אותו שם משתמש בX זמן וכמו"כ חסימת IP שיש לו X כניסות שגויות ב X זמן.
אממה, גם IPים וגם שם משתמש אפשר להחליף כל הזמן, ואז מה? למה לחסום את אותו אחד שניסו להיכנס אליו? זה אחד.
2. לגבי מה ש @צדיק-תמים אמר, "שמבינים את מבנה הטבלאות במערכת",
כוונתי הייתה, לרעיון שלחדור בכביש שכולם נוסעים שם, יותר קשה מלחדור בכביש VIP שרק המנהל נוסע שם - סתם הרגשה כזו.
מה גם שחשבתי אולי בגישה של ניהול / סוכן - אוכל להשים עוד מזהה, כמו קוד סוכן וכו'. שזה גם כבר מצריך גישה נפרדת בצד לקוח.

[dovid]

@avi-rz
מיותר החסימה, אתה לא צריך לעשות שום דבר מקורי.
אמנם אתה כן צריך לחייב סיסמה ארוכה וקשה (ואם זה מאוד רגיש ויש מקום לחשש אז לחייב Two Factor).
שים לב בexpress-session מקבל secret, שים שמה משהו רנדומלי.
ראה גם הערה בהמשך לגבי גיבוב הסיסמה - זה לא מוסיף אבטחה על האתר אלא מגן על סיסמת המשתמש.
עד כאן זה הטכניקה, וכפי שאתה רואה אין פה כמעט כלום. אז איך כל הזמן יש פריצות לאתרים? בגלל לוגיקה שגויה של מפתח, ודי במקום אחד לאורך כל היישום.
יש כמה סוגים עיקריים, אני שם לפי סדר התדירות לדעתי:
א. חוסר ביקורתיות על קלט משתמש. זה כולל כמה וכמה התקפות, אני ארחיב בהמשך.
ב. חוסר התבוננות על השלכות של פעולות, שמאפשרות למשתמש בהינתן מצבים מסויימים למצל אותם.
ג. מימוש בדיקת אבטחה בצורה לקויה או באופן לא מספק.
ד. טעויות של ממש ובאגים, שמשתמש הצליח לקלוט ולנצל.

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

א. חוסר ביקורתיות על קלט משתמש

זו הבעיה מספר 1 שאין מצב להינצל ממנה בלי אימון של חשיבה ביקורתית.

• sql injection קלאסי (שרשור טקסט) ופחות קלאסי שזה קצת הסעיף הבא).
• קלטים לא צפויים במבט של מפתח נחמד, אלא רק עם ביקורת קצת קרימינלית:
  למשל אתה מצפה לקבל מספר שלם בין 1 ל10, ואפילו מוודא את זה עם פונקציה, ואתה גם מוודא שלא מדובר ב5 כי זה צריך הרשאה משמעותית יותר. אבל המשתמש החכם שם 4.9 שזה לא 5... בהכנסה למסד זה מתעגל ל5 - מספר שלם בגלל איזה ספריה כשרונית כל שהיא שמתאימה את הקלט לשדה שהוא מסוג מספר שלם.
  דוגמה גרועה יותר זו בדיקה טקסטואלית על קלט שבסוף מספרי אפליקטיבית - param != '5', ואז המשתמש שולח לך 5.0 או 05...
• קלטים קיצוניים שגורמים לבאג/שגיאה שמבחינה לוגית מביאה למשתמש ייתרון שלא אפשרת לו בcontrole flow. למשל שמת try אבל הקוד ממשיך אח"כ, בלי החלק האבטחתי שבתוך הtry (זה לא קשור לקלט משתמש דוקא, כי יש עיקרון: כל try עיוור, שמאפשר להכיל כל שגיאה, הוא פוטנציאלית בעיית אפליקציה ולעיתים בעיית אבטחה. לא לעשות try-catch בלי שיודעים מה תהיה השגיאה).
  למשל אתה מקבל מייל ומוודא עליו משהו, אבל לא חשבת שיכול להיות שהמשתמש ישלח מחרוזת באורך של מגה... אבל לא היה קורה כלום אם לא שבעודף תבונה שמו try שמה על משהו, ובחוסר תבונה לא דאגו שכל catch לא צפוי יזרוק שוב שגיאה (כל המפתחים כמעט כולל עבדך הנאמן מוותרים על הרעיון...) הקוד בהמשך הוא יכול להיכשל (הכי טוב) ואולי להשאיר תוצאות לא רצויות (פחות טוב) ולפעמים לאפשר משהו שלא רצינו (פירצת אבטחה).

ב. חוסר התבוננות על השלכות של פעולות שאפשרו למשתמש לבצע

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

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

ג. מימוש בדיקת אבטחה בצורה לקויה או באופן לא מספק.

• ניסיון מימוש אבטחה מקורי/אישי, כשמדובר במקרה קלאסי ובפרט סבוך.
  למשל טיהור קלט פרמטרי SQL על ידי החלפות או עטיפה במרכאות וכדומה, במקום טכניקה של פרמטרים.
  טיהור HTML עם regex וכדומה, במקום שימוש בספריה עם שימוש מסיבי בתעשייה.

הערה בקשר לגיבוב סיסמה:
שים לב שמבחינת אבטחה יש לשמור בבסיס הנתונים רק גיבוב + מלח.
המלח זה קשקוש שאתה מייצר בעת בחירת סיסמה, והוא עושה שהסיסמה מורכבת ממה שהמשתמש בחר + הקשקוש שיצרת, מה שעושה את הגיבוב לייחודי אף ביחס לאותה סיסמה.
הגיבוב זה תוצאת פונקציית גיבוב תקנית כמו SHA1 על התרכובת של הסיסמה והמלח.
בעת כניסה אתה לוקח מהמסד את הגיבוב והמלח, ובודק אם פלט הפונקציה על קלט הסיסמה של המשתמש יחד עם המלח מביא את אותו גיבוב ששמור לך.

[dovid]

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

[yossiz]

למרבה הצער passkeys הם עדיין לא נחלת הכלל. לטעמי זו האופציה הכי נוחה ובטוחה

[צדיק תמים]

@yossiz כתב בארכיטקטורת ניהול משתמשים עם רמות גישה שונות:

למרבה הצער passkeys הם עדיין לא נחלת הכלל. לטעמי זו האופציה הכי נוחה ובטוחה

למשתמש המצוי כניסה עם חשבון גוגל יותר נוחה משמעותית
אני חושב גם שאי אפשר להשתמש בpasskey אם אין למחשב סיסמת כניסה

[מד]

@צדיק-תמים כתב בארכיטקטורת ניהול משתמשים עם רמות גישה שונות:

אני חושב גם שאי אפשר להשתמש בpasskey אם אין למחשב סיסמת כניסה

נכון, וחוץ מזה passkey זה רק על אותו מחשב.

[צדיק תמים]

@מד כתב בארכיטקטורת ניהול משתמשים עם רמות גישה שונות:

@צדיק-תמים כתב בארכיטקטורת ניהול משתמשים עם רמות גישה שונות:

אני חושב גם שאי אפשר להשתמש בpasskey אם אין למחשב סיסמת כניסה

נכון, וחוץ מזה passkey זה רק על אותו מחשב.

אפשר לשמור אותו במנהל הסיסמאות של הדפדפן (כלומר של גוגל) ואז זה מסתנכרן כמו סיסמאות

[ששא]

@dovid כתב בארכיטקטורת ניהול משתמשים עם רמות גישה שונות:

הדרך הקלה ביותר בעיני פה בארץ זה כניסה באמצעות גוגל

@צדיק-תמים כתב בארכיטקטורת ניהול משתמשים עם רמות גישה שונות:

למשתמש המצוי כניסה עם חשבון גוגל יותר נוחה משמעותית

האם כניסה וכן הרשמה באמצעות גוגל היא אכן הדרך הכי טובה?
והאם אני לא מוסר לאתר שאליו אני נרשם איזה ממני/עלי?
זה מומלץ?

[dovid]

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

[ששא]

@dovid ומבחינת אבטחה זה הכי מאובטח?

[dovid]

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