Web, XSS, LFI RFI, CSRF, SQL

מבוא כללי

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

גופי מחקר ופיתוח שונים בישראל שמים דגש מיוחד על נושא זה.
לרבים העוסקים באבטחת מידע חשוב להכיר לעומק את פרצות הווב הנפוצות, מאחר שהן פוגעות ברמות שונות של Confidentiality ו-Integrity וביכולת המשתמשים לשמור על פרטיותם.
נושאים כמו ‪XSS‬, ‪LFI‬, ‪RFI‬, ‪CSRF‬ ו-‪SQL Injection‬ הם רק חלק קטן מעולם עשיר של מתקפות אפשריות.
חשיפה למתקפות אלו ולשיטות ההתגוננות מהן מעניקה בסיס חיוני להתמודדות עם אירועי אבטחה מגוונים.

הבנת פרצת ‪XSS‬ (Cross-Site Scripting)

‪XSS‬ הוא אחד מסוגי המתקפות הנפוצים ביותר בכל הקשור לאפליקציות ווב.
הרעיון העיקרי הוא הזרקה של קוד ‪JavaScript‬ זדוני אל תוך הדפדפן של המשתמש.
ניתן לחלק את ‪XSS‬ למספר תתי-סוגים עיקריים.
חשוב להבין את ההבדל בין ‪Stored‬ ל-‪Reflected‬, וכן להכיר גם מתקפות ‪DOM‬-Based.

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

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

אחת מדרכי ההתגוננות הבסיסיות היא סינון והסרת כל תווים או מחרוזות חשודות שעשויים להשתלב כקוד.
עם זאת, מסננים פשוטים מחליפים לעיתים רק תווים בסיסיים כמו < או > ולכן תוקפים יכולים להזריק אירועים כגון onerror או onclick בתוך תגיות ‪HTML‬ כדי לעקוף מנגנוני אבטחה.
ניתן להוסיף שכבות הגנה נוספות דוגמת ‪CSP‬ להגבלת מקורות טעינת סקריפטים, אך יש לזכור שאלו לא תמיד חוסמים את כל התקפות ‪XSS‬ באופן מוחלט.

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

פרצות ‪LFI‬ (Local File Inclusion) ו-‪RFI‬ (Remote File Inclusion)

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

ב-‪RFI‬, המאיים הרבה יותר, התוקף מציין נתיב לקובץ מרוחק ומאלץ את השרת לטעון ולהריץ אותו.
פעולה זו יכולה להוביל להרצת קוד זדוני באופן מיידי.
אם הקובץ המרוחק כולל ‪PHP‬ זדוני למשל, התוקף עלול לפתוח לעצמו ‪Web Shell‬ ולקבל שליטה נרחבת על השרת.
ההבדל העיקרי בין השניים הוא שמתקפת ‪RFI‬ מתמקדת בהרצה של קובץ חיצוני בעוד ‪LFI‬ פועלת על קבצים המקומיים בשרת.

ישנן טכניקות רבות לעקוף בדיקות מסלול פשוטות.
דוגמה נפוצה היא שימוש בסימנים כמו ../ או בגרסאות מקודדות דוגמת %2e%2e, במטרה לצאת מחוץ לתיקיות מוגדרות ולהגיע לקבצים רגישים.
הדבר מכונה לעיתים Path Traversal.
כדאי לוודא שהאפליקציה מוודאת במדויק את הנתיב הסופי שאליו מתייחס המשתמש, ושהיא אינה מסתמכת אך ורק על בדיקות טקסטואליות בסיסיות.

הבנת מתקפת ‪CSRF‬ (Cross-Site Request Forgery)

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

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

יש טכניקות נוספות היכולות לסייע בצמצום הסיכון.
אחת מהן היא הגדרת SameSite ב-‪Cookies‬.
ערך SameSite Strict או אפילו Lax יכול למנוע מהדפדפן לשלוח את ה-‪Cookies‬ כאשר הבקשה מגיעה מדומיין חיצוני.
בכך מצטמצמת מאוד ההסתברות להטעיית דפדפן לבצע בקשה מזויפת עם הרשאות המשתמש.

