פריצה לאתר דרך כתובת URL
uuid מסוג char(36) עם ערכים ייחודיים. המרצה מכין סקריפט שמריצים ב-SQL.npm i uuid, ובלוגיקת ה-auth מייצרים UUID בגרסה 4 ומשלבים אותו בשאילתת ההוספה. אין צורך להחזיר את ה-ID ללקוח.uuid במקום id.where uuid = '...', בתוך גרשיים, כי הערך הוא מחרוזת.uuid מה-params במקום id, ובקובץ האפליקציה הראוט של העריכה מקבל uuid.+ לפני הפרמטר ממיר אותו למספר, ולכן מסירים אותו.פרקי ההרצאה: פריצה לאתר דרך כתובת URL
תמלול ההרצאה: פריצה לאתר דרך כתובת URL
הטקסט המלא של הדקות הראשונות בהרצאה «פריצה לאתר דרך כתובת URL» בקורס הווידאו של PracticU – כתוביות בעברית עם זמן התחלה לכל פסקה. כך תוכלו לקרוא ולחפש את הנושאים לפני שמתחילים ללמוד.
אנחנו מגיעים לבעיית הסקיוריטי הבאה שקיימת פה. לצורך כך בואו נירשם בתור מושיקו1234 הכוונה לוגין ואנחנו רואים שהאתר עובד פעיל הכל בסדר אני רוצה רגע ללכת ולעדכן פרטים אז אנחנו רואים שאנחנו יכולים לעדכן את הפרטים של המשתמש שלנו לבצע update זה כמובן אמור לעבוד בלי בעיה
אבל יש פה משהו מעניין שאני מסתכל עליו על כל הדף הזה ואני רואה את בעיית הסקיוריטי שיש פה. ובעיית הסקיוריטי שקיימת פה היא בעיה שנקראת InSecureDirectObjectReferenceInSecureDirec tObjectReferenceInSecureDirectObjectRefere nce זה מצב שבו האתר שלנו חושף מידע שדרך המידע הזה אפשר לשנות אותו ולבצע דברים
אחרים או לראות דברים אחרים. אז מה בעצם אנחנו חושפים פה? מה אנחנו רואים בכל האתר הזה שמאפשר לנו לחשוף את המידע הזה שדרכו אפשר לבצע עוד דברים או לראות עוד דברים?
אז אם הצלחתם לראות, זה בעצם נמצא פה. מה זה המספר הזה שמופיע? המספר הזה זה ה-ID של היוזר. בואו ניכנס רגע לטבלת היוזרים ונראה שלמוישה ה-ID שלו זה אחד.
אם משתמש, או בטח שהאקר רואה את הדבר הזה, אז הוא אומר, אוקיי, אם אני רואה איזשהו מספר, בואו נשנה אותו לשתיים, והופה, שימו לב מה אותו האקר רואה, פרטים של מישהו אחר.
בואו נשנה את זה לשלוש ונראה פרטים של מישהו אחר. אז יש כל מיני משאבים בדאטה-בייס שלא אכפת לי שיראו את המספר שלהם, לדוגמה קודים של מוצרים, שישנו ויראו קוד של מוצר אחר, אין לי בעיה, זה לא מידע חסוי או מידע רגיש, אבל יש כל מיני סוגי נתונים שנחשבים מידע רגיש.
יוזרים זה מידע רגיש, אם היוזר משנה, הלקוח שלנו או ההאקר משנה מספר של יוזר, פתאום הוא רואה יוזרים אחרים.
תחשבו על קופת חולים נניח, שפתאום אתם רואים ב-URL או איפשהו את הקוד שלכם ואפשר לשנות אותו בלי בעיה.
ואז כמובן לראות פרטים חסויים של קופת חולים של מישהו אחר, אנחנו לא רוצים את זה. אז ברגע שהמידע הוא מידע רגיש, אנחנו לא רוצים לחשוף אותו, את ה-ID, כי אחרת זה Insecure Direct Object Reference ואנחנו רוצים להגן על זה.
מה השיטה? לא להחזיר ID מספרי, להחזיר איזושהי מחרוזת שמייצגת את הרשומה המתאימה, אבל או מחרוזת כזאת שהיא דרכה אי אפשר להגיע למחרוזות דומות אחרות.
אז אנחנו בעבר עשינו משהו עם זה, וזה נקרא UUID, Universal Unique Identifier, שזאת מחרוזת ארוכה שהמערכת מספקת לנו, וברגע שנרצה עוד מחרוזת, אנחנו לא נקבל את אותה מחרוזת בדיוק, כי זה בעצם האלגוריתם, האלגוריתם שומר על זה שכל הזמן תהיה לנו מכרוזת מאוד גדולה, ייחודית.
ואנחנו רוצים שבדאטאבייס, קודם כל נתחיל מהדאטאבייס הפעם, בנוסף ל-ID תהיה את המכרוזת המיוחדת הזאת. אנחנו לא רוצים לבטל את ה-ID, כי ה-ID המספרי הזה זה המזהה הראשי, זה המפתח הראשי, והוא כן יכול להופיע בעוד טבלאות, נניח בכישורים.
אנחנו לא רוצים שהמחרוזת הארוכה הזאת תופיע כמפתח זר. אנחנו רוצים שה-ID ישוכפל כמפתח זר, אבל בנוסף יהיה לו איזשהו UUID. אז הכנתי כאן דאטאבייס שביחד עם ה-ID, אנחנו יכולים לראות את זה כאן, זה ה-ID Auto Increment, יש לנו UUID, char 36 ויש פה כמה UUIDs מתאימים שיצרתי.
בואו ניקח את כל המחרוזת הזאת, ניגש לדאטה בייף שלנו נורת'ווינד sql נדביק go. עכשיו ליוזרים יש גם איי.די וגם את האוניברסל יוניק איידנטיפייר הזה אנחנו רק צריכים לבצע את ההתאמות הדרושות במערכת שלנו.
נתחיל עם ארת' לוג'יק כאשר אנחנו עושים רג'יסטר אז אנחנו רוצים עכשיו להכניס ליוזר גם default value עבור ה-id, המספור האוטומטי רץ, ברגע שלשום פה default זה אומר שהמערכת תייצר לנו מספור אוטומטי, כי זה מה שמוגדר בדאטה בייס, אבל הוספנו עוד מכרוזת, והמכרוזת שהוספנו זה user.uuid.
אנחנו צריכים עכשיו לעשות את ההתאמות הדרושות. עכשיו, user, כשהוא מביא לי את הנתונים, אין לו uuid, הוא לא שולח לי אותו אז כאן אני רוצה לגשת ליוזר ולהוסיף uuid אבל אני צריך את המנגנון שמייצר לי אותם אז בואו נתקין את זה npmi uuid וברגע שיש לנו אנחנו עושים
פה required למעלה בואו ניגש לפה ונבצע קונסט של uuid שווה אמריקווייר של uuid ואז אנחנו יכולים להשתמש איתו כאן. בואו נייצר uuid, יש לו כל מיני ורז'ונים, ורז'ון 4 הוא ידוע בתור ורז'ון חזק שאנחנו יכולים להשתמש איתו.
זאת המחוזת הארוכה עם ה-36 תווים. אז כרגע הכנסנו UUID למשתמש ושילבנו אותו בתוך השאילתא. עכשיו השאילתא אמורה להתאים לשאילתא שקיימת בדאטאבייס, למבנה של הדאטאבייס.
דבר נוסף שאני רואה כאן זה שהחזרנו את ה-ID, אני לא צריך להחזיר את ה-ID, אז אנחנו בעצם לא צריכים את השורה הזאת, כי אני לא מחזיר יותר ID לקליינט סייד, רק UUID.
אין לי פה צורך, גם באינפו הזה. ביי ביי. נקסט, הדבר הבא שאנחנו רוצים לבצע זה פה.