נגמרו הנקיונות, ואף חג הפסח חלף עבר לו. רציתי לשוב עם פוסט מעניין במיוחד, כזה שיפצה על שבועיים של יובש, אבל הנושא שלו אני רוצה להקדיש את הפוסט הזה אינו נחשב נושא מעניין כלל: בניית אתר מאובטח.
אני מתחילה לפהק רק מהמחשבה על הפיהוקים שהנושא הזה מעורר אצלכם, אבל האמת היא שגיליתי שזה בכלל לא משעמם, ולכן אסתכן בשיתופכם בכמה מאמרים שקראתי לאחרונה.
המאמר הראשון הוא זה שהתחיל לעורר את התעניינותי בנושא של אבטוח אתר, והוא מדרג את סוגי הפרצות לאתרים לפי הנפיצות שלהם. המאמר מתחיל במשפט מבהיל: ל-9 מתוך כל 10 אתרים יש פרצות (vulnerabilities) שדרכן ניתן לפרוץ לאתר, כאשר הממוצע הוא 7 פרצות לאתר (כלומר, 7 חורים דרכם יכולים האנשים הרעים להגיע למידע רגיש).
במקום הראשון, הפרצה הנפוצה ביותר היא Cross Site scripting – XSS, המופיע בכ-70% מהאתרים. XSS קורה כשהאתר אוסף מידע מהמשתמש, והמידע מכיל תוכן זדוני (כמו למשל scriptים למיניהם). דוגמה: משתתף פורום כותב script בתוך הודעה בפורום. כאשר יעלה הפורום עם ההודעה שכתב גולש זה, הדפדפן יריץ את ה-script…
הפרצה הבאה בתור בנפיצותה היא דליפת מידע , והיא מתרחשת ב-2 מתוך 5 אתרים. דליפת מידע מתרחשת כאשר האתר – במודע או שלא במודע – חושף מידע רגיש כמו למשל: הערות בקוד, מידע על משתמש, כתובות IP פנימיות, קוד מקור.
הפרצה שנמצאת במקום השלשי היא content spoofing – הונאת תוכן, טכניקה נפוצה במזימות phishing. היא גורמת לגולש להגיע לתוכן שדומה לתוכן באתר הלגיטימי, אך למעשה מגיע מאתר בלתי לגיטימי וזדוני. ההונאה הזו יכולה להתבצע באמצעות דואל (למשל: דואל המבקש לאפס סיסמה באתר שלגולש יש בו חשבון. במקרה של הונאה, הקישור אינו מוביל לאתר הנכון, אלא לאתר הדומה לו אך נמצא בכתובת אחרת וכל מטרתו היא לגנוב את סיסמתו של המשתמש).
במקומות הרביעי והחמישי נמצאים בהתאמה – אי מחיקה של דפי אינטרנט ישנים העלולים להכיל מידע רגיש, ו-SQL injection – שיטה להחדרת פקודות SQL ל-DB, פקודות שנועדו למחוק מידע או לגנוב זהות.
שני המאמרים הבאים שקראתי נועדו למפתחים, והם מכילים הדרכות להתגוננות מפני כוחות האופל:
למאמר הראשון יש כותרת שמשרה בטחון: אפליקציות אינטרנט הן סוסים טרוייאנים להאקרים. איך אפשר להרדם בלילה אחרי כותרת כזאת?! מכל מקום, המאמר הזה מפרט סוגי פרצות באתרים, לא לפי סדר חשיבות מסויים. כמובן שישנה חפיפה מסויימת עם המאמר הקודם, אך הנה מספר חידושים:
שדות חבויים (hidden fields). מתכנתים רבים סבורים כי בגלל שמם (hidden), השדות הללו אינם גלויים ולכן ניתן לשמור בהם מידע רגיש. כמובן, כל מי שאי פעם עשה view source לדף עם שדות חבויים יודע כי הם גלויים לעיני כל מתבונן, ולכן יש להזהר מאד בשימוש בהם כמאחסני מידע.
הרעלת עוגיות. לפעמים אתרים משתמשים בעוגיות הנשתלות אצל הגולש, ושומרים בהם מידע כגון שם משתמש, סיסמה, מספר חשבון וכד’. יש לדעת להזהר מגולשים זדוניים העלולים לשנות את המידע המאוחסן בעוגיות ובכך לגשת למידע לא-להם.
אז מה צריך לעשות כדי להגן על האתר? המאמר הבא מלמד את המתכנתים כמה וכמה כללים:
1) להיות חשדניים כלפי כל מידע המגיע מהגולש. עליהם לסמוך רק על מידע שהם שולטים בו, ומכיון שהם אינם שולטים במידע המגיע מהגולש, עליהם להתייחס לכל קלט כפוטנציאל לזדון ולכן לבדוק (באמצעות ולידטורים או באמצעים אחרים) כל קלט המגיע לאפליקציה.
2) אם האפליקציה דורשת זיהוי משתמשים, יש לכתוב את הקוד לזיהוי המשתמשים מיד בהתחלה ולדבג אותו, ולא להשאיר זאת לסוף. במסגרת כלל זה כדאי גם להזכיר שיש תמיד לתת את ההרשאה הנמוכה ביותר האפשרית לכל תפקיד, כדי למנוע אפשרות שלמשתמשים לא מורשים יהיו מסוגלים לבצע מניפולציות מסוכנות על המידע.
3) להשתדל להשתמש ב-POST במקום ב-GET.
4) דפי ASP לעתים קרובות מכילים כתובות גישה ל-DB. אמנם הקוד של דף ASP הופך להיות HTML רגיל וזה גורם למתכנתים להיות בטוחים שמה שכתוב בקוד אינו גלוי לגולש, אך ישנן לא מעט דרכים להגיע לקוד המקור של דף ASP, ולכן כדאי להזהר.
לסיכום, קצת מפחיד לגלות באיזו קלות יכולים אנשים רעים להגיע למידע, אך בו בזמן נראה כי אם מפעילים מספר תהלכי עבודה פשוטים בזמן הפיתוח ניתן לספק הגנה די טובה לאתרינו וליישומינו.
מעניין אותי
מה מתוך זה מיושם בכליקיט.. מצד שני אולי אני האקר 😉
פוסט מעניין, מצפה לעוד כאלה
מסיבות מובנות, לא התייחסתי לכליקיט בפוסט הזה 🙂