יחד עם זאת, מנגנונים כמו ‪HSTS‬ או ‪CSP‬ אינם מספיקים לבדם נגד ‪CSRF‬.
הם אמנם שימושיים בהצפנת התקשורת או בהגבלת מקורות טעינת משאבים, אך הם לא מספקים מנגנון לווידוא שהבקשה מגיעה באמת מהמקור הרצוי.
לכן שילוב נכון של ‪CSRF Token‬ והנחיות SameSite חיוני להגנה מירבית.

הבנת ‪SQL‬ Injection ואסטרטגיות הגנה

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

שיטה אפקטיבית מאוד למניעת מתקפות כאלה היא שימוש ב-‪Prepared Statements‬ או ‪Parametrized Queries‬.
כך מבוצעת הפרדה בין פקודת ה-‪SQL‬ לנתונים המוזנים, ומונעת אפשרות להחדיר פקודות חדשות.
טכניקה זו עדיפה בהרבה על שרשור מחרוזת רגילה שבה ניתן לנצל תווים כמו ' או ; כדי לשבור את השאילתה.

קיימות טכניקות מתקדמות כמו ‪Blind SQL Injection‬, שבה התוקף אינו מקבל שגיאות או תוצאות ישירות מהשרת.
במקום זאת הוא מסתמך על תגובות בוליאניות (אמת או שקר) או מודד זמן תגובה כדי להסיק מסקנות על מבנה הנתונים.
זו מתקפה איטית אך יכולה להיות יעילה מאוד אם האתר אכן פגיע.

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

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

מתקפות ‪HTTP‬ Parameter Pollution

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

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

מדוע ‪HSTS‬ ו-‪CSP‬ אינם מונעים את כל המתקפות

‪HSTS‬ או בשמו המלא ‪HTTP Strict Transport Security‬ מבטיח שהדפדפן יוצר קשר רק ב-‪HTTPS‬.
הוא נועד למנוע התקפות על ידי יירוט או האזנה בלתי מורשית, אך אינו מונע הזרקת קוד זדוני.
אם האתר עצמו פגיע ל-‪XSS‬ או ‪CSRF‬, הצפנת התקשורת אינה רלוונטית לעצם ההרצה של הקוד הזדוני.

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

חשיבות הידע בתחום האבטחה

אנשי אבטחת מידע נדרשים להבין לעומק את כל המתקפות שתוארו כאן כדי לתת מענה מתאים.
הידע הזה קריטי במיוחד למי שמתכנן להשתלב בתחום, וגם למי שכבר פעיל ורוצה לחזק את ההגנה על מערכות מבצעיות.
הכרות עם פרצות כמו ‪XSS‬, ‪LFI‬, ‪RFI‬, ‪CSRF‬ ו-‪SQL Injection‬ אינה רק תיאורטית אלא הכרחית בבניית תשתית חזקה באתרי ווב.

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

רלוונטיות לקהל הישראלי

בישראל קיים ביקוש רב למומחי אבטחה בדגש על ווב.

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

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

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

סיכום

מדריך זה שם דגש על פרצות אבטחת מידע נפוצות בווב ועל הדרכים להתמודד איתן.
הסברנו את ההבדלים בין ‪Stored‬ ו-‪Reflected XSS‬, את ההשלכות של ‪LFI‬ ו-‪RFI‬, את אופן הפעולה של ‪CSRF‬ וכן את מנגנוני ההגנה מול ‪SQL Injection‬.
לכל פרצה קיימת שורת טכניקות ושיטות הקשחה שעליהן מומלץ להקפיד, כולל שימוש ב-‪Token‬ עבור טפסים, ‪Prepared Statements‬ והגדרות אבטחה כדוגמת SameSite.
אין פתרון אחד מושלם לכל התרחישים.
השילוב בין תצורה מאובטחת, ולידציה קפדנית וסקרי אבטחה שוטפים הוא המפתח להפחתת הסיכון.

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

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

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