VladiC4T
2020-06-01 00:35:57 UTC
אני בונה ממשק API עם שקע אינטרנט שמבצע סדרת נתונים באמצעות JSON. האפליקציה עצמה היא אפליקציית צ'אט. הגעתי למבנה הבא כדי לשלוח את הנתונים שלי:
{date: '2020-05-31', time: '14: 28: 05 ', text: "Hey!", אל: '<id: int>', מ: '<id: int>'} המשתמש בעצם שולח הודעה דרך הדפדפן וזה מתקבל בשרת רשת האינטרנט. ה מ: 'מזהה' יהיה מהמשתמש ששולח את הנתונים ואילו ה אל: 'מזהה' יהיה למשתמש שהנתונים נשלחים.
כשמסתכלים על זה יש לי תחושה רעה מאוד. המחשבות שלי; המשתמש המשתמש באפליקציה תאמת באופן תיאורטי ושם הוא יקבל את הזהות שלו. ואז למקלט יהיה מזהה אחר, כזה שאינו זהה לזה המאומת (ברור). לאחר מכן השרת יחפש את המזהה הזה וישלח את ההודעה, אבל אני לא בטוח אם זה מאובטח.
יש לי כמה היבטים שלדעתי חייבים להתמודד כראוי כדי להגן על האפליקציה מפני כל תוקף:
- מה אם התוקף יחליט לטפל ב" מ: id " כך שיוכל לשלוח הודעות שרירותיות לכל אחד מכל משתמש?
- מה אם התוקף בונה סקריפט שמסרב מיליוני הודעות על ידי ניצול השדה "ל: id"
האם יתכן ויש בעיה אבטחתית אחרת אני לא מודאג?
אנא אל תשתמש במזהים מספריים.במיוחד לא אם רצוף.אתה לא צריך לבנות מערכת שבה פשוט ניתן למנות את המשתמשים.השתמש במקום זאת במחרוזות אקראיות.אם אני משתמש 55, מי משתמש 54?אם אני משתמש ב- abfkg-4remq, סביר להניח ש- abfkg-4remr אפילו לא יהיה משתמש, ולכן כתוקף, אני לא יכול לזהות בקלות את כל מזהי המשתמש
@stefan זה רלוונטי רק אם ספירת המשתמשים מהווה איום.בהרבה תרחישים זה לא.
@vidarlo אולי זה הדמיון המוגבל שלי, אבל אני לא יכול לראות תרחישים שבהם ספירת משתמשים מבחוץ היא דבר טוב.בטח, באופן פנימי יש לך db עם כל המשתמשים וזה עשוי להיות נחוץ לשימוש, אבל חיצונית, אני טוען שזה כמעט תמיד פגם.
לא קשור לאבטחה, אבל השתמש בפורמט ISO לחותמת הזמן (או העידן).זה יחסוך הרבה כאב ראש בהמשך.כמו כן, השתמש בספרייה טובה ומלאה כדי לתפעל את הזמן הזה (למשל מסירת הזמן של פייתון יליד היא איומה (ביור), למרבה המזל יש חץ, מטוטלת, דולוריאנית)
כדי להוסיף לתגובות קודמות, סיבה נוספת לא להשתמש במזהים מספריים היא שהמספרים ב- JS הם כפולים, ולכן אינם מדויקים לערכים גדולים.
@AskarKalykov בהתחשב בכך שאתה לא עושה מתמטיקה על תעודות זהות בתוך היישום שלך, (אני לא יודע למה היית עושה זאת), סביר מאוד כי חוסר דיוק שיעלה בפועל.יהיו לך כמעט 2 ^ 53 מזהים, וזה רק המספרים השלמים החיוביים.
@Ryan1729 לא תעשו שום מתמטיקה, אבל כמעט בוודאות תרצו להעביר תעודות זהות, ותרצו להעביר תעודות זהות.זה לא יהיה כל כך נהדר אם לקוחות יתחילו לקבל 404 או 403 לבקשות לגיטימיות רק בגלל שמפתחי backend החליטו להשתמש בקיזוז עבור מזהים ודיוק של מזהים אלה כאשר הכפלות נפלו ממספרים שלמים.
@AskarKalykov 2 ^ 53 הוא מעל 9 * quadrillion *.יהיו לך יותר ממספיק תעודות זהות מובחנות לכל דבר הגיוני.אתה פשוט לא מקצה למשתמשים מזהים כלשהם מחוץ לטווח הבטוח שלם.אז אני לא בטוח למה אתה מתכוון ב"דיוק של מזהים אלה ככפול נפל מעל מספרים שלמים ".אתה מתכוון שהזוגות מדויקים יותר מהנדרש?האם אתה מודאג מכך שבאגים הנובעים מכפילות חלקיות מופיעים איכשהו?
אם היינו מדברים על צפי דיוק בודדים אז בטוח, שיש רק כ -16 מיליון תעודות זהות מקלות על הקצאתם באופן לא ברצף, ותיאורטית אתה עלול להיגמר, אבל זה לא נושא עם כפילים באופן ספציפי.
@Ryan1729 אנא הסתכל בכינור הבא כדי להבין על מה אני מדבר: https://jsfiddle.net/4ez675uf/
אם אתה עומד לקבל json מ- backend, אפילו לא היית יודע שיש בעיה.
@AskarKalykov כפי שציינתי קודם, הנקודה בה זה מתחיל להתרחש היא אחרי 9 קדריליון.ספציפית ב -9,007,199,254,740,992.ראה https://jsfiddle.net/koe3fsh1/ אז, פשוט לעולם אל תקצה למשתמש מזהה שאינו בין 0 ל 9007199254740991, ותוכל לבצע בדיקה פשוטה בצד השרת כדי לבדוק אם המזהה נמצא בטווח זה ולדחותכל דבר שמחוץ לו.(וודא שאתה מטפל נכון ב- NaNs.) אז אתה יכול להוריד כל חלק חלקי ולהשתמש בו כמזהה, מכיוון שמזהה משתמש לא אמור להיות מפתח גישה.
הצעות מחיר בודדות אינן JSON.הם מקובלים על ידי מנתחים רבים, אך זה לא חלק מהתקן.שדות תאריך / שעה (אם הם מתייחסים לאותה ישות), צריכים להיות בפורמט ISO8601 (yy-MM-ddThh: mm: ss.fffZ) כלומר קל ליצור / לנתח עם ספריות סטנדרטיות.