רוב בעלי האתרים חושבים שאבטחה זה משהו שקורה בשרת. תוסף אבטחה, SSL, סיסמה חזקה – וזהו.
אבל חלק גדול מהפרצות שאני רואה מגיע ממקום אחר לגמרי: מהחלטות קטנות שנעשו בזמן בניית האתר, בלי לחשוב פעמיים.
אני מתחילה סדרה של טיפים לאבטחת מידע לאתרים ואפליקציות. זה החלק הראשון – חמישה דברים שאפשר לתקן היום, בלי מפתח ובלי תקציב.
אבטחת מידע לאתרים מתחילה בהחלטות בסיסיות בשלב הבנייה – שמות משתמש, אימות בצד השרת, והגבלת גישה – עוד לפני התקנת תוספי אבטחה.
https://youtube.com/shorts/tLL5hmGWfJo?feature=share
1. שם המשתמש שלכם הוא חצי מהסיסמה
זו הטעות הכי נפוצה שאני רואה, והכי קלה לתיקון.
בעל עסק בשם דני פותח אתר. שם המשתמש שהוא בוחר? dani. או גרוע מזה – [email protected], בדיוק כמו המייל שמופיע בעמוד "צור קשר".
עכשיו תחשבו על זה מהצד השני. מי שמנסה להיכנס לאתר צריך שני דברים: שם משתמש וסיסמה. אם שם המשתמש כתוב באתר בעמוד יצירת קשר – נשאר לו לנחש רק דבר אחד.
וזה לא נשאר תיאורטי. מהרגע ששם המשתמש חשוף, בוטים אוטומטיים מתחילים לעבוד עליו – ניסיונות כניסה חוזרים, ובמקביל בקשות איפוס סיסמה שוב ושוב. דני מקבל מיילים של "בקשה לאיפוס סיסמה" שהוא לא ביקש, האתר מתחיל להיטען לאט מרוב הבקשות, והשרת נכנס לעומס.
ואפילו אם אף אחד לא הצליח להיכנס בסוף – הנזק כבר קרה. אתר איטי, שרת עמוס, ותיבת מייל מוצפת.
מה לעשות:
- שם משתמש שאינו המייל שלכם ואינו השם הפרטי שלכם
- לא
admin, לאadministrator, לא שם האתר - משהו שאף אחד לא ינחש – שילוב אותיות ומספרים שאין לו שום קשר לעסק
- מייל לכניסה שונה מהמייל הפומבי באתר
ואם כבר יש לכם שם משתמש חשוף – אפשר ליצור משתמש מנהל חדש, להעביר אליו את כל התכנים, ולמחוק את הישן.
2. כל מה שרץ בדפדפן – חשוף
זה הטיפ שהכי מפתיע אנשים.
כל דפדפן מודרני כולל כלי מפתחים מובנים. לוחצים F12 ורואים את כל הקוד שרץ בצד הלקוח: HTML, JavaScript, שדות מוסתרים, ובקשות רשת.
מה זה אומר בפועל? כל דבר שהאתר "מסתיר" בצד הדפדפן – לא באמת מוסתר.
- שדה טופס מוסתר עם מחיר – נראה
- רשימת קופונים שנטענת לדף – נראית
- בדיקת תקינות שרצה ב-JavaScript – ניתנת לעקיפה
- מפתח API שהוטמע בקוד הדף – חשוף לחלוטין
ראיתי חנויות שבהן קוד ההנחה נבדק רק בצד הלקוח. ראיתי טפסים ששולחים מחיר משדה מוסתר, במקום למשוך אותו מהמסד. ראיתי מפתחות API של שירותים חיצוניים יושבים בקוד הדף.
כלל הזהב באבטחת אתרים הוא שאין לסמוך על שום נתון שמגיע מהדפדפן – כל בדיקה קריטית חייבת להתבצע שוב בצד השרת, כי כל מה שרץ בצד הלקוח ניתן לצפייה ולשינוי.
מה לעשות:
- מחירים נקבעים בשרת, לא נשלחים מהטופס
- קופונים נבדקים בשרת – תוקף, הגבלות, מוצרים רלוונטיים
- בדיקות תקינות ב-JavaScript הן לנוחות המשתמש בלבד, לא לאבטחה
- מפתחות API יושבים בשרת ולא בקוד הדף
- הרשאות נבדקות בכל בקשה, לא רק בהסתרת כפתור
הכלל פשוט: אם משהו חייב להיות נכון – השרת חייב לבדוק אותו. תמיד.
3. הגבלת ניסיונות כניסה
בלי הגבלה, אפשר לנסות סיסמאות שוב ושוב. אלפי ניסיונות בשעה, אוטומטית, מבלי שאף אחד ישים לב.
עם הגבלה של חמישה ניסיונות וחסימה זמנית – אותה מתקפה הופכת ללא מעשית.
מה לעשות:
- הגבלת ניסיונות כניסה – 3 עד 5 ניסיונות, ואז חסימה זמנית
- שינוי כתובת עמוד ההתחברות מברירת המחדל
- התראה במייל על ניסיונות כניסה חוזרים
- חסימת מדינות שאין לכם בהן לקוחות, אם רלוונטי
בתוסף האבטחה שפיתחתי לאתרים שלנו, זה הרכיב הראשון שהפעלתי. הוא לבדו חוסם את רוב הרעש שמגיע מבוטים אוטומטיים.
4. אימות דו-שלבי – חמש דקות שמשנות הכל
גם אם הסיסמה שלכם דלפה – בלי הקוד מהטלפון, אף אחד לא נכנס.
זה ההגנה החזקה ביותר ביחס למאמץ. חמש דקות התקנה, ופתאום דליפת סיסמה כבר לא אומרת פריצה.
איפה להפעיל, לפי סדר חשיבות:
- המייל שלכם – כי דרכו משחזרים כל סיסמה אחרת
- ניהול האתר
- חשבון האחסון והדומיין
- מערכת הסליקה
- ה-CRM וכל מקום שמחזיק מידע של לקוחות
שימו לב לסדר. המייל ראשון, כי מי שנכנס אליו יכול לאפס את כל השאר.
5. עדכונים – הפרצה שאתם מכירים
כשמתפרסם עדכון אבטחה, מתפרסם איתו גם תיאור של הפרצה שהוא מתקן. זה אומר שמהרגע שהעדכון יצא, כל מי שרוצה יודע בדיוק מה חשוף באתרים שלא עדכנו.
אתר שלא עודכן חצי שנה הוא לא "אתר ישן". הוא אתר עם רשימת פרצות ידועה ופומבית.
מה לעשות:
- עדכוני אבטחה – אוטומטית, מיד
- עדכוני תוספים – ידנית, אחרי גיבוי
- למחוק תוספים ותבניות שלא בשימוש – גם כשהם כבויים, הקוד עדיין שם
- לא להשתמש בתוספים שלא עודכנו מעל שנה
וכלל שאני עובדת לפיו: פחות תוספים זה יותר בטוח. כל תוסף הוא קוד של מישהו אחר שרץ באתר שלכם. ולכן, כשאפשר לפתור משהו בקוד קטן ומותאם במקום בתוסף כבד – זו לא רק שאלה של מהירות.
למה זה חשוב במיוחד עכשיו
אנחנו בתקופה שבה אפשר לבנות מערכת שלמה תוך ימים בעזרת כלי AI. זה מדהים, ואני משתמשת בזה כל יום.
אבל מהירות הבנייה לא משנה את דרישות האבטחה. מערכת שנבנתה ביומיים מחזיקה בדיוק את אותו מידע רגיש כמו מערכת שנבנתה בחודשיים – פרטי לקוחות, כתובות, היסטוריית רכישות.
ההבדל הוא רק אם מישהו עצר לחשוב על זה בדרך.
מה בחלק הבא
בחלק השני נדבר על הדברים שקורים מתחת לפני השטח:
- למה טפסים הם נקודת התורפה הכי נפוצה
- איך מגנים על API ועל חיבורים בין מערכות
- מה זה SQL Injection ו-XSS, בשפה של בעל עסק
- גיבויים – איפה, כל כמה זמן, ואיך בודקים שהם באמת עובדים
- מה עושים ברגע שמגלים שנפרצתם
שאלות נפוצות
יש לי תוסף אבטחה. זה לא מספיק?
תוסף אבטחה מגן על שכבה אחת. הוא לא יעזור אם שם המשתמש שלכם הוא המייל שמופיע באתר, ולא ימנע ממישהו לשנות מחיר בשדה מוסתר. אבטחה היא שכבות, לא מוצר בודד.
האתר שלי קטן. למי אכפת ממנו?
רוב הפריצות אינן ממוקדות. סורקים אוטומטיים עוברים על אתרים ומחפשים חולשות מוכרות – בלי לבדוק מי הבעלים ומה גודל העסק. אתר קטן עם פרצה ידועה נמצא בדיוק כמו אתר גדול.
שיניתי שם משתמש. מה עכשיו?
אימות דו-שלבי, הגבלת ניסיונות כניסה, ועדכון כל התוספים. שלושת אלה יחד לוקחים פחות משעה ומכסים את רוב מה שקורה בפועל.
איך יודעים אם נפרצתי?
סימנים נפוצים: משתמשי מנהל שלא יצרתם, תוכן או קישורים שלא הוספתם, האתר נטען לאט משמעותית, התראה מגוגל בסרץ' קונסול, או קבצים חדשים בתיקיות המערכת. אם משהו מזה קורה – כדאי לבדוק מיד.
עדכון שבר לי את האתר בעבר. עדיין כדאי לעדכן?
כן, אבל עם גיבוי לפני. הסיכון בעדכון שנשבר הוא שעה של תיקון. הסיכון באי-עדכון הוא פרצה ידועה שנשארת פתוחה חודשים.
