עד כמה עלי לנסות למנוע ממשתמש XSSing את עצמו?

Rory McCune

2019-04-02 01:28:29 UTC

view on stackexchange narkive permalink

זהו למעשה מושג אמיתי, "Self XSS" שנפוץ מספיק שאם אתה פותח את https://facebook.com ואז פותח את כלי המפתח, הם מזהירים אותך לגבי זה

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

אני מאמין שאפליקציית Discord (תוכנית, לא גרסת הדפדפן) כוללת את אותו סוג של הודעה אם אתה פותח את המסוף באמצעות קיצור הדרך 'Ctrl` + `Shift` +` I`.

ראוי לציין שמדובר בנושא הנדסה חברתית שעדיין היה קיים גם אם ה- OP יתקן את כל הפגיעות באתר שלהם.המשתמש מבצע קוד במסוף.למעשה, IMO "XSS עצמי" הוא שם שגוי.אולי עלינו לקרוא לזה "הונאת JavaScript" או משהו כזה.

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

האם אני היחיד שמוטרד מכך שלפייסבוק יש גישה למסוף הבאגים והראתה נכונות להשתמש בו, אפילו למטרה שפירה לכאורה?

@MasonWheeler מדוע אתה מוטרד מהדבר הספציפי הזה?

@Sumurai8 באופן כללי, מכיוון שכלי המפתחים אמורים להיות קדושים.זהו אחד מקווי ההגנה החשובים ביותר של המשתמש מפני תוכן מזיק או זדוני, ועליו להישאר לגמרי מחוץ לארגז החול אליו יש גישה לדף האינטרנט עצמו.במקרה הספציפי הזה, * כי זה פייסבוק, * ויש להם היסטוריה ארוכה של התנהגות זדונית ופועלים נגד האינטרסים של המשתמשים שלהם.

@MasonWheeler כל JS מכל אתר יכול להעביר למסוף ניפוי הבאגים עם 'console.log' וזה פונקציות של אחות - הם לא ממש יכולים לתפעל את devtools בשום צורה שהיא

@Alex אה, אם זה רק יומן קונסולות עדיף.טוב לשמוע שהם לא ממש יכולים להיכנס אל מכשירי ההתפתחות עצמם.

זה לא ימנע מהתוקף להשתמש בסימניות

@MasonWheeler למרות שהיית קצת מחוץ לבסיס עם ההנחות שלך לגבי רישום פשוט של קונסולות, הדאגה שלך לגבי התעסקות בפייסבוק עם כלי מפתח יותר ממה שהם צריכים זה די סביר. ראה שאלה זו לגבי פייסבוק באמצעות באג של Chrome כדי להשבית את המסוף, כדי להילחם בהונאות: https://stackoverflow.com/questions/21692646/how-does-facebook-disable-the-browsers-integrated-developer-tools

@FelipeWarrener-Iglesias וואו.הם באמת עשו זאת בשלב מסוים.כן, זה פישל ברצינות.

תכונה זו ממש (טקסט אזהרה לקונסולה) הייתה גורם לפתח אבטחה באחת מאפליקציות הבנקאות של Android בפולין.תחת אנדרואיד אין קונסולת Chrome, ולכן הודעה זו נדחקה ל logcat, יחד עם כתובת ה- URL המקורית שהייתה הקישור SSO (כניסה יחידה).באנדרואיד 4.x אפליקציות קודמות יכולות ליירט את כתובת ה- URL הזו, שהייתה נוטה למצב גזע ולמעשה ניתנת לניצול.אז היו זהירים.עוד על כך: https://usmile.at/symposium/2017/program/zielinski

meowcat

2019-04-02 01:51:56 UTC

view on stackexchange narkive permalink

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

  <html> <head><title>HI< / title>< / head> <body> <h1>WEBSITE< / h1> היי שמי <travis>. < / body>< / html>

שים לב שכאשר אתר זה מוצג, המילה ' travis ' אינה מוצגת.

זה הנושא האמיתי

שניהם נושאים אמיתיים.

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

