Cross-Site Scripting: Stored, Reflected ו-DOM

איך XSS נוצר

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

בתרגול, רשמו את context, encoding, CSP, stored/reflected/DOM, sanitization, השוו להתנהגות צפויה והגדירו Pivot אחד לפחות. התוצאה צריכה להיות ניתנת לבדיקה על ידי אנליסט נוסף, כולל מגבלות וצעדי המשך.

Reflected ו-Stored

הנושא 'Reflected ו-Stored' הוא חלק מרכזי בעבודה על בדיקת XSS. מומלץ לפרק אותו לשלוש שאלות: מהו הקלט, איזו החלטה רוצים לקבל, ואיזו ראיה מספיקה כדי להצדיק אותה. השאלות האלה מונעות שימוש אוטומטי בכלי ללא הבנת המטרה.

בתרגול, רשמו את context, encoding, CSP, stored/reflected/DOM, sanitization, השוו להתנהגות צפויה והגדירו Pivot אחד לפחות. התוצאה צריכה להיות ניתנת לבדיקה על ידי אנליסט נוסף, כולל מגבלות וצעדי המשך.

DOM-based XSS

הנושא 'DOM-based XSS' הוא חלק מרכזי בעבודה על בדיקת XSS. מומלץ לפרק אותו לשלוש שאלות: מהו הקלט, איזו החלטה רוצים לקבל, ואיזו ראיה מספיקה כדי להצדיק אותה. השאלות האלה מונעות שימוש אוטומטי בכלי ללא הבנת המטרה.

בתרגול, רשמו את context, encoding, CSP, stored/reflected/DOM, sanitization, השוו להתנהגות צפויה והגדירו Pivot אחד לפחות. התוצאה צריכה להיות ניתנת לבדיקה על ידי אנליסט נוסף, כולל מגבלות וצעדי המשך.

Context ו-Encoding

הנושא 'Context ו-Encoding' הוא חלק מרכזי בעבודה על בדיקת XSS. מומלץ לפרק אותו לשלוש שאלות: מהו הקלט, איזו החלטה רוצים לקבל, ואיזו ראיה מספיקה כדי להצדיק אותה. השאלות האלה מונעות שימוש אוטומטי בכלי ללא הבנת המטרה.

בתרגול, רשמו את context, encoding, CSP, stored/reflected/DOM, sanitization, השוו להתנהגות צפויה והגדירו Pivot אחד לפחות. התוצאה צריכה להיות ניתנת לבדיקה על ידי אנליסט נוסף, כולל מגבלות וצעדי המשך.

CSP, Remediation ו-Retest

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

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

מוקדי בדיקה ייחודיים

בנושא הזה מומלץ לבנות מראש מפת ראיות ממוקדת. מוקדי הבדיקה המרכזיים הם: context, encoding, CSP, stored/reflected/DOM, sanitization, sink/source. הרשימה אינה Checklist אוטומטי; כל פריט נבחר משום שהוא יכול לקשור בין ישות, פעולה וזמן או להסביר התנהגות לגיטימית.

• context: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
• encoding: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
• CSP: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
• stored/reflected/DOM: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
• sanitization: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.
• sink/source: הגדירו מהו הערך הצפוי, מה ייחשב חריג ואיזה מקור נוסף יאמת את הממצא.

כאשר אחד המוקדים אינו זמין, יש לתעד את הפער ולבחור חלופה. לדוגמה, אם Process identifier אינו יציב, אפשר להיעזר בזמן, Host, User ו-Parent; אם Payload מוצפן, משתמשים ב-Metadata, נפח, תדירות ו-TLS/DNS context.

תהליך עבודה מומלץ

1. הגדירו Scope ושאלת עבודה אחת בנושא בדיקת XSS.
2. רשמו את מקורות הנתונים והראיות הדרושים: context, encoding, CSP, stored/reflected/DOM.
3. צרו Baseline קצר של התנהגות תקינה או תוצאה צפויה.
4. בצעו את הבדיקה המינימלית בסביבת מעבדה ושמרו זמן, קלט ופלט.
5. בנו Timeline או טבלת השוואה והפרידו בין עובדה לפרשנות.
6. בצעו Pivot למקור נוסף כדי לאמת או להפריך את ההסבר הראשוני.
7. סכמו החלטה, מגבלות, פעולה מומלצת וקריטריון Retest.

תרחיש מעשי

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

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

Checklist מעשי

• ✓בדקו ותעדו: Role ו-session.
• ✓בדקו ותעדו: Endpoint ו-method.
• ✓בדקו ותעדו: Request/Response.
• ✓בדקו ותעדו: Object identifier.
• ✓בדקו ותעדו: Server-side effect.
• ✓בדקו ותעדו: Control expected ו-remediation.
• ✓ציינו Time zone, גרסת כלי ושעת איסוף.
• ✓שמרו את הנתון הגולמי לפני סינון או שינוי.
• ✓כתבו מה הממצא מוכיח ומה עדיין אינו ידוע.
• ✓הגדירו בעלים ופעולת המשך עם מועד.

טעויות נפוצות

• לבדוק רק Status code.
• להסתמך על שינוי Client-side.
• להשתמש ב-Payload מסוכן.
• לא לבדוק Roles שונים.
• להתעלם מלוגיקה עסקית.
• לדווח בלי Request/Response נקיים.

העמקה מקצועית: איכות, הקשר ובקרה

עבודה איכותית בנושא בדיקת XSS נמדדת גם ביכולת לשחזר את הדרך למסקנה. מומלץ לשמור Query, Filter, Scope, Timestamp, Dataset וגרסת כלי. כך ניתן לבדוק מחדש את אותו מקרה לאחר שינוי תצורה או לאחר שמתקבל מידע נוסף.

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

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

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

סיכום ו-CTA

Cross-Site Scripting: Stored, Reflected ו-DOM הוא נושא שמחבר ידע טכני למשמעת עבודה. התחילו משאלה, אספו רק ראיות רלוונטיות, שמרו הקשר וזמן, ובחרו פעולה שאפשר להצדיק ולבדוק מחדש.

במסלול Cybersecurity & AI של HPI מתרגלים את העקרונות האלה באמצעות מערכות, לוגים ומעבדות. המשך טבעי הוא לעבור למאמרים המקושרים, לבצע את תרגיל המעבדה ולשמור את התוצר כחלק מתיק עבודות מקצועי.

שאלות ותשובות

מקורות

• OWASP Web Security Testing Guide
• OWASP Top 10:2025
• OWASP API Security Top 10:2023
• PortSwigger Web Security Academy
• OWASP ASVS