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

dovid
-
ארכיטקטורת ניהול משתמשים עם רמות גישה שונות -
ארכיטקטורת ניהול משתמשים עם רמות גישה שונות@ששא אתה מקבל אזהרה בדיוק מה האתר רוצה לקבל (הוא יכול לבקש דברים מפליגים אבל האזהרה תהיה בהתאם).
בדרך כלל משתמש מסכים לתת שם של החשבון הציבורי, מייל ותמונת חשבון.
אני בהחלט אוהב את הדרך הזו, אני מרגיש יותר נח איתה. -
ארכיטקטורת ניהול משתמשים עם רמות גישה שונותאפרופו סיסמה ארוכה וקשה, זו בעיה שכולם שוברים עליה את הראש (כי המשתמשים ממש לא זורמים עם זה, וגם הסיסמאות נוראות או כתובות מפורש או משותפות בין משתמשים).
הדרך הקלה ביותר בעיני פה בארץ זה כניסה באמצעות גוגל, ככה זה מגלגל את הבעיה אליהם (והם מסתדרים נהדר למעט עם נעדרי הSMS...). איפה שזה אפשרי זה חוסך הרבה כאבי ראש פיתוח. -
רעיון לפיתוח שימושי ונצרך -
ארכיטקטורת ניהול משתמשים עם רמות גישה שונות@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 על התרכובת של הסיסמה והמלח.
בעת כניסה אתה לוקח מהמסד את הגיבוב והמלח, ובודק אם פלט הפונקציה על קלט הסיסמה של המשתמש יחד עם המלח מביא את אותו גיבוב ששמור לך. -
ארכיטקטורת ניהול משתמשים עם רמות גישה שונותאני ביומיום, חוסם פעולות בצד שרת למי שלא בrole המתאים, ובצד לקוח לעיתים חוסם תצוגות ולעיתים רק מסתיר לינקים/ניווט, יש גם שיקולים ארגוניים למשל שהעובד לא יראה שמהנהל יכול או לא יכול לעשות פעולה וכדומה. בצד לקוח בדרך כלל כיום הכל סטטי ונגיש, ומי שמבין עניין יכול לדעת הכל על מבנה הניהול - מצד הממשק - אם זה אותה מערכת).
במקרים נדירים שנדרשת הסתרה (לא אבטחה!) משמעותית יותר - אני בד"כ מחזיר תצוגות מרונדרות בצד שרת. -
ארכיטקטורת ניהול משתמשים עם רמות גישה שונותאדגיש קודם שבמקרה הזה התשובות שאני אומר הם לא דעתי האישית או נטיית דעה/לב, אלא עקרונות מאוד חד משמעיים שמקובלים בכל מערכת נורמלית.
א. טבלת users אחת. role בטבלה או בטבלה נפרדת, אני מעדיף נפרדת עם אפשרות של יותר מrole אחד למשתמש.
ב. הסתרת נקודת קצה לא מועילה כלום באבטחה. זה נכון שיהיה קשה לתוקף לדעת, אבל זה לא נחשב שעשית אפילו מילמטר מבחינת אבטחה.
אם האבטחה שלך היא ללא פגם, לא היית מרגיש צורך בסניף המסכן הזה, ולהיפך, אם יש לך קצת הישענות על הסתרת נקודת הקצה של המנהל, יש פגם באבטחה שלך. זה צריך להיות מאה אחוז גם אם כל העולם יודע.
(יש אמנם עיקרון של ערפול כאבטחה (Security through obscurity ראה פה), אבל הוא עיקרון מצומצם שאף פעם לא צריך לעמוד בשיקולי ארכיטקטורה, ובשום אופן לא להיות אפילו סניף לאבטחה. זה אולי אולי תוספת להוסיף למהדרים אחרי שהמערכת 100 אחוז, אני בעד לוותר על ההידור שמביא לידי קולות).
אם אתה רוצה להתייעץ על איך ניתן לפרוץ למערכת שלך והאם האבטחה שלך מספיקה, זה נושא מעולה לדיון. -
התקנת כרום בגירסא נמוכה לצד גירסא מתקדת יותר.@YK כתב בהתקנת כרום בגירסא נמוכה לצד גירסא מתקדת יותר.:
המטרה היתה דפדפן שמאשר/סומך על הגדרה של 'X-Frame-Options'.
ועכשיו תלך עוד יותר אחורה ותגיד מה הבעיה שלך המקורית המקורית,
אולי נפתיע ונעזור הרבה יותר מהGPT... -
מקלדת ועכבר משולבים, או - פיתרון לתנוחה לא טבעית של הזרוע@יוסף-בן-שמעון אני מרגיש שהגובה שלך לא מתאים,
אתה בדקת את זה?
המקלדת והעכבר צריכים להיות במשטח שגובהו באיזור המקום של המרפקים כשהם לצד הגוף.
גם ככה, כואב לך המעבר לעכבר? -
טאבלט בלי כלום חוץ מקריאה של ספרים@pcinfogmach קינדל זה שם של קורא ספרים של אמזון,
יש מלא חברות של קוראי ספרים, ובהרבה אין שום דבר חוץ מלקרוא,
אבל נראה לי שהם גם לא אידאלים ל"הצגת קבצים" אלא רק לפורמטים של ספרים.
כמו"כ אין להם סייר נוח.הכי טוב זה התאמת אנדרואיד כמו שהציע @shraga, זה השקעה חד פעמית של זמן ומחשבה ואח"כ אתה יכול להוציא פס ייצור.
-
בניית תקציב באקסלאתה כותב את הנתונים בצורת טבלה שטוחה,
עמודות למשל: תאריך, סכום, קטגוריה, תת קטגוריה ...
אחרי הזנת נתונים כל שהם צור PivotTable (בכרטסת הוספה, כשהתא הנבחר על אחד התאים שמילאת)
בעריכת הPivotTable גרור מאיזור השדות ל"שורות" את תאריך, קטגוריה, תת קטגוריה, ואת השדה סכום לאיזור ערכים. -
API מומלץ לתכנון מסלול@צדיק-תמים זה חדש, אם אני לא טועה לא היה מענה לזה.
לזכרוני זה עולה יותר יקר להשתמש בספריות ולחשב לבד.
אתה צריך לדעת כל מיקום מה המרחק שלו מכלל המיקומים האחרים (לא אווירי/גאוגרפי שזה מספיק חישוב על הנ.צ., אלא מרחק תחבורתי), זה יוצא מלא בקשות. -
API מומלץ לתכנון מסלול -
API מומלץ לתכנון מסלוללזכרוני google maps לא נותן אופציה של ריבוי כתובות במסלול אחד (מציאת מסלול אופטימלי).
אני מכיר ארגון שמשתמש ב https://getcircuit.com/ (ידנית בלי API)
יש להם API -
https://developer.team.getcircuit.com/ -
ווינדוס 11 HOME לא מופיע סמל WIFI@שוהם307 תשתף דגם מדוייק,
תצרף תמונה של מנהל ההתקנים אחרי פתיחה של הצומת "מתאמי רשת" (אם באנגלית network adapters) -
אפליקציית wpf מקומפלת ל־.NET Framework 4.7.2 לא עובדת על Windows 11@Mordechai-0 כתב באפליקציית wpf מקומפלת ל־.NET Framework 4.7.2 לא עובדת על Windows 11:
חברינו היקר ביקש כיווני בדיקה, וזה בדיוק מה שנתתי לו – כלי פשוט שיכול לעזור להבין מה קורה אצלו במחשב, בלי להיכנס לדיון עקרוני על גרסאות .NET ומה "אמור" לעבוד.
השאלה שלו בתמצית זה איך לגרום לNET 4.8 לכבד תוכנה שנסגרה בNET 4.7, אתה לא מקדם אותו במילימטר.
הוא סיפר:
א. אני סוגר ב NET 4.8 זה עובד מצויין ב11, אבל לא עובד ב10 בלי עדכון NET
ב. אני סוגר בNET 4.7 זה לא עובד ב11
ג. אני רוצה לסגור באופן שיתאים לשניהםכיווני הבדיקה שהוא רצה הם לשאלתו ולא לשאלות אחרות שיוצאות מהפוסט שלו.
אולי ההודעה שלך עוזרת לוודא שהבעיה היא פרימוורק חסר, יכול להיות.
אגב, לא באמת חשבתי שזה AI אלא חשבתי קריאה שטחית של פוסט שניבה תשובה שהזכירה לי AI של פעם. -
אפליקציית wpf מקומפלת ל־.NET Framework 4.7.2 לא עובדת על Windows 11@Mordechai-0 זה נראה AI מהסוג הדפוק....
במקרים רבים, השגיאה נגרמת בגלל שגרסת .NET מסוימת אינה מותקנת במחשב. בתוך הלוג תוכל למצוא גם קישור ישיר להורדת הגרסה החסרה.
זהו שבכל win11 מה שנסגר כ4.8 עובד ללא התקנה, אז הוא לא מבין למה 4.7 לא יכול להתקבל על ידו.
-
תקרה דקורטיבית מתפרקת@one1010 לא מפריע לי אם כותבים, סך הכל רציתי לעזור לך.
אני אכן אמליץ לכולם לעבור לכתוב שמה, ככל והפורום הזה יצליח - מקוה מאוד. -
תקרה דקורטיבית מתפרקת@one1010 אם היה קל טכנית לסגור היא הייתה סגורה ממזמן עם עשרות קטגוריות שהינם שארית של הפורום בזמנו של ברוך גולן. הוא היה מקצוען אמיתי בכל זה וגם ידע לייבא אנשים מהתחום.
לא כל כך מבין מה העומק של השאלה שלך,
אם יש לשאלה השלכות מעשיות פנה אלי בפרטי. -
תקרה דקורטיבית מתפרקת@מד לא יודע על מה אתם מתבססים,
נכון לעכשיו 259 צפיות שמה, ורק 200 פה.
זה לא קשור לעובדה ששמתי פה לינק כי זה בערך הצפיות שיש שמה להרבה נושאים.מלבד מה שבנושאי מקצוע בדרך כלל עדיף אחד שיודע ממאה שיודעים מעט,
אם מחפשים חכמת המונים פה זה ממש לא המקום...