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

תקציר

תסריטי צולבות אתרים (XSS) נותרים אחת מנקודות התורפה הנפוצות והמסוכנות ביותר באינטרנט. מסגרות front-end מודרניות, SPAs (יישומים של עמוד בודד) ומערכות אקולוגיות עשירות של תסריטי צד שלישי מרחיבות הן את ההזדמנויות והן את המורכבות. מאמר זה משלב את דף העזר למניעת XSS של OWASP עם מחקרים אקדמיים ותעשייתיים עדכניים, ויוצר אסטרטגיית הגנה רב-שכבתית: קידוד קונטקסטואלי, טיהור HTML, מעקב דינמי אחר זיהומים ב-DOM XSS, ניתוח דיפרנציאלי, מדיניות אבטחת תוכן (CSP) ובקרות שרשרת אספקה. בנוסף, אנו מציעים עיצוב ל- "סריקת XSS" בלחיצה אחת תכונה בתוך Penligent, עם צינורות אוטומטיים, תבניות סריקה לשימוש חוזר, מכשור זמן ריצה ויצירת דוחות. מסמך זה מתאים לשילוב ישיר במסמכי הנדסה או בתיעוד מוצרים.

מוטיבציה

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

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

מטרות המדריך:

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

יסודות: קידוד קונטקסטואלי ומאגרים בטוחים

עיקרון מרכזי במניעת XSS הוא: לעולם אל תאפשר לנתונים גולמיים ולא מהימנים להגיע להקשר ביצועי. ללא קידוד או טיהור נאותים. הקידוד חייב להיות מתאים להקשר (גוף HTML, תכונה, ליטרל JavaScript, CSS או URL). זהו תמציתו של דף העזר למניעת XSS של OWASP. (cheatsheetseries.owasp.org)

כללי קידוד פלט קונטקסטואלי

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

כיורים בטוחים והימנעות מ-API מסוכנים

גם עם קידוד נכון, ממשקי API מסוימים הם מסוכנים מטבעם. דוגמאות למקורות מסוכנים כוללות:

• innerHTML, HTML חיצוני
• document.write, document.writeln
• eval(), פונקציה() קונסטרוקטור
• מטפלי אירועים מוטמעים (לדוגמה, onclick="…" עם תוכן דינמי)

העדיפו חלופות בטוחות:

• .textContent או .innerText להכנסת טקסט
• element.setAttribute() (לשמות תכונות מבוקרים)
• שיטות DOM (לדוגמה appendChild, createElement) ללא שרשור מחרוזות

טיהור HTML כאשר נדרש HTML עשיר

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

1. רשימת הלבנים תגיות, תכונות ודפוסי ערכי תכונות מותרים.
2. השתמש בספריות בוגרות (למשל DOMPurify) במקום בביטויים רגולריים מותאמים אישית, שהם שבירים.
3. שימו לב התקפות הפרש ניתוח: התנהגות הניתוח של המנקה עשויה להיות שונה מזו של מנתח ה-HTML של הדפדפן, מה שעלול להוביל לעקיפות.

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

איתור XSS מבוסס DOM באמצעות מעקב אחר זיהום בזמן ריצה

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

• TT-XSS (מאת R. Wang et al.) הוא יישום קלאסי של זיהוי DOM XSS דינמי מבוסס זיהום. (מדע ישיר)
• מדברים על הדור שלי משתמש בניתוח זרימת נתונים דינמי כדי ליצור ניצול DOM XSS ממוקד. (ResearchGate)
• TrustyMon (2025) מציג מערכת ניטור זמן ריצה מעשית שיכולה לזהות XSS מבוסס DOM באפליקציות אמיתיות ברמת דיוק גבוהה ובשיעור נמוך של תוצאות חיוביות כוזבות. (ספריית ACM הדיגיטלית)

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

אזהרה אחת: מעקב בזמן ריצה כרוך בעלות ביצועים. ישנם עבודות המשלבות ML/DNN כמסנן מקדים כדי להפחית את העומס של מעקב אחר זיהומים. לדוגמה, Melicher et al. מציעים להשתמש בלמידה עמוקה כדי לסווג מראש פונקציות שעלולות להיות פגיעות ולהחיל מעקב אחר זיהומים רק בהן. (contrib.andrew.cmu.edu)