מסכן קטן [שולחנות בובי] (https://www.xkcd.com/327/)

@SeldomNeedy אני מסכים איתך ב 100%, התכוונתי לומר ש * התנהגות בלתי צפויה * הייתה קשה / בלתי אפשרית עבור אנשים שאינם יודעים קרוא וכתוב לפתור / להבין מדוע היישום המשיך לקרוס עליהם.עדכנתי את התשובה כדי לשקף זאת.

@WayneWerner חחח כן, הקבלנים הנימוקים לא לתקן את הבעיה נובעים מכך שרק אנשים מהימנים יכולים להשתמש ביישום, והיו להם יומנים מי עשה מה במערכת, כך שתדעו מי SQL הזריק להם ... למרות היומנים היכןמאוחסן במסד הנתונים ... * אנחה *.

@meowcat המתן ... נכנס למסד הנתונים כדי שיידעו מי SQL הזריק להם?!?!meowcat: נקודה קשורה, טקסט בסוגריים זוויתיים לא מופיע אפילו בפוסטים של SE ...

reed

2019-04-02 15:44:32 UTC

view on stackexchange narkive permalink

אם הדרך היחידה להכניס קוד זדוני היא להקליד אותו ממש בדף האינטרנט שלך, אז וקטור ההתקפה יהיה "self xss", שהוזכר בתשובה אחרת, וזה מתקפה הנדסית חברתית שאתה לא באמת יכול למנוע.

אך אם ניתן לטעון קוד זדוני גם בדרכים אחרות בדף שלך, יש לך בעיה גדולה יותר. לדוגמא, אם האתר שלך פגיע ל- XSS או CSRF המשתקף, תוקף יכול להשתמש בכאלה כדי לגרום למשתמש לטעון קוד זדוני.

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

  https://www.example.com/search?data=<script src = ".. . ">< / script>

דוגמה ל- CSRF: אם הנתונים שהוגשו מודפסים על הדף מבלי לטהר אותם ואין גם שום הגנה מפני CSRF, תוקף יכול לגרום לקורבן לפרסם נתונים זדוניים. .

  <form method = "post" action = "submit" > <input type = "text" name = "title" > <input type = "text" name = "note" > <input type = " הגש "value =" שלח "> <! - אין שום סימן למניעת CSRF כאן !!! -->< / form>

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

Anders

2019-04-02 16:59:48 UTC

view on stackexchange narkive permalink

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

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

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

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

zero298

2019-04-02 16:44:08 UTC

view on stackexchange narkive permalink

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

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

dotancohen

2019-04-02 19:04:49 UTC

view on stackexchange narkive permalink

לאפשר לכאורה להתקפות "XSS עצמי" עשויות להיות השלכות משניות.

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

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

  ניתן ליצור טקסט מודגש על ידי הקפתו בתגים הבאים: <b> שלום, עולם מודגש! < / b>

אם היישום שלך מאפשר התקפות "XSS עצמי", המשתמש יתקשה להוסיף הערה כזו.

shellster

2019-04-03 22:20:29 UTC

view on stackexchange narkive permalink

משהו שלא מוזכר בתשובות אחרות, הוא בעיות האבטחה המשניות הפוטנציאליות שיכולות לנבוע מ- XSS עצמי.

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

במקרה של CSRF, פעולה בלתי מזיקה יחסית עשויה להפוך להתקפה חזקה על ידי שימוש ב- CSRF כדי לגרום ל- XSS עצמי מאוחסן ואז נותן לתוקף גישה לעוגיות המשתמש או להפעלת הדפדפן. למעשה השתמשתי בטכניקת שרשרת התקפה זו מספר פעמים כאשר הדגמתי פגיעות בפני מפתחים.

taswyn

2019-04-05 00:50:31 UTC

view on stackexchange narkive permalink

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

להיות, בעצם, שאם אנשים יכולים להטעות להפיל קוד XSS עצמי. למסוף ה- dev, מדוע שתצפה שלא יטעה אותם ליפול למרכיב קלט כלשהו בממשק המשתמש שלך?

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

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

שיטות פיתוח: השלכות של התרת XSS עצמי

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

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

אם אין לך קידוד של היישום שלך באופן ששיטת הפלט המוגדרת כברירת מחדל מונעת XSS (ויעדי פלט שונים כגון תכונות לעומת אלמנטים דורשים מתודולוגיות שונות עבור מה שיש ואינו 'לא מותר, ומכאן' ברירת מחדל '), וזה דורש יותר מאמץ (לא פחות) כדי למקד את הפלט כדי לאפשר (בתקווה שמופיע ברשימה הלבנה, "מטוהרת") לעבור כ- HTML / וכו' מקורי ...

כמה בטוחים שאתה לא הולך לעבור תאונה שבה השתקפות מסוימת של המשתמש da ta חזרה לאינטרנט לא מאפשר XSS מחוץ ל רק "נתונים שהמשתמש יכול לעצמם להציג"?

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

מתן אפשרות ל- XSS לפוטנציאל התרחשות על סמך קלט משתמש צריכה לדרוש פעולה חיובית, בחירה מפורשת של היזם ביחס לכל מקום זה עשוי להתרחש, ולא פשוט התוצאה הבסיסית, ברירת המחדל של משיכת נתוני המשתמש המאוחסנים ומשקף אותם בחזרה החוצה. אם הקוד שלך לא נכתב כך, כאשר הוא מונע XSS כברירת מחדל ודורש פרמטר עקיפה כלשהו כדי להשבית את טיהור הפלט הזה, אז זה סימן שאתה צריך להעריך מחדש את התהליך שלך.

n0idea

2019-04-04 13:48:15 UTC

view on stackexchange narkive permalink

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

יתר על כן, בהתחשב בכך שניתן למנוע בקלות את פגיעות ה- XSS, האם באמת כדאי שלא לדאוג לה ? רק חשוב על כל תוצאה אפשרית: כרטיסי תמיכה נפתחים, דיווחים על באגים, חוסר שביעות רצון מהמשתמשים, ..?