מהי זיהום פרמטר HTTP ומדוע היא מהווה סיכון ממשי?

כשאנחנו מדברים על אבטחת יישומי אינטרנט, אנשים רבים חושבים רק על כשלים בהזרקת SQL, XSS או אימותעם זאת, במשך שנים קיימת טכניקה שקטה למדי שעדיין לא מורגשת בביקורות רבות: זיהום או זיהום של פרמטרים של HTTP, המכונה זיהום פרמטרים של HTTP (HPP) זיהום פרמטר HTTP.

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

מושג פרמטרי HTTP וקדימות

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

בבקשת GET טיפוסית, הנתונים הללו עוברים ב- מחרוזת שאילתה (כל מה שבא אחרי הסימן ? בכתובת האתר)זוגות מפתח/ערך מופרדים באמצעות סימן אמפרסנד (&). בבקשת POST, הם יכולים להיות בגוף הבקשה, אך לוגיקת היישום בשרת בדרך כלל מתייחסת אליהם באופן דומה מאוד: מפתחות עם ערך משויך אחד או יותר.

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

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

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

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

מהו זיהום פרמטרים של HTTP (HPP)?

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

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

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

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

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

כיצד שרתים מטפלים בפרמטרים כפולים

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

בסביבות מסוימות, אם נשלח כתובת URL מהסוג משתנה1=ערך1 ומשתנה1=ערך2השרת ישמור רק את הערך הראשון (val1). באחרים, זה ייקח את הערך האחרון שהתקבל (val2). ובמקרים מסוימים, כפי שקורה עם תצורות מסוימות של IIS, שני הערכים הם לשרשר באופן פנימי לרשימה, לדוגמה מופרדים באמצעות פסיקים, שאותם האפליקציה תצטרך לפרש לאחר מכן.

דוגמה נפוצה המצוטטת היא ש אַפָּשׁ בהתנהגות ברירת המחדל שלו, הוא בדרך כלל שומר את הערך הראשון של פרמטר וזורק את הבאים, בעוד שטכנולוגיות אחרות יוצרות רשימת CSV (ערכים מופרדים בפסיקים) עם כל הערכים של הפרמטר המזוהם הזה. אם יישום ה-backend מותאם רק לאחד מהמקרים הללו, תרחישים בלתי מבוקרים עלולים לגרום להשפעות בלתי צפויות.

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

יתר על כן, ניתן להשתמש ב-HPP כדי לנצל את ה- שינויים פנימיים באופי מה שהשרת עצמו עושה. תועד, למשל, כיצד שרתים מסוימים משנים תווים ספציפיים מסוימים (כגון החלפת התו "]" ב-"_") במהלך העיבוד, דבר שניתן להשתמש בו כדי התחמקות מכללי סינון או קושחות WAF המבוססות על ביטויים רגולריים.

השלכות ותרחישי ניצול של HPP

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

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

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

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

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

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

דוגמה קלאסית של HPP ביישום הצבעה

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

האפליקציה מקבלת דרך פרמטר שנקרא מזהה_בחירות המזהה של הבחירות הנוכחיות. עם ערך זה, השרת יוצר דף המפרט את המועמדים הזמינים, לכל אחד קישור להצבעה. השיטה Request.getParameter("זוג") ב-JSP, כאשר קיימים ערכים מרובים עבור אותו פרמטר, הוא תמיד מחזיר את הערך הראשון.

בואו נדמיין כתובת URL כזו: http://servidor/eleccion.jsp?eleccion_id=4568הדף שנוצר יציג קישור להצבעה עבור כל מועמד, לדוגמה:

קישור 1אני מצביע למר ווייט
קישור 2אני מצביע לגברת גרין

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

כתובת האתר שהיא בונה יכולה להיות משהו כזה: http://servidor/eleccion.jsp?eleccion_id=4568%26candidato%3Dgreenשימו לב שהתוקף קידד את הסימן & כ-%26 ואת הסימן = כ-%3D, כך שלאחר הפענוח הם הופכים לפרמטר מועמד חדש המוטמע בתוך הערך election_id.

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