דוגמה א' — קבוע (השתמש בכיור בטוח) תוכן הטקסט)

<html>
  <head><title>ברוכים הבאים</title></head>
  <body>
    <h1>שלום!</h1>
    <div id="greeting"></div>
    <script>
      function getQueryParam(name) {
        return new URLSearchParams(window.location.search).get(name);
      }
      var raw = getQueryParam("name") || "";
      // Use textContent to insert as plain text (safe)
      document.getElementById("greeting").textContent = raw;
    </script>
    <p>ברוכים הבאים לאתר שלנו.</p>
  </body>
</html>

מדוע זה בטוח: תוכן הטקסט כותב טקסט רגיל; גם אם גולמי מכיל <script>…</script>, הוא יוצג כטקסט ולא יבוצע. כמו כן, באמצעות URLSearchParams נמנע מניתוח שברירי של אינדקס/תת-מחרוזת. portswigger.net

דוגמה ב' — טיפול ב-attribute sink וב-safe URL (href pseudo-sink)

דפוס פגיע:

// פגיע: var params = new URLSearchParams(window.location.search); var target = params.get("url"); // בשליטת המשתמש document.getElementById("mylink").href = target;

אם יעד הוא קוד JavaScript, לחיצה על הקישור מפעילה את JS.

תבנית בטוחה (אימות תוכנית):

function safeHref(input) {
  try {
    var u = new URL(input, window.location.origin);
    if (u.protocol === "http:" || u.protocol === "https:") {
      return u.toString();
    }
  } catch(e) { /* invalid URL */ }
  return "#";
}
document.getElementById("mylink").href = safeHref(params.get("url"));

הסבר: URL חדש() מתייצב; אנו מאפשרים רק http:/https: תכניות. זה חוסם javascript:/נתונים: תכניות. portswigger.net

מדיניות אבטחת תוכן (CSP): הגנה מעמיקה

בעוד קידוד וטיהור הם אמצעי ההגנה העיקריים, CSP מספק מחסום משני חזק. CSP המוגדר היטב המשתמש ב-nonces או ב-hashes, יחד עם דינמי קפדני והסרת 'unsafe-inline', יכול להגביל מאוד את ניצול XSS.

עם זאת, קיימים גם חסרונות:

• שימוש חוזר ב-Nonce: אתרים מסוימים משתמשים באותו nonce במספר תגובות, מה שמערער את ההגנה של CSP. מחקר שנערך לאחרונה, "The Nonce-nce of Web Security" (ה-nonce-nce של אבטחת האינטרנט), מראה כי אתרים רבים בעולם האמיתי נוהגים כך. (arXiv)
• מורכבות הפריסה: תמיכה בסקריפטים מוטמעים ישנים, ספריות צד שלישי וחוסר עקביות בדפדפנים מובילה לעיתים קרובות להקלה במדיניות.

לפיכך, CSP צריך להוות השלמה, ולא תחליף, לקידוד ולטיהור.

שיטות עבודה מומלצות בהנדסה: CI, Lint, בדיקות, ניטור

כדי להפעיל הגנות XSS חזקות:

• ESLint / בודקי קוד: איסור או סימון שימוש ב-sinks אסורים (innerHTML, eval), דרישה להערות הקשר בביטויי תבנית.
• ניתוח סטטי ודינמי ב-CI:
  • ניתוח סטטי של זיהום קבצים מרובים עבור מודולי JS
  • בדיקות Fuzz או בדיקות ניתוח דיפרנציאלי
  • מדידת ביצועים בסביבות ביניים
• בדיקות יחידה/אבטחה: יצירת מטענים מבוססי הקשר בבדיקות יחידה כדי להבטיח יישום קידוד נכון (כמו ב"איתור ותיקון אוטומטיים של פגיעויות XSS" או "איתור XSS באמצעות בדיקות יחידה") (arXiv)
• ניטור והתראה: לאסוף דיווחים על הפרות CSP, התראות זמן ריצה מכשירניות עבור זרימות חשודות, מדדי יומן של כשלים בקידוד.

Penligent סריקת XSS בלחיצה אחת עיצוב

להלן מפרט עיצובי מוצע שניתן לשלב במוצר של Penligent כ- סריקת XSS בלחיצה אחת "Playbook".

