6.3 הגנות xss הרצאה

הגנה מ-XSS (Cross-Site Scripting)

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

---

הגנות מ-XSS

1. CSP (Content Security Policy)

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

דוגמת הדר CSP בהגדרות השרת:

Content-Security-Policy: default-src 'self'; script-src 'self' https://apis.google.com; object-src 'none'; style-src 'self';

📌 הסבר:
הגדרה זו מתירה לטעון סקריפטים רק מתוך הדומיין הנוכחי ('self') או מ-https://apis.google.com ומונעת טעינת אובייקטים או סקריפטים ממקורות לא מאובטחים.
כך שכאשר הדפדפן שלנו מקבל את העמוד שאותו אנחנו טוענים עם הheader הזה, אז הדפדפן שלנו ידע מאיזה עמודים הוא יכול לקבל javascript ומאיפה אי אפשר.

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

---

2. SOP (Same-Origin Policy)

מדיניות מקור זהה (Same-Origin Policy - SOP) היא מנגנון אבטחה קריטי בדפדפנים שמגביל אינטראקציה בין דפים או סקריפטים מדומיינים שונים. לפי מדיניות זו, סקריפט שפועל בדף אינטרנט יכול לגשת לנתונים או לשלוח בקשות רק לאותו דומיין, פרוטוקול (HTTP/HTTPS) ופורט שמהם הוא נטען.

הגדרת "מקור זהה":
שני דפים נחשבים מאותו מקור אם יש להם את אותו:
- פרוטוקול (HTTP / HTTPS)
- דומיין (example.com)
- פורט (80 / 443)

דוגמאות:
1. מקור זהה:
- https://example.com/page1 ו-https://example.com/page2 – חולקים אותו מקור.
- http://example.com ו-http://example.com:80 – חולקים אותו מקור (פורט 80 הוא ברירת המחדל של HTTP).

1. מקור שונה:
2. https://example.com ו-http://example.com – פרוטוקול שונה (HTTPS vs HTTP).
3. https://example.com ו-https://sub.example.com – תת-דומיין שונה.
4. https://example.com ו-https://example.org – דומיין שונה.
5. https://example.com:80 ו-https://example.com:443 – פורט שונה.

---

איך SOP עוזר בהגנה מפני XSS?

התקפות Cross-Site Scripting (XSS) מאפשרות לתוקף להזריק קוד JavaScript זדוני לדף אינטרנט. ללא SOP, הסקריפט הזדוני יכול:
- לגשת לנתונים רגישים (כמו עוגיות או tokenי הרשאה).
- לשלוח בקשות לשרתים פנימיים (למשל, ממשקי API של אתר הבנק שלך).
- לבצע פעולות בשם המשתמש המאומת.

SOP מגביל את הנזק האפשרי מ-XSS:
- חסימת גישה לנתונים מדומיינים אחרים:
- אם אתר evil.com מנסה לגשת ל-https://bank.com/api דרך JavaScript, הדפדפן יחסום את הבקשה.
- מניעת שליחת בקשות לא מורשות:
- גם אם תוקף מצליח להזריק סקריפט XSS ב-example.com, הוא לא יוכל לשלוח בקשות ל-api.internal.com (אלא אם יש CORS).

דוגמה מעשית:
נניח שיש לך אתר פגיע ל-XSS ב-https://social-site.com, ותוקף מזריק את הסקריפט הבא:

fetch("https://bank.com/transfer", {
  method: "POST",
  body: JSON.stringify({ to: "hacker", amount: 1000 }),
  credentials: "include" // שולח עוגיות אוטומטית
});

- ללא SOP: הסקריפט היה יכול לבצע העברה מחשבון המשתמש ב-bank.com אם הוא מחובר.
- עם SOP: הדפדפן יחסום את הבקשה כי social-site.com ו-bank.com הם דומיינים שונים.

---

האם SOP מספיק להגנה מוחלטת?

לא. SOP הוא רק שכבת הגנה אחת, ויש דרכים לעקוף אותו במקרים מסוימים:
1. CORS (Cross-Origin Resource Sharing) – מאפשר גישה בין דומיינים אם השרת מאשר זאת במפורש.
- לדוגמה, אם bank.com מגדיר Access-Control-Allow-Origin: *, אתרים אחרים יוכלו לגשת אליו.
2. JSONP (מיושן אך עדיין קיים) – טכניקה ישנה שמאפשרת טעינת נתונים מדומיין שונה באמצעות תגיות <script>.
3. התקפות CSRF – SOP לא חוסם בקשות שליחה (כמו POST דרך <form>), רק קריאת תגובה.

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

3. Escaping (הימנעות מבעיות קידוד)

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

דוגמת escaping ב-PHP:

$user_input = $_GET['user_input'];
$safe_input = htmlspecialchars($user_input, ENT_QUOTES, 'UTF-8');
echo "<div>$safe_input</div>";

📌 הסבר:
הפונקציה htmlspecialchars() משנה את התוונים המיוחדים (<, >, &, ", ') כדי שלא יתפרשו כקוד HTML או JavaScript.

איך זה עוזר בהגנה על XSS?
הימנעות מבעיות קידוד מונעת מהקוד שהוזן על ידי המשתמש להיבנות כקוד HTML או JavaScript זדוני, וכך נמנע ממתקפת XSS.

---

4. innerHTML

מה זה innerHTML?
הפונקציה innerHTML מאפשרת להכניס תוכן HTML לדף דרך JavaScript. אבל שימוש לא נכון בה יכול לחשוף את האתר להתקפות XSS.

דוגמת קוד פגיע ב-JavaScript:

document.getElementById('output').innerHTML = user_input;

📌 הסבר:
אם המשתמש מזין קוד HTML או JavaScript זדוני, הוא יוצג ויתבצע בסביבת הדפדפן של המשתמש.

איך למנוע את הפגיעות? במקום להשתמש ב-innerHTML, יש להשתמש ב-textContent או ב-createElement להכניס תוכן טקסטואלי בלבד, כך שאין סיכון להזרקת קוד זדוני.

דוגמת קוד מאובטח:

document.getElementById('output').textContent = user_input;

---

סיכום הגנות מ-XSS:

1. CSP – מגביל את מקורות הסקריפטים ומונע הרצת קוד זדוני.

2. SOP – מונע מתוקפים לשלוח בקשות או לגשת למידע מדומיינים אחרים.

3. Escaping – מוודא שהקלט של המשתמש לא יתפרש כקוד HTML או JavaScript.

4. innerHTML – יש להימנע משימוש בו כדי להימנע מהזרקת קוד זדוני. במקום זאת, השתמשו ב-textContent.