התוצאה היא שקישורים שנוצרים באופן פנימי הופכים למשהו כזה:

קישור 1אני מצביע למר ווייט
קישור 2אני מצביע לגברת גרין

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

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

עקיפת אימות: המקרה של בלוגר

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

הבקשה הבעייתית הייתה בערך כך (פישוט התחביר):

POST /add-authors.do HTTP/1.1
security_token=attackertoken&blogID=attackerblogidvalue&blogID=victimblogidvalue&authorsList=attackermail%40gmail.com&ok=Invite

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

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

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

HPP וחומת אש של יישומי אינטרנט (WAF)

ארגונים רבים מסתמכים על WAF כשכבה נוספת להגנה על יישומי האינטרנט שלהם מפני התקפות ידועות. חומות אש אלו מבוססות בדרך כלל על כללים וחתימות (ביטויים רגולריים) אשר מוחלים על הפרמטרים, הכותרות ואפילו על גוף בקשות ה-HTTP.

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

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

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

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

מקרים אמיתיים, כלים ושכיחות של HPP

מחקרים אקדמיים ועבודתם של מומחי אבטחה הראו שזיהום פרמטרים של HTTP רחוק מלהיות נדיר. פרויקטים כגון PAPAS (מערכת ניתוח זיהום פרמטר), שהונעו על ידי חוקרים כמו כרמן טוראנו, תוכננו בדיוק כדי לזהות באופן אוטומטי פגיעויות HPP ביישומי אינטרנט בקנה מידה גדול.

בניסויים שבוצעו על יותר מ 5000 אתרים פופולריים ביותר (לפי דירוגים כמו Alexa), נצפה שכמעט 30% מהאתרים שנותחו הם הכילו לפחות דף אחד פגיע ל-HPP. כלומר, היה אפשר להחדיר פרמטר מקודד לפרמטר קיים אחר ולאמת שהוא נראה מפוענח בכתובת URL או בצורה כלשהי שנוצרה.

בולט עוד יותר הוא שליד ה- 47% מהפגיעויות שנמצאו (שווה ערך לכ-14% מכלל האתרים) היו באמת ניתן לניצולהמאפשרים התקפות שחרגו מעבר לפגמי תצוגה פשוטים. בין האתרים שנפגעו היו שמות גדולים כמו מיקרוסופט או גוגלזה מבהיר שאפילו ענקיות הטכנולוגיה אינן פטורות מבעיות אלה.

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

בנוסף לפתרונות ספציפיים כמו POTATOES, ישנן הרחבות כמו מאתר HPP עבור גוגל כרוםכלים אלה נועדו לזהות וקטורי תקיפה פוטנציאליים של HPP בכתובות URL ובטפסי HTML. למרות שהם יכולים לסייע בזיהוי נקודות חשודות (לדוגמה, טפסים המשתמשים מחדש בפרמטרים ללא אימות נאות), הם אינם מהווים... לא פתרון מלא ולא תחליף לביקורת אבטחה מעמיקה.

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

HPP במנועי חיפוש פנימיים ודוגמאות כמו Apple.com

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

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

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

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

ניתוח הטכנולוגיות הבסיסיות בפורומים כמו של אפל (לדוגמה, אפאצ'י עם J2EE ב-backend) מראה שמערכות הפעלה מודרניות רבות מתנהגות באופן דומה לשרתים כמו IIS או שילובים כמו Apache עם Python בעת טיפול בפרמטרים מזוהמים, יצירת רשימות מופרדות בפסיקים והאצלת הטיפול הסופי בערכים אלה ללוגיקת האפליקציה.

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

זיהוי והפחתת זיהום פרמטרים של HTTP

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

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

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

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

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

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

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