מה זה XSS?
אז Cross-site scripting או XSS היא חולשה בה התוקף יכול לנצל את האינטראקציות של המשתמש באתר שלנו.
במילים אחרות, בעזרת XSS אפשר לגרום למשתמש הקצה לבצע פעולות שנראות לגיטימיות משום שהן קורות תחת הברנד של המוצר או האתר שאליו הוא מחובר או פשוט לגנוב מידע אודותיו.
אם לקורבן יש הרשאות מסוימות באותה אפליקציית ווב אזי לתוקף יש יכולת לגשת ולהשתמש באותן יכולות כדי לקרוא או לשנות מידע תוך כדי שהוא מוליך שולל את המשתמש דרך שינויים ב UI.
ההבדל בין XSS ל- CSRF הוא שב CSRF אין צורך בפועולות פיזיות של המשתמש מאחר והתוקף השיג את הטוקן שעל פיו השרת מזהה משתמש שעבר אותנטיקציה.
שימושים שכיחים ל XSS
- התחזות למשתמש מסוים.
- לבצע פעולות שהמשתמש רשאי להן.
- קריאה של נתונים שלמשתמש יש גישה אליהם.
- תפיסה ושימוש בפרטי התחברות של משתמש.
- שינוי פני האתר.
- גישה להיסטוריית הדפדפן ולתוכן ה clipboard (מה שהמשתמש העתיק).
- סריקה וניצול של מכשירים או יישומים מחוברים.
איך זה עובד?
התוקף מזהה פרצת קוד המאפשרת לו להזריק קוד HTML או JS זדוני. בעזרת אותו קטע קוד הוא גורם למשתמש לבצע את הפעולות שהוא רוצה.
אם ניקח לדוגמא אתר שעושה שימוש ב query param בשם name מתוך ה url ומזריק את הערך שלו לתוך ה HTML של האתר, נוכל להזריק כל קטע קוד שנרצה.
כל שנצטרך לעשות הוא לשלוח מייל או הודעה לקורבן עם לינק כמו זה ->
https://example.com/status?name=<script>some malicious code</script>
האתר מכניס את הערך של name בצורה הבאה ->
<p>Name: <script>some malicious code/</script></p>
וכך ברגע שהקורבן יכנס לאתר הוא יקבל סקריפט זדוני. למשל, הסקריפט יכול להציג טופס תמים שגורם לו לשלוח פרטים אישיים לנקודת קצה של התוקף.
ניצול חולשה דרך url היא סוג אחד מתוך שלוש של XSS. מה הם שלושת הסוגים? פשוט תמשיכו לקרוא…
XSS בעזרת שיקוף פרמטרים – Reflected cross-site scripting
שיטה זו הידועה גם בכינויה ״XSS לא עקבי״, עוסקת בחולשות מהסגנון של הדוגמא מהפסקה למעלה. התוקף עושה שימוש בפרמטרים מה- url שלא עוברים סניטציה ומשתקפים ישירות לגולש דרך ה HTML.
XSS ממידע שמור – Stored cross-site scripting
שיטה זו הידועה גם בכינויה ״XSS עקבי״, היא ניצול חולשה של הכנסת ערך המגיע ממקור עם מידע עקבי המועבר לאפליקציה שלנו מאוחר יותר. המידע יכול להגיע למשל מבסיס נתונים שלנו או של גורם צד שלישי, במידה והיתה אפשרות להכניס לתוכו HTML לא מסונתז.
דוגמא קלאסית היא כאשר הטמענו קוד של ספק צ׳אטים אונליין שלא דאג להתגונן מפני XSS.
אם התוקף הכניס להודעת הצ׳אט סקריפט ובצד השני, בו נמצא הקורבן, ההודעה מוטמעת בתוך ה HTML, תהיה אפשרות לבצע פעולה זדונית, כזו שתוליך שולל את הקורבן.
XSS מבוסס DOM – DOM based cross site scripting
בשיטה הזו ניתן להזריק קוד זדוני דרך מניפולציה שקורת בקוד שלנו על ה DOM. דוגמא קלאסית היא הכנסה של כל ה url לתוך ה innerHTML של אלמנט ב DOM, למשל, בעמוד 404 עם הכתובת המבוקשת.
שימוש XSS מבוסס DOM לא מחייב שיקוף של הקוד הזדוני מיידית על המסך, אלא יכול לקרות גם לאחר פעולה שמבצע המשתמש. למשל, בקוד שלוקח ערך של שדה טקסט ולאחר לחיצה על כפתור "שלח" בטופס ומציג את הערך בתוך ה DOM. במצב כזה אם ניתן להכניס ערך התחלתי לאותו שדה טקסט דרך כתובת האתר יהיה ניתן להזריק אליו קוד זדוני שיפעל ברגע שליחת הטופס.
למעשה, רוב הפריימוורקים לבניית אפליקציות ווב כגון React, Angular ו- Vue, משתמשים במנגנון סניטציה עבור הכנסת משתנה דינמי ל HTML כברירת מחדל.
במה גישה זו שונה מה Reflected XSS?
ממאמר של עמית קליין עולה שבשני סוגי ה XSS הראשונים המידע עובר דרך שרת. השרת יכול לבחון את ה url ובמידה ויש קוד זדוני לבצע התאמות.
ההבדל בא לידי ביטוי כאשר מעבירים ב url ערכים דרך תגית hash (#), לדוגמא ->
https://example.com/status#<script>some malicious code</script>
החלק שנמצא אחרי תגית ה- # מבחינת השרת הוא לא חלק מה- query של הכתובת המבוקשת. במצב כזה השרת לא מודע אליו ומכאן שהדרך להתגונן היא קודם כל בצד של הדפדפן.
איך מתגוננים נגד זה?
סניטציה של המחרוזת
במידה ויש לנו מחרוזת שנרצה להזריק לתוך ה HTML נוכל להעביר אותה תהליך של סניטציה. בתהליך זה נרצה למחוק תגיות HTML או אטריביוטים לא מורשים. כיום עובדים על גירסא ניסיונית של Sanitizer מובנה בדפדפן. בינתיים יש לא מעט כלים אחרים שעוזרים במלאכה.
- DOMPurify – אפשר גם להיכנס לסביבת לייב לבדיקות.
- js-xss
- sanitize-html – יש גם גירסא לריאקט
שימוש ב CSP – Content Security Policy
בעזרת CSP מגדירים איזה תוכן ומאילו כתובת נטען אותו בתוך האתר שלנו. טכניקה זו יכולה בהחלט לצמצם את כמות האפשרויות לניצול חולשות XSS.
ניתן לקנפג CSP דרך האדרים שחוזרים מהשרת או דרך תגית meta, מזמין אתכם להעמיק במאמר הבא.
הפכו את הערך ל HTML Entities
בעזרת פעולת encode ניתן להמיר תווים ל HTML Entities לפני שמכניסים אותם לתוך ה HTML.
להלן קוד שממיר טווח מסוים של תווים על פי unicode ל HTML Entities שלהם ->
const encodedStr = rawStr.replace(/[\u00A0-\u9999<>\&]/g, function(i) {
return '&#'+i.charCodeAt(0)+';';
});שימוש ב- createTextNode
document.createTextNode מחזיר אלמנט שניתן לדחוף כבן של אלמנט אחר רק שהתוכן שלו הוא טקסט רגיל.
תגית template
תגית <template> מונעת ריצה של חלק מהאלמנטים, ביניהם תגיות script או events attributes (כמו onload, onclick וכו׳) וכך ניתן לדחוף קוד HTML מבלי לחשוש.
לסיכום
אבטחה היא לא נושא שרלוונטי רק לצד השרת, גם בצד הלקוח צריכים להיות מודעים לחולשות שיכולות להזיק למשתמשים שלנו.
כפי שפרטתי במאמר XSS יכול להגיע בדרכים וצורות שונות אך בכולן המטרה היא להשתמש ביוזר דרך האתר שלנו.
זו אומנם חולשה שדי קל לפתור אותה אך הזיהוי שלה יכול להגיע רק לאחר מעשה. מומלץ להשתמש בכלים המפורטים למעלה בכדי לצמצם אפשרות שתתרחש אצלנו.