דף עזר ל-XSS: מדריך מעשי למהנדסי אבטחה קשוחים

מדוע דף צ'יט של xss עדיין חשוב

מסגרות מודרניות ≠ נקיות מ-XSS. הבריחה האוטומטית ב-React/Angular/Svelte מפחיתה את החורים בתבניות, אך מערכות אמיתיות עדיין כוללות שימוש לא נכון ב-DOM API, ווידג'טים לא בטוחים של צד שלישי, Markdown/WYSIWYG מתירני, javascript: מטפלי URL, SVG/MathML, שרידי JSONP ואמון מרומז ב- מיקום/חשיש/postMessage.

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

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

מטריצת שטח התקפה × הקשר

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

דוגמאות מינימליות ניתנות לשחזור (MRE) שניתן להריץ בפועל

1) הקשר תכונה + מפעיל ללא אינטראקציה

<input autofocus onfocus="fetch('/beacon?xss=1')">

מדוע זה חשוב: אירועי מיקוד מופעלים באופן אוטומטי בעת הטעינה בזרמי UX רבים (שדות חיפוש, הנחיות מהירות). החלף ב- <svg onload=…> או <img onerror="…"> כדי לבדוק סמנטיקה שונה של טריגרים.

2) נשא SVG + מוזרויות בטיפול ב-URL

<svg><a xlink:href="javascript:fetch('/beacon?svg')">x</a></svg>

מדוע זה חשוב: SVG הוא מרחב שמות XML נפרד עם ניתוח תכונות מוזר מבחינה היסטורית. צוותים לעתים קרובות שוכחים לנקות SVG או לאפשר אותו באמצעות מעבדי Markdown.

3) XSS מבוסס DOM (מקור → שושלת קליטה)

<script>
  const q = new URL(location).hash.slice(1);
  document.getElementById('out').innerHTML = q; // sink
</script>
<div id="out"></div>

מדוע זה חשוב: הדפוס הקלאסי של "קריאה מ-URL, כתיבה ל-DOM". הוא נמצא בכל מקום באתרים ישנים ובכלים פנימיים. ניתן לתקן זאת באמצעות קידוד נכון בהקשר ולעולם אל תכתוב ישירות ל-HTML sinks.

קו הגנה בסיסי (הנדסה בראש ובראשונה, לא סיסמאות)

1. קידוד פלט לפי הקשר. קידוד עבור HTML / תכונה / URL / JS בהתאמה. בריחה אוטומטית של מסגרת אינה מכסה DOM מגולגל ביד עדכונים.
2. ניקוי רשימת ההיתרים עבור HTML של המשתמש. כאשר הלוגיקה העסקית דורשת תוכן עשיר (הערות, ביוגרפיות, מאגרי ידע), השתמש ב- DOMPurify (או שווה ערך) עם תצורות קשיחות; הימנע מ"חיתוך מילים" ברשימה השחורה.
3. מדיניות אבטחת תוכן. התחל עם script-src 'self' + חסום מוטמע כברירת מחדל; הגדר object-src 'none' ו בסיס-URI 'אין'. לאמץ סוגי אמינות ב-Chromium כדי לאכוף ממשקי API DOM בטוחים בזמן קומפילציה/ריצה.
4. ביקורת API מסוכנת. איסור או שער eval/new פונקציה/setTimeout(מחרוזת) והמרת JSON→קוד דינמית. אכוף באמצעות כללי ESLint במהלך הבנייה והפסק את CI כאשר מתגלות הפרות.
5. בדוק ואימת כקוד. אוטומציה של השמעת נתונים. צמד עם דיווח על הפרת CSP ו קורלציה בין שער/יומן להפריד בין "חלונות קופצים הניתנים להדגמה" לבין ניתן לניצול נתיבים החשובים לעסק.

מגיליון צ'יט לפייפליין: אוטומציה שמניבה תוצאות

הדרך הקצרה ביותר מ"ספריית וקטורים" ל"הבטחת איכות ברמת ייצור" היא לולאה בת חמישה שלבים:

1. גילוי הקשר. סריקות סטטיות (כללי ESLint, grep סמנטי) + בדיקות בזמן ריצה המתויגות כמקורות פוטנציאליים לבזבוז משאבים (innerHTML, קובעי תכונות, נקודות ניווט).
2. תזמון וקטורי. מפה כל כיור/הקשר ל- בריכה מאורגנת של מטענים (אירועי תכונות, תגיות, מטפלי URL), סינון לפי דפדפן ודגלי תכונות.
3. הגהה ללא כותרת. מחזאי/Chromium פועל לפי וקטור. לכידת קונסולה, רשת, הפרות CSP, ומוטציות DOM.
4. קורלציה בין אותות. חבר ממצאים חסרי ראש עם שער API ו יומני אפליקציה לסווג "רעש לעומת אמיתי". זה מבטל את התוצאות החיוביות השגויות מהיום הראשון.
5. דיווח המבוסס על ראיות. צרף אוטומטית צילומי מסך, עקבות HTTP, DOM לפני/אחרי הבדלים והפרות מדיניות — ואז ציון ביטחון כך שהמהנדסים ידעו מאיפה להתחיל.

