Ein-des-ein blog

פגיעויות אבטחת אינטרנט העיקריות ואיך להימנע מהן

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

מה זה OWASP?

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

סוגי פגיעויות אבטחה

1. הזרקת SQL
2. אימות שבור
3. איומים על חשיפת נתונים רגישים
4. ישויות חיצוניות XML (XXE)
5. תצורת יישום שגויה
6. דסיריאליזציה לא מאובטחת
7. מתקפות רכיבה על מושבים
8. שימוש ברכיבים עם בעיות אבטחה ידועות
9. חסר שליטה על גישה ברמת פונקציה
10. רישום ומעקב לא מספיקים

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

הזרקת SQL

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

איך להגן על האתר שלך

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

אימות שבור

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

• חוסר ניסיון של מפתחים 
• חוסר דרישות אבטחה
• לחץ לשחרר את המוצר

איך להגן על האתר שלך

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

המלצות טכניות של OWASP

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

איומים לחשיפת נתונים רגישים

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

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

דוגמאות לתרחישי התקפה

תסריט #1. 

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

תסריט #2. 

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

איך להגן על האתר שלך

• אל תשמור נתונים סודיים שלא לצורך. נתונים שאינם נשמרים לא יכולים להיגנב.
• ודא שישנם אלגוריתמים, פרוטוקולים ומפתחות סטנדרטיים מעודכנים ואמינים; השתמש בניהול מפתחות נכון.
• הצפן את כל הנתונים המועברים באמצעות פרוטוקולים מאובטחים, כגון TLS, עם פרמטרים מאובטחים והעדפת שרת להצפנה
• כבה את המטמון עבור תגובות המכילות נתונים רגישים
• שמור סיסמאות באמצעות פונקציות גיבוב חזקות, אדפטיביות ו"מלוחות" כגון Argon2, scrypt, bcrypt או PBKDF2

ישויות חיצוניות XML (XXE)

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

וקטורי התקפה עבור אובייקטים חיצוניים של XML

על פי עשרת הגדולים של OWASP, וקטורי ההתקפה העיקריים עבור אובייקטים חיצוניים של XML (XXE) כוללים את השימוש ב:

• מעבדי XML פגיעים (תוקפים יכולים לטעון XML או לכלול תוכן זדוני במסמך XML)
• קוד לא מוגן
• תלויות ואינטגרציות פגיעות

איך להגן על האתר שלך

• יישם אימות חיובי בצד השרת ("רשימה לבנה") של נתוני קלט וסינון כדי למנוע מנתונים זדוניים להיות בשימוש במסמכי XML, כותרות או צמתים.
• ודא שהפונקציה להעלאת XML או XSL מאמתת XML נכנס באמצעות XSD או כלי דומה.
• השתמש בכלי SAST כדי לעזור לזהות XXE בקוד המקור (אם כי בדיקת קוד ידנית היא חלופה טובה יותר באפליקציות גדולות ומורכבות עם הרבה אינטגרציות).

תצורת יישום שגויה

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

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

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

אובייקטים פגיעים

תצורות אבטחה שגויות יכולות להתרחש בכל רמה של ערימת היישום:

• שירותי רשת
• הפלטפורמה
• שרת אינטרנט
• שרת היישומים
• מסד נתונים
• מסגרות
• קוד משתמש
• מכונות וירטואליות מותקנות מראש
• מיכלים
• חנויות

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

דוגמאות לתרחישי התקפה

תסריט #1 

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

תסריט #2

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

איך להגן על האתר שלך

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

דסיריאליזציה לא בטוחה

ה-OWASP Top-10 מציין כי פגיעות האינטרנט הזו נוספה לרשימה בהתבסס על תוצאות סקר בתעשייה, ולא על מחקר של נתונים כמותיים. תוקפים תמיד ינסו "לשחק" עם כל דבר שמתקשר עם יישום, מ-URLs ועד אובייקטים מסודרים.

מהי דסיריאליזציה

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

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

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

תסריט #1

אפליקציית React קוראת לערכה של מיקרו-שירותים של Spring Boot. כמפתחים פונקציונליים, המפתחים ניסו להבטיח שהקוד שלהם יישאר עקבי. הפתרון שהם הגיעו אליו היה לסדר את מצב המשתמש ולשלוח אותו הלוך ושוב עם כל בקשה. התוקף שם לב לחתימה של האובייקט "R00" ומשתמש בכלי Java Serial Killer כדי להריץ את הקוד על השרת של האפליקציה מרחוק.

תסריט #2

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

איך להגן על האתר שלך

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

מתקפות רכיבה על סשן

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

התקפת XSS משתקפת: 

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

התקפות XSS מאוחסנות:

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

DOM XSS: 

מסגרות JavaScript, יישומים חד-עמודיים ו-APIs שמוסיפים נתונים הנשלטים על ידי תוקפים באופן דינמי פגיעים ל-DOM XSS.

איך להגן על האתר שלך

• השתמש במסגרת שנועדה ללא שימוש ב-XSS. 
• הפעלת מדיניות אבטחת תוכן (CSP) היא הגנה מקיפה שמפחיתה את הסיכון להתקפות XSS. 
• החלת קידוד רגיש להקשר בעת שינוי מסמך דפדפן בצד הלקוח

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

בימינו, אפילו אתרים פשוטים, כמו בלוגים אישיים, כוללים אינטגרציות רבות עם שירותים חיצוניים, תוספים ויישומים אחרים שיכולים להפוך לאתר התקפה. אי יכולת לעדכן כל תוכנה על השרת ובצד הלקוח של אתר, sooner or later, יוצרת סיכוני אבטחה חמורים. בשנת 2019, 56% מכלל יישומי ה-CMS היו מיושנים כאשר הם נדבקו.

הסיבות לקיום הפגיעות הזו

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

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

איך להגן על האתר שלך

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

חסר בקרת גישה ברמת פונקציה

רוב מערכות ניהול התוכן (CMS) חשופות לאיום אבטחת רשת זה. כברירת מחדל, לכולם יש גישה לדף הכניסה של המנהל. ברוב המקרים, אפילו שיטת האימות הדו-שלבי (2FA) לא בשימוש.

דוגמאות להפרת בקרת גישה

הנה כמה דוגמאות למה שאנחנו כוללים במושג גישה:

• גישה לפאנל הניהול של ההוסטינג
• גישה לשרת דרך FTP/SFTP/SSH
• גישה לפאנל הניהול של האתר שלך
• גישה ליישומים אחרים על השרת שלך
• גישה למסד הנתונים.

תוקפים יכולים להשתמש בפגמים בהרשאות למטרות הבאות:

• גישה לתכונות ו/או נתונים לא מורשים.
• צפייה בקבצים רגישים
• שינוי זכויות גישה

איך להגן על האתר שלך

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

• יישם מנגנוני בקרת גישה והשתמש בהם בכל שלב של היישום. צמצם את השימוש ב-CORS
• כבה את רשימת התיקיות של השרת ודא שמטא-נתונים של קבצים (כגון .git) וקבצי גיבוי אינם בתיקייה הראשית של השרת
• הגבל את תדירות הבקשות ל-API כדי לצמצם נזק מהתקפות אוטומטיות.

רישום ומעקב לא מספיק

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

תסריט התקפות

תסריט #1

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

תסריט #2

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

איך להגן על האתר שלך

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

איך למנוע איומי אבטחת יישומים באינטרנט?

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