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

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

1. שמרו על צד השרת

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

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

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

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

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

2. שמרו על הלקוחות שלכם

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

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

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

3. שדרגו לעתים קרובות

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

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

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

4. דאגו לזמינות גבוהה באמצעות יתירות

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

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

5. התכוננו לגרוע מכל

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

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

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