מובאות בזה הנחיות לכתיבה נכונה של אתרים באוניברסיטה כך שיעמדו במרבית הדרישות של אבטחת מידע.
אין האמור כאן פוטר את בעלי האתר וכותביו מכל אחריות במידה והוא ייפרץ ע"י האקרים ברשת.
1) יש לבדוק את כל הנתונים המגיעים מהלקוח ליישום לפני העברתם לביצוע בתוכנית. יש לוודא שהנתונים נקיים מכל סימן או תו בלתי צפוי. יש לבצע בדיקות תקינות על כל השדות ולאמת אותם מול סוגי הנתונים המצופים מהם: נומריים או מחרוזתיים. לגבי האחרונים יש לוודא שהם נקיים מתווים 'מסוכנים'. בדיקות הנתונים אמורות למנוע SQL injection ו command injection .
2) אם יש צורך להציג למשתמש דף עם נתונים אותם הקליד בדף אחר אזי יש לוודא שנתונים אלה לא מכילים מחרוזות 'מסוכנות' כגון javascript שעלולות להתממש בעת הצגת הדף.
3) יש לוודא שה referrer תמיד נכון. אין לאפשר מניפולציה על כתובת הדף . במקרה כזה להחזיר הודעת שגיאה. בטפסים – יש לעבוד עד כמה שניתן ב post.
4) יש לתת ליישומים את ההרשאות המינימאליות להפעלת האתר. אין לתת להם זכויות שעלולות ליצור דלת אחורית לפריצה. למשל לכל אתר יש לתת שם וסיסמא לגישה לבסיס הנתונים עם הרשאות מינימאליות. אין לתת ליישומי אינטרנט הרשאות ניהול גורפות על הבסיס הנתונים. יש לתת למשל הרשאות קריאה בלבד כשאין צורך בכתיבה.
5) יש לרכז את כל סוגי הבדיקות באתר ברוטינה ייעודית אחת.
6) אין לחשוף למשתמש הודעות שגיאה אפליקטיביות העלולות להסגיר מה קורה בתוך היישום. אין לתת מידע מיותר שעלול לסכן את האתר. שגיאות כאלה יש לכתוב לקובץ לוג בלבד. הודעות השגיאה היחידות שיראה המשתמש הן כאלה הנגרמות על ידו ושהתגלו על ידי רוטינת בדיקת הנתונים מסעיף 5.
7) יש לתת שמות מסובכים, לא באנגלית אם אפשר, לקבצים של מערכת ניהול התוכן. אין להסגיר את מערכת ניהול התוכן עם שמות טריוויאליים כמו admin.php או admin.asp . אם באתר יש צורך להפעיל שם וסיסמה, לתת שמות וסיסמאות לא טריוויאליות . למשל לא לתת שמות שקשורים לשם האתר או לנושא האתר. אין להשתמש כלל בשם admin באתר. לא בשמות קבצים, לא בשמות יישומים, לא בשמות טבלאות ולא בשמות שדות. כנ"ל יש להימנע מהשם id או idnumber וכו'.
8) אם קיים באתר ממשק ניהול – יש להפרידו לגמרי מחלק האתר המוצג לגולשים.
9) יש לוודא שגרסאות ישנות של האתר ועתקי גיבוי למיניהם, הנמצאים יחד עם האתר הפעיל או צמודים אליו, לא יהיו נגישים. שאריות פיתוח של האתר חייבות להיות חסומות. מומלץ למחוק אותן (אם ניתן) או לחסום גישה אליהן. בעת שמירת עותק גיבוי של קוד העובר עיבוד בצד השרת (כמו php, aspx) יש לשמור על הסיומת - למשל לקרוא לגיבוי index_sav.php ולא index.php.sav. שאריות כאלו מהוות חולשה באבטחת המידע של האתר כולו בגלל שהן מאפשרות לתוקף גישה לקוד מקור.
10) יש להגן על טפסים פתוחים לקהל הרחב שנתוניהם נכתבים בבסיס נתונים או נשלחים בדוא"ל ע"י CAPTCHA על מנת למנוע התקפות של רובוטים על הטפסים האלו. התקפות כאלו עלולות להציף בזבל את הבסיס נתונים או את תיבה דוא"ל יעד במקרה של טופס תגובות.
11) על התשתית בה רץ האתר להיות עדכנית. הדבר נוגע למערכת הפעלה, שפת תכנות, שימוש במסד נתונים ועוד. שימוש בתשתית מיושנת מעלה משמעותית את הסיכון לפרצות אבטחה ללא אפשרות תיקון. לדוגמה - אין לבנות אתרים חדשים ב ASP ישן אלא רק ב ASP.NET, גרסת PHP עדכנית, אין להשתמש בשום פנים באופן בגרסאות ישנות כגון 3 או 4.
12) עדכוני אבטחה - בעת מסירת האתר מהמפתחים למנהל השרת יוגדר נוהל התקנת עדכוני אבטחה באתר. בנוהל יוגדרו האחראים לביצוע העדכונים ברמת מערכת הפעלה (למשל חלונות, לינוקס), שרת ווב (למשל Apache, IIS), מודולים מצד שלישי בהם האתר תלוי (למשל Perl modules,ASPupload, ImageMagick), אפליקציות המפעילות את האתר (למשל מערכת ניהול תוכן, מערכת פורומים, wiki, ניהול בלוג) ויישומי תשתית הדרושים לפעילות האתר (למשל SQL). עדכוני האבטחה יותקנו בהקדם האפשרי לאחר ההכרזה על קיומם מצד מפתחי היישום (למשל, אם מדובר בחלונות - הכרזה על עדכוני אבטחה ממיקרוסופט).
13) גיבוי האתר - בעת מסירת האתר מהמפתחים למנהל השרת יוגדר נוהל גיבוי של תשתית האתר ותוכנו בו יוגדר כיצד מתבצע הגיבוי וכיצד מתבצע השחזור לשרת אחר (חשוב להגדיר בנוהל זה כיצד להתקין מודולים מצד שלישי).
14) במידה ויש באתר דפים המוגנים בסיסמה יישמרו הסיסמאות בהצפנה חד כיוונית חזקה (למשל SHA1). מומלץ להשתמש בהצפנה חזקה יותר (למשל SHA256). פעולת ההצפנה צריכה להתבצע בצד השרת ולא בצד הלקוח.
לקריאה נוספת:
Top 25 Software Errors
http://www.owasp.org/index.php/Secure_Coding_Principles
http://www.owasp.org/index.php/About_The_Open_Web_Application_Security_Project
תשלומים באתר האוניברסיטה ע"י כרטיסי אשראי (מערכות סליקה ברשת)
כל אתר באוניברסיטה שמפעיל מערכת סליקה ברשת חייב לעמוד בסטנדרט PCI DSS וזאת על מנת למנוע חשיפה של האתר לפגיעות זדוניות, תביעות נזיקין מצד חברות האשראי ו/או מצד לקוחות נפגעים.
בנוסף, על האתר לעמוד בתנאים הבאים:
1) לא לשמור בשום מקום את נתוני כרטיסי האשראי של המשתמשים. יש להעביר את הפרטים לחברת הסליקה ולא להשאיר עקבות נתונים בשרת הווב. יש לדאוג שבקבצי הלוג של השרת לא נכתבים פרטי הכרטיס ברשומת הטרנזקציה.
2) יש לשים CAPTCHA בטפסי ביצוע התשלום כדי למנוע מתקפות רובוטים על מערכת הסליקה. מתקפות כאלו מאפשרות לתוקפים לנחש את מספרי כרטיסי האשראי.
3) יש לשים בדיקה של הסכום הנגבה - כדי למנוע פעולות של סכומים לא הגיוניים כמו $1 או $100000 לדוגמא. סכומים חריגים קשורים לרוב להונאות עם כרטיסים גנובים.
לקריאה נוספת על סטנדרט PCI DSS והגנת תשלומים בווב :