Ivan T.
2018-01-24 18:02:17 UTC
גיליתי משהו שאני מחשיב כפגיעות עיקרית במוצר SaaS הכולל את שם המשתמש והסיסמה במחרוזת השאילתות של כתובת ה- URL ברישום וכל ניסיון התחברות.
התמיכה הטכנית של השירות אמרה אותי הם מחשיבים את הפגיעות כלא משמעותית, כדרך היחידה לנצל אותה היא לקבל גישה להיסטוריית הדפדפן של המשתמש.
האם הם צדקו בהחלטתם? אני חדש למדי באבטחת מידע, אבל זה עדיין נשמע כמו עצלות מצידם.
דילגתי על שאלה זו, אך לאחר שקראתי את התשובה המצוינת ביותר אני כעת מודאגים עוד יותר מכך שמתעלמים מכך, מכיוון שהנתונים נשלחים באמצעות GET והפרטים מופיעים בטקסט רגיל.
ראוי לציון: אסימוני אימות זמניים שפג תוקפם לאחר השימוש ו / או חלון זמן קצר הם בסדר בכתובות אתרים
אולי כדאי לציין שבקשת GET היא כמעט בוודאות שיטת ה- HTTP הלא נכונה לסוג הבקשה שמתבצעת.הפרמטרים בכתובת ה- URL הם שהופכים את זה לטריוויאלי עבור האישורים לדלוף דרך;היסטוריות דפדפן, שיתוף קישורים וכו '. באמת שהבקשה צריכה להיות POST עם האישורים בגוף הבקשה - ובכך למנוע דליפות אישורים טריוויאליות כאלה.
עליכם לסמוך רק על שירותים שמשתמשים תמיד ב- HTTPS לצורך אימות ומעבירים את האישורים בשיטת POST.לשם כך נדרש אישור תקף ומהימן (סמל נעילה ירוק בשורת הכתובת).
אסימוני אבטחה (הם מחרוזות ייחודיות ולא אישורים) התקפים לאימות יחיד יכולים להופיע בכתובת ה- URL מבלי להוות סיכון לאבטחה.
השימוש ב- GET לאימות אינו מקצועי: ניתן לרשום אישורים ביומנים, היסטוריה, תוכנות צד ג '(חבילות אבטחה / תוכנות זדוניות / ...) ותוספות לדפדפן.
לעולם אל תסמוך על מי שאינו מתייחס ברצינות לביטחונך.
מ- POV להנדסה חברתית, כל מי שיודע באילו אתרים אתה מבקר, יידע לאילו אתרים למקד וכך באמת יכול להתחיל לפרופיל אותך כאדם פרטי.ראיתי מספר מקרים בהם תוקפים כחלק משלב ספירתם והזיהוי שלהם יביאו אותך ללחוץ על קישור כחלק, וכל מה שהוא עושה זה מעביר את היסטוריית הדפדפן שלך לתוקף.