תשובה טובה מאת alexwen, למרות שלדעתי התשובה שלו היא יותר בעיית חיטוי של פרמטר כללי, לא בדיוק למה ש- OWASP מתייחס. אני חושב שאולי OWASP מתייחס לכל אחד מהמושגים הבאים.

אימות מחדש של נתונים מניתוב מחדש

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

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

מעולם לא ראיתי מעולם תכנית אימות מטומטמת זו, אך נראה שזה מה ש- OWASP מתייחס אליו.

תבנית לאחר הפניה-הפניה מחדש

דפוס PRG פירושו הפניה לבקשת GET לאחר עיבוד בהצלחה של POST. זה משמש כדי להימנע מבעיית השימושיות האיומה של משתמש שלוחץ על כפתור הקודם בדפדפן והדפדפן שואל את המשתמש שאלה לא ברורה אם "לפרסם מחדש נתוני טופס" או לא. (ראיתי את המסע הזה כל כך הרבה משתמשים שזה אפילו לא מצחיק.)

מעולם לא ראיתי שזה משמש בצורה פגיעה להתקפה, אלא בתיאוריה תוכנית אימות גרועה. עשוי להשתמש ב- PRG לעיבוד אישורי אימות, ואז להפנות לדף "חברים בלבד" או למשהו טיפשי שכזה. שוב, אף פעם לא ראיתי את זה באופן טבעי בטבע, אז אני לא בטוח ב 100% שגם על זה מדבר OWASP.

הפניה עיוורת

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

  http://my.badsite.com/redirect.php?destination= http://google.com  

אם redirect.php מפנה ללא תנאי לכל כתובת URL שתועבר (למשל ב- PHP, כותרת ("מיקום: $ מיקום")), אז התוקף יכול לבנות URL שנראה בטוח אך מוביל למעשה לאתר מסוכן. לדוגמא, אם סקריפט ההפניה העיוור נמצא בכתובת http://nytimes.com/redirect.php, אז התוקף שולח לקורבן קישור כמו http://nytimes.com/redirect .php? destination = http: //spyware.malware.xxx/get_pwned ומשתמש נאיבי מסתכל על הקישור וחושב שהוא נכנס לאתר NYT. (תלוי באופי המדויק של הסקריפט, התוקף יוכל לקודד כתובת URL או חלק מכתובת אתר היעד כדי לטשטש אותו עוד יותר.)

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

נוהג נפוץ לאחר פרסום טופס הוא הפניית משתמש לדף הצלחה:

  POST / HTTP / my-form HTTP / 1.1Host: www.myhost.comHTTP / 1.1 302 הועבר באופן זמני מיקום: https://www.myhost.com/form-success.html?message=%3Cb%3ESuccess!%3C/b%3E

בדוגמה זו המשתמש מנותב לטופס -success.html דף, עם ההודעה של:

  <b>Success! < / b> 

יש לנו javascript על טופס-success.html שלוקח את ההודעה ומצרף אותו למסמך. מבלי לנקות את התגובה, אתה פותח את עצמך להתקפה של XSS.

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

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