מכיוון שייתכנו מספר פריצות בלתי תלויות, גם אם הצלחתם לאתר ולתקן נקודת חולשה אחת, מומלץ להמשיך לחפש נקודות חולשה אחרות. בתור התחלה, כדאי לקרוא על הדרכים העיקריות שבהן אתרים נפרצים על ידי מפיצי ספאם.
הנתונים הדרושים:
- גישת אדמין מעטפת או גישה של טרמינל לשרתי האתר שלכם: אינטרנט, מסד נתונים וקבצים
- היכרות עם פקודות מעטפת או טרמינל
- היכרות עם קוד (כגון PHP או JavaScript)
- היכולת להפעיל שני סורקי אנטי-וירוס
הפעולות הבאות
אנו נפרט כמה דרכים נפוצות שבהן ניתן לפגוע באתר. אני מקווה שאחת מהאפשרויות האלה תחול על האתר שלכם, או לפחות תבהיר לכם על אפשרויות נוספות.
שימו לב שסורקי נקודות חולשה שונים מסורקי אנטי-וירוס. סורקי נקודות חולשה יכולים להיות הרבה יותר פולשניים ויש להם פוטנציאל גדול יותר לגרום נזק לא רצוי לאתר שלכם. לפני שמריצים את הסורק צריך לפעול לפי כל ההנחיות, למשל גיבוי האתר.
נקודות חולשה פוטנציאליות {potential-vulnerabilities}
הפגיעויות פוטנציאליות לבדיקה כוללות:
מחשב של מנהל נגוע בווירוס
במחשב של מנהל מערכת נגוע בווירוס, ייתכן שההאקר התקין רוגלה כדי לתעד את ההקשות של מנהל האתר.
- לבדוק אם יש וירוסים במערכות של האדמינים. אנחנו ממליצים להפעיל כמה סורקים מהימנים של אנטי-וירוס (AV) בכל מחשב שמנהל מערכת השתמש בו כדי להיכנס לאתר. מכיוון שההדבקה של תוכנות זדוניות חדשות מתוכננות באופן קבוע להתחמק מסורקים, זו לא שיטה מובטחת לזיהוי וירוסים. הפעלה של מספר סורקים עוזרת למנוע תוצאות חיוביות מוטעות ומספקת נקודות נתונים נוספות כדי לקבוע אם קיימת נקודת חולשה. ליתר ביטחון, כדאי גם לסרוק את שרת האינטרנט וגם את כל המכשירים שמשמשים לעדכון או לפרסום באתר.
- אם סורק ה-AV מזהה רוגלה, וירוס, סוס טרויאני או כל תוכנה חשודה אחרת, בדקו את יומני השרת של האתר כדי לבדוק אם מנהל המערכת הוא הבעלים של המחשב הנגוע.
- ייתכן שההאקר שינה קובצי יומן. אם הם לא עשו זאת, קישור שם המשתמש של האדמין לפקודות חשודות בקובץ היומן מהווה הוכחה נוספת לכך שווירוס במערכת של האדמין הפך את האתר לפגיע.
סיסמאות חלשות או בשימוש חוזר
להאקרים קל יותר לגלות סיסמאות חלשות, ומספקות להם גישה ישירה לשרת. בסיסמאות חזקות יש שילוב של אותיות ומספרים, פיסוק, ובלי מילים או סלנג שעשויים להימצא במילון. יש להשתמש בסיסמאות עבור יישום אחד בלבד, אין לעשות בהן שימוש חוזר ברחבי האינטרנט. במקרה שנעשה שימוש חוזר בסיסמאות, דרושה רק פרצת אבטחה אחת באפליקציה אחת כדי שהאקר יוכל למצוא פרטי התחברות וסיסמה שבהם הוא יכול להשתמש במקומות אחרים.
ביומן השרת, בודקים אם יש פעילות לא רצויה, כמו ניסיונות התחברות מרובים של אדמין או של אדמין שמבצע פקודות לא צפויות. שימו לב מתי התרחשה הפעילות החשודה, כי כשיודעים מתי הפריצה התרחשה, אפשר לדעת אילו גיבויים עדיין נקיים.
תוכנה לא עדכנית
בדקו שבשרתים שלכם מותקנת הגרסה האחרונה של מערכת ההפעלה, מערכת ניהול התוכן, פלטפורמת הבלוגים, האפליקציות, יישומי הפלאגין וכל תוכנה אחרת אחרת שבה האתר משתמש.
- לערוך מחקר על כל התוכנות שהותקנו (למשל באמצעות חיפוש באינטרנט) כדי לקבוע אם הגרסה כוללת הודעת אבטחה. אם כן, סביר להניח שתוכנה לא עדכנית הפכה את האתר שלכם לפגיע.
- מומלץ תמיד להקפיד לעדכן את תוכנות השרתים שלכם, גם אם תוכנה לא עדכנית גרמה לבעיה הספציפית הזו.
4. הרגלי קידוד מתירניים, כגון כתובות אתר פתוחות להפניה מחדש והחדרות SQL
כתובות אתר פתוחות להפניה מחדש
הפניות אוטומטיות פתוחות מקודדות במטרה לאפשר למבנה של כתובות ה-URL להוסיף כתובת URL אחרת, כדי שהמשתמשים יוכלו להגיע לקובץ או לדף שימושיים באתר. לדוגמה:
http://example.com/page.php?url=http://example.com/good-file.pdf
או
http://example.com/page.php?url=malware-attack-site>
- אם האתר שלכם מנוצל לרעה על ידי הפניות אוטומטיות פתוחות, סביר להניח שההודעה ב-Search Console מספקת כתובות URL לדוגמה, שכוללות כתובות URL פתוחות להפניה אוטומטית ליעד לא רצוי.
- כדי למנוע הפניות פתוחות בעתיד, כדאי לבדוק את הדברים הבאים:
- האם האפשרות 'התרת הפניות אוטומטיות פתוחות' מופעלת כברירת מחדל בתוכנה.
- האם הקוד שלכם יכול לאסור הפניות לכתובות אחרות מחוץ לדומיין.
- אם אתם יכולים לחתום על ההפניה האוטומטית כך שתוכלו להמשיך לבצע הפניות אוטומטיות רק עם כתובות URL שעברו גיבוב (hash) נכון, עם החתימה הקריפטוגרפית הנכונה.
החדרות SQL
החדרות SQL מתרחשות כשהאקר יכול להוסיף פקודות מתחזות לשדות קלט של משתמשים שמופעלים במסד הנתונים. החדרות SQL מעדכנות את הרשומות במסד הנתונים עם תוכן ספאם או תוכנות זדוניות לא רצויות, או שהן יוצרות נתונים חשובים ליצירת פלט עבור ההאקר. אם האתר שלכם משתמש במסד נתונים, ובמיוחד אם נדבקתם בתוכנות זדוניות, ייתכן שהאתר נפגע מהחדרת SQL.
- נכנסים לשרת מסד הנתונים ומחפשים תוכן חשוד במסד הנתונים, כמו שדות טקסט רגילים שמציגים עכשיו iframes או סקריפטים.
- לגבי ערכים חשודים, צריך לבדוק שקלט המשתמש אומת ומקודד כמו שצריך, או אולי מוקלד בצורה חזקה כדי שאי אפשר יהיה להריץ אותם כקוד. אם הקלט של המשתמש לא נבדק לפני העיבוד של מסד הנתונים, הזרקת SQL עלולה להיות נקודת חולשה באתר שלכם.