נגן Minimal Playwright (קטע קוד מובנה)

import { chromium } מ- 'playwright'; const vectors = [ '#\"&gt;<img src="x" onerror="fetch(\">',
  '#<svg onload="fetch(\">' ]; (async () =&gt; { const browser = await chromium.launch(); const page = await browser.newPage(); page.on('console', m =&gt; console.log('console:', m.text())); page.on('pageerror', e =&gt; console.error('pageerror:', e));
  for (const v of vectors) { await page.goto('https://target.example/' + v); await page.screenshot({ path: `evidence_${encodeURIComponent(v)}.png` }); } await browser.close(); })();

הפוך את זה למוצר: הוסף תוויות מקור→יעד לכל ריצה, הפעל דו"ח CSP בלבד לאסוף הפרות, ולאחסן הבדלים ב-DOM להפוך את הרגרסיות לברורות ב-PRs.

מציאות מסגרתית שעליכם לתכנן עבורה

• React/JSX. בריחה אוטומטית עוזרת, אבל dangerouslySetInnerHTML וגולמי ref.current.innerHTML = … פתח מחדש את הכיור. התייחס אליהם כאל ריחות קוד; הגן עליהם באמצעות מחטא ומדיניות Trusted Types.
• זוויתי. החיטוי סביר, אבל עקוף אבטחת HTML מהימן ו-API דומים יכולים ליצור פרצות; תיעדו כל עקיפה והגבלו את השימוש למקורות מאושרים.
• Next/Nuxt/SSR. דפים שנוצרו על ידי השרת חייבים להציג רק מקודד תוכן. לעולם אל תסתמך על מסגרות לקוח כדי "לנקות" טעויות שרת.
• Markdown/MDX/WYSIWYG. התייחס אליהם כאל קליטת HTML בעיות. הקשיחו את המנדר שלכם, הכניסו ווידג'טים לא מהימנים לסביבת בדיקה, ונקו תכונות אירוע/מטפלי URL.
• SVG/MathML. אם אתה חייב לאפשר זאת, הגבל את מערך התכונות והפעל תוכנה לניקוי שמבינה מרחבי שמות XML. אם זה לא קריטי, המר ל- רסטר בטוח בשרת.

משפחות מטען שימושיות שתזדקקו להן בפועל

• הפעלה אוטומטית בעת אירוע: פוקוס אוטומטי, onload, onerror, בהפעלת האנימציה, onfocus, onpointerenter. מצוין להוכחת ניצול ללא לחיצות של המשתמש.
• מטפלי URL: javascript:, נתונים:, ולעיתים vbscript: (מורשת). אכוף רשימות היתר.
• התנגשויות תבניות: טריקים של פיצול/חיבור שמתחמקים ממסננים נאיביים (למשל, יציאה מהקשר התכונות ואז כניסה מחדש ל-HTML).
• DOM clobbering: החלף מזהים/שמות כדי להפנות נתיבי קוד ולהנחית כיור.
• תזמון תצפית מוטציות: טריגרים המנצלים עדכונים דינמיים במקום טעינה ראשונית.

CSP וסוגי אמון: מ"נחמד שיש" למגן

