מבוא לאבטחת מידע: XSS

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

במאמר הקודם דיברנו על SQL Injection

איך קליינט סייד באתר עובד

אז נתחיל? ראשית אנחנו צריכים להבין מה זה בק אנד ופרונט אנד, או קליינט סייד באתר. מה קורה כשאני נכנס עם דפדפן לאתר אינטרנט? אני משגר בקשה לשרת: ״הבא לי את הכתובת של העמוד about-me״, השרת מקבל את הבקשה, מעביר אותה לתוכנה שהוא מריץ (למשל PHP, או פייתון או Node.js), התוכנה בודקת את כל הפרמטרים ומחזירה תשובה. התשובה בדרך כלל היא קבצי HTML, CSS וג׳אווהסקריפט.

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

נעבור במהירות על הקבצים האלו:

קובץ HTML – מכיל את המידע והתגיות של האתר. יכול להכיל גם קוד ג׳אווהסקריפט עצמאי.

קבצי ג׳אווהסקריפט – קוד תוכנה שרץ על דף ה-HTML.

קבצי CSS – קובע את העיצוב של האתר (לא נדון בו במאמר זה)

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

מה קורה אם תוקף משתלט על קובץ הג׳אווהסקריפט ומשנה את תוכנו? הוא בעצם שולט באתר. עם קובץ ג׳אווהסקריפט בשליטתו הוא יכול:

1. להחליף את תוכן ה-HTML לפי בחירתו ולשנות את תצוגת האתר.
2. להעביר את המשתמש לאתר אחר.
3. להריץ קוד שעוקב אחר המשתמש ואם הוא מזין פרטי אשראי הוא יכול לקחת אותו.
4. לגנוב את פרטי החיבור של המשתמש.
5. להקפיץ חלונית למשתמש, לבשר לו שהוא זכה במיליון דולר ולשכנע אותו להקליד פרטים.

קוד ג׳אווהסקריפט לא יכול (ברוב המוחלט של המקרים) לעשות נזק למחשב או להריץ קוד על המחשב של המשתמש שנכנס לאתר, אבל אפשר לעשות מה שרוצים באתר. אם המשתמש סומך על האתר, לפי שם המתחם ורואה שיש HTTPS והכל ובאמת בודק אותו – עדיין קוד הג׳אווהסקריפט יכול לעשות תעלולים רבים ולא נעימים.

להזכירכם: קוד ג׳אווהסקריפט יכול להתקיים גם לא רק כקובץ עצמאי אלא כחלק מה-HTML.

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

אבל איך התוקף יכול לשלוט על קבצי הג׳אווהסקריפט? או איך הוא יכול להזריק את הקוד שלו לתוך האתר? XSS עוסק בזה בדיוק – ביכולת של תוקף להכניס קוד משל עצמו לאתר מבלי שבעל האתר ידע. או בקובץ ג׳אווהסקריפט או כחלק מה-HTML ראשי התיבות של XSS הן Cross Site Scripting – הזרקה של קוד לאתר מבלי שבעל האתר יודע.

ההתקפה עצמה

כאשר אנו דנים ביכולת להזריק קוד, אנחנו בדרך כלל מדגימים באמצעות הקוד הזה:

<script>alert(1)</script>

הנה דוגמה של הקוד הזה. זה קוד ג׳אווהסקריפט שמקפיץ חלון שמראה ״1״ אם אנו משתילים אותו בקוד ה-HTML של הדף. לא צריך להיות גאון קוד כדי לראות ולהבין מה בדיוק הקוד עושה. אנו קוראים לקוד כזה Payload. מטען שאותו תוקף אמור להזריק.

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

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

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

או קיי, זה כבר מרמז על משהו מעניין. אני יכול להכניס לשם קוד שלי. למשל:

 https://example.com/?p=<script>alert(1)</script>

אני אקבל alert(1)!!!

למה? כי השרת ברוב חוכמתו האינסופית, מתוכנת להדפיס משהו כזה:

העמוד [פרמטר] חסר! אנא נסה שוב מאוחר יותר

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

העמוד <script>alert(1)</script> חסר! אנא נסה שוב מאוחר יותר

וככה מתבצע ה-XSS.

ה-XSS הזה נקרא reflected XSS. כי הוא משתקף מפרמטר שהתוקף מכניס.

הסיכון שיש בפרצה הזו

אז רגע, מה הבעיה פה? אז התוקף יכול להקפיץ לעצמו alert? הרי זו פרצה בצד לקוח, אין פה שום משהו שהוא יכול לעשות לשרת. זה נכון, אבל התוקף יכול למשל להכין <script> שעושה דברים יותר יותר גרועים (וגם יותר ארוך, כי הוא יכול להטען ממקומות אחרים) ולהעביר אותו לאנשים במתקפת ספאם או סקאם כמו שאנו רגילים לראות. יש קוד של תוקף שרץ על אתר שלא התכוון להריץ אותו.

יש לנו XSS יותר פשוט שנקרא Stored XSS. הוא עובד באופן יותר פשוט – הפורץ מאתר מקום שבו הוא יכול להכניס קלט לאתר שמאפשר לו להכניס קוד ג׳אווהסקריפט ולשמור אותו במסד הנתונים ואז הוא יופיע באתר בלי הזרקה בכלל.

למשל בטוקבקים, אם אני יכול להכניס

<script>alert(1)</script>

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

איך מונעים XSS?

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

1. שימוש בWAF על מנת לצמצם או אפילו למנוע Payloads שנראים זדוניים. בטח ובטח כאלו הכוללים תגיות חשודות.
2. לא לסמוך על קלט מצד המשתמש מבלי להעביר אותו ולידציה. הליך וידוא שכל פרמטר הוא אכן מה שאני חושב שהוא. למשל בדיקה שמדובר רק באותיות בעברית או באנגלית ולא > או < למשל. ישנן ספריות ולדיציה רבות בכל שפת תוכנה ופלטפורמה.
3. לא להדפיס פלט, לא משנה מה מקורו, ללא סניטציה. כל הפריימוורקים והספריות בצד הלקוח תומכות בסניטציה.
4. שימוש ב-CSP על מנת למנוע טעינה של סקריפטים ממקור לא מאושר. כך גם אם התוקף מצליח לבצע הזרקה, הוא לא יצליח לטעון סקריפט ממקור מרוחק.

פרצות כאלו שאירעו בעבר:

האמת שיש הרבה, הנה כמה שסיקרתי/מצאתי:

משרד התפוצות – שנה לא טובה

אתר Bestore (שלוש פרצות שהתגלו אחת אחרי השניה)

עירית רחובות

חומרים לקריאה נוספת:

מאמר הסבר על XSS ודוגמה להתקפה אמיתית כזו באתר המצוין CamelCase (עברית)

הסבר על XSS בדגש על שיטות הגנה בבלוג המומלץ של אדיר קנדל (עברית)

מאמר בגיק טיים של יקיר המערכת ים מסיקה על XSS (עברית)

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