זרימת עבודה של משימות (ברמה גבוהה)

1. סריקה ורינדור JS – גלה את כל הדפים והמסלולים המונעים על ידי JS.
2. ניתוח סטטי – התפשטות זיהום בקוד המקור כדי לאתר מקורות ופונקציות בסיכון גבוה.
3. סריקת תבניות – השתמש בסורקים מבוססי תבניות (למשל Nuclei) כדי לשגר מטעני XSS נפוצים.
4. סריקה בזמן ריצה / סריקה דינמית – באמצעות גלישה ללא ממשק משתמש ומכשור, הזרקת מטענים וזיהוי ביצוע סקריפטים.
5. מעקב אחר זיהום בזמן ריצה – למדוד את זמן הריצה של הדף ולבדוק אם נתונים לא מהימנים מגיעים למקורות מסוכנים.
6. בדיקת פאזל דיפרנציאלית – הזן סימון מקרה קיצון למנקה + דפדפן וזיהוי סטיות.
7. ביקורת CSP ו-SRI – לבדוק כותרות, תגי סקריפט, לבדוק אם נעשה שימוש חוזר ב-nonce, תכונות שלמות חסרות.
8. הפקת דוחות – לאסוף נקודות תורפה עם PoC, דירוג סיכונים, הצעות לתיקון, ובאופן אופציונלי ליצור תיקוני PR.

תבנית גרעין לדוגמה (XSS מוחזר)

id: xss-reflect-basic info: name: Reflected XSS Basic author: penligent-scan severity: high requests: - method: GET
    path: - "{{BaseURL}}?q={{payload}}" payloads: payload: - "" matchers: - type: word part: body words: - ""

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

הגדרת משימה לדוגמה (JSON)

{ "name": "XSS QuickScan", "steps": [ {"id": "crawl", "type": "crawler", "params": {"start_url": "{{target}}", "render_js": true}},
    {"id": "static", "type": "static_analysis", "deps": ["crawl"], "params": {"analyzers": ["multi-file-taint"]}},
    {"id": "template_scan", "type": "scanner", "deps": ["crawl"], "params": {"templates": ["xss-reflect-basic"]}},
    {"id": "dynamic", "type": "dynamic_scan", "deps": ["template_scan", "static"], "params": {"engine": "headless-instrumented"}},
    {"id": "dom_taint", "type": "runtime_taint", "deps": ["dynamic"], "params": {"agent": "instrumented-browser"}},
    {"id": "parsing_diff", "type": "parsing_diff", "deps": ["dynamic"], "params": {}}, {"id": "audit_csp", "type": "csp_audit", "deps": ["crawl"], "params": {}}, {"id": "report", "type": "report_gen", "deps": ["dom_taint", "parsing_diff", "audit_csp"], "params": {"format": "pdf,html"}}
  ] }

דוח ותפוקה

כל ממצא כולל:

• סוג (משתקף / מאוחסן / DOM)
• הוכחת היתכנות (בקשת/תגובת HTTP, תמונת מצב DOM, צילום מסך)
• ציון חומרה
• תיקון הצעות (למשל, מקודד נכון, תצורת מחטא, שימוש בטוח ב-API)
• באופן אופציונלי, צור באופן אוטומטי תיקון או שלד PR

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

דוגמאות לקטעי קוד ושיטות עבודה מומלצות

להלן כמה דוגמאות לקטעי קוד בטוחים/לא בטוחים בסביבה דמוית React:

לא בטוח (פגיע)

import DOMPurify from 'dompurify'; function UserGreeting(props) { const clean = DOMPurify.sanitize(props.userContent, { ALLOWED_TAGS: ['b','i','u','a'], ALLOWED_ATTR: ['href'] }); return <div dangerouslysetinnerhtml="{{" __html: clean }} />;
}

פונקציה UserGreeting(props) { החזר <div>{props.userContent}</div>; // React יבצע בריחה אוטומטית }

// Unsafe
<img src={userInput} />

// Safer
function safeUrl(u) {
  const doc = new URL(u, window.location.origin);
  if (doc.protocol === 'http:' || doc.protocol === 'https:') {
    return doc.toString();
  }
  return '/';  // fallback
}
<img src={safeUrl(userInput)} />