• CSP מספק לך שפת מדיניות להגבלת מקורות סקריפט וביצוע מוטמע. התחל בקפדנות, ואז הרחב רק במקרים שנבדקו. שלב עם דו"ח-URI/לדווח ל וקציר דיווחים על הפרות בטלמטריה שלך.
• סוגי אמינות לכפות על מפתחים לעבור נוצר על ידי מדיניות ערכים ל-DOM APIs, אשר אחרת היו מקבלים מחרוזות גולמיות (innerHTML, HTML חיצוני, הוסף HTML סמוך, טווח #createContextualFragment). זה מסיר קטגוריות שלמות של DOM XSS על ידי בנייה.
• טיפ להטמעה: הפעל CSP ב דו"ח בלבד לשני ספרינטים; לתקן הפרות; ואז לאכוף. להציג יחיד מדיניות סוגי אמינות בכל האפליקציה ולפרסם HTML "מבורך" רק באמצעות בוני אתרים שנבדקו.

כיצד להוכיח את יכולת הניצול למהנדסים

1. סקריפטים לשכפול: ספק שורת קוד אחת (URL או curl) וענף Playwright להפעלה חוזרת.
2. DOM diff: הצג את הצומת המדויק ששונה ואת הנתיב (#app > .profile > .bio).
3. ערימות קריאות: עבור כיורים JS, כלול עקבות ערימה מה- eval/פונקציה ווים.
4. ראיות CSP: צרף JSON של הפרה עבור הפרות של inline/script src.
5. נרטיב עסקי: "זה יכול להוציא אסימוני הפעלה מ- /חשבון באמצעות הזרקה <img> "beacon" מנצח את "alert popped" בכל פעם.

הפעלת דף העזר הזה ל-xss בתוך Penligent

אם אתה כבר משתמש ב- Penligent כפלטפורמת בדיקת חדירות אוטומטית, ניתן לאגד את האמור לעיל לתבנית אחת הניתנת להפעלה:

• תבנית משימה: "XSS Recon + Validate". הסוכן מבצע סיור (תת-דומיין/יציאה/טביעת אצבע), מתזמן וקטורים לפי הקשר שזוהה, מבצע השמעה חוזרת ללא ממשק משתמש, ו קורלציה בין אותות עם יומנים/שערים כדי להפחית רעש.
• ייצוא מבוסס ראיות. ממצאים נשלחים עם ציוני ביטחון, שלבים ניתנים לשחזור, צילומי מסך, יומני הפרות CSP והבדלים ב-DOM שהמהנדסים שלכם יכולים לסמוך עליהם.
• במקום שבו זה עוזר ביותר. סקופים גדולים עם ערימות מורשת מעורבות + SPA, או צוותים שעוברים ל-CSP/Trusted Types וזקוקים מיון מבוסס הוכחות במקום טריוויה על מטען.

מלכודות נפוצות שממשיכות להקשות על צוותים מנוסים

• חיטוי הקלט, לא הפלט. אם אתה חייב לקבל HTML, נקה אותו ו עדיין מקודד בפלט בהתבסס על הקשר היעד; השניים אינם ניתנים להחלפה.
• מתיר javascript: ל"גמישות". השמד אותו לחלוטין; הוסף לרשימת ההיתרים רק פרוטוקולים ספציפיים (https, mailto, אולי טל).
• טיפול ב-Markdown כ"טקסט בטוח". זהו רנדרר — התוספים שלו קובעים את רמת האבטחה. בדקו תגיות/תכונות מותרות; שקלו רסטריזציה בצד השרת עבור SVG שאינו אמין.
• התעלמות מהקשרים שאינם HTML. שרשור כתובות URL ו-JSON→JS evals הם עבריינים חוזרים. יש לחזק את המדיניות של "אין המרת מחרוזות לקוד".
• אמון בסביבה אחת. XSS שנכשל ב-headless עשוי עדיין להצליח ב-Chromium לנייד או בגרסאות שולחן עבודה ישנות יותר. שמור על מטריצת דפדפנים עבור אפליקציות בעלות ערך גבוה.

רשימת בדיקה לייצור, הצמיד אותה ליד תג ה-CI שלך

• מודע להקשר קידוד כלי עזר עם בדיקות יחידה עבור HTML/Attr/URL/JS
• DOMPurify (או שווה ערך) נעול לתצורה מחוזקת עבור נתיבי תוכן עשיר
• CSP עם script-src 'self' (ללא unsafe-inline), object-src 'none', בסיס-URI 'אין'; איסוף הפרות המחובר לטלמטריה
• סוגי אמינות מדיניות + כללי lint בזמן הבנייה לחסימת מקורות מחרוזות גולמיות
• כללי ESLint האוסרים eval/new פונקציה/setTimeout(מחרוזת) (אכיפה על ידי CI)
• מחזאי חדר השמעה מוטמע עם וקטורים בסגנון PortSwigger; צילומי מסך לכל וקטור + הבדלים ב-DOM
• אוטומטי קורלציה בין אותות עם יומני אפליקציות / אירועי שער API
• דוחות מבוססי ראיות עם ציוני ביטחון והערות על השפעה עסקית
• שורות תבנית יחסי ציבור: "מציג כיורים HTML חדשים?" "עוקף את מטהר?" "מדיניות TT עודכנה?"
• בדיקה קבועה של הגדרות יישומונים/WYSIWYG/Markdown של צד שלישי

שאלות נפוצות

ש: אם אנחנו כבר משתמשים ב-React/Angular, האם אנחנו עדיין זקוקים לזה?
ת: כן. מסגרות אינן מפקחות על כל כתיבות DOM, יישומונים של צד שלישי או Markdown/SVG. אתה עדיין זקוק למנקה + CSP + TT, ועליך להימנע מכתיבת נתונים לא אמינים למאגרי DOM גולמיים.

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

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

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

קריאה נוספת (סמכותית)

• PortSwigger — דף עזר בנושא Cross-Site Scripting (XSS) — קטלוג חי של וקטורים, PoCs והערות דפדפן.
• OWASP — דף עזר למניעת XSS — אסטרטגיות קידוד קפדניות ומותאמות להקשר, וטבלאות "עשה/אל תעשה".
• OWASP — דף עזר למניעת XSS מבוסס DOM — דפוסי מקור→יעד והפחתות בדפדפן.
• PortSwigger — מהו XSS? — הדרכה מובנית ומעבדות מעשיות להכשרת עובדים חדשים.

נספח: התייחסות מהירה לתברואה וקידוד

• צמתים טקסט HTML → בריחה & " ' /
• ערכי תכונות → קידוד תכונת HTML + איסור תכונות אירוע מנתונים לא מהימנים
• כתובות URL → רכיבי קידוד; פרוטוקולי רשימת התרים; לעולם אל תכתוב גולמי javascript: / נתונים:
• מחרוזות JS → לסדר בסדר סדרתי בבטחה; לעולם אל תעביר נתוני משתמש ל-API המפרשים קוד

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