אז איך לכם לא יפרצו?
מדריך קצר שיעזור לכם לשמור על השירות והמוצר שלכם מוגנים בפני פריצות. איך עושים זאת נכון מהרמה הארגונית ועד לרמה הטכנית?
הפוסט נכתב על ידי אוהד רבינוביץ’, ראש צוות QA בחברת Checkmarx.
האירועים האחרונים בתחום אבטחת המידע אשר פורסמו בהרחבה בתקשורת הכללית, עם דוגמאות כמו ההאקר הסעודי, שיתוק השרתים של סוני או לחליפין, הקמת המאגר הביומטרי, מעלות תהיות בקרב הציבור הרחב בנוגע לאופן ההגנה על המידע.
וכך, על כתפיהם הצרות של חברי צוות אבטחת האיכות נוספה בימינו משימה חדשה – אבטחת מידע. אין מדובר באבטחת המידע של חברת הפיתוח, משימה המוטלת לרוב על אנשי ה-IT, כי אם וידוא שהמוצר או השירות עליו אנחנו אמונים יהיה מוצר בטוח בפני התקפות.
מה זו בעצם פירצת אבטחה?
אולי הדרך הטובה ביותר להסביר אך פורצים לאתר היא פשוט להדגים פריצה נפוצה בשם SQL Injection.
אז ככה, בואו נמציא לנו אתר…
זה כמובן אתר פשוט מאוד, יש לנו שדה טקסט אחד וכפתור. לחיצה על הכפתור תבדוק האם שם הספר בשדה הטקסט קיים במאגר הנתונים ואם כן תדפיס את שם המחבר. כתיבה לא נכונה של הקוד באתר כזה תאפשר להאקר מתחיל גישה לכל מאגר הנתונים שלנו, ואפילו להפיל את האתר ואת המכונה הפיזית.
איך הוא עושה את זה?
בוא נכניס לשדה בטקסט את הסימן ‘ ונלחץ על הכפתור – נגיע לעמוד שגיאה:
למה? כי אתר זה כתוב גרוע והסימן ‘ שובר את השאילתה שבעזרתה ניגשים למאגר הנתונים, מספר משחקים של ניסוי וטעיה יובילו את ההאקר שלנו למחרוזת הזו “union select password from users;– ‘ “, הוא ינסה אותה באתר.
והינה הסיסמאות של המשתמשים באתר חשופות.
זוהי כמובן פירצה אחת מתוך אלפי פרצות מוכרות היום.
מוטיבציה
בין אם מדובר ברגולציה ובין אם בדרישות של לקוחות רגישים, הדרישה למוצר בטוח בדרך כלל מגיעה מבחוץ. זליגת מידע מהמוצר שלנו או שימוש במוצר שלנו בכדי לחדור לשרתי לקוח יכולים לגרום לנזקים עצומים לחברה. לכן, חברות רבות נדרשות היום לספק מוצר שאינו רק איכותי (יעיל ונוח), אלא גם בטוח. בדרך כלל נידרש לעמוד בתקנים מסוימים (לדוגמה OWASP top 10 או PCI) ובסטנדרטים המוגדרים חדשות לבקרים בתעשייה. במיוחד בעולם הנע אל הענן ומספק Web Interfaces הדגש הופך חד יותר, אבל גם תוכנות “מסורתיות” הנן פגיעות ודורשות הגנה.
האחריות על צוות הבדיקות (או צוות ה-QA)
ברוב בתי התוכנה צוות אבטחת מידע, אם קיים, איננו גדול. באופן מסורתי, האחריות נפלה על המהנדס הראשי או אחד מראשי צוות הפיתוח והם, מלבד ניהול כללי, לא יכלו להיכנס לפרטים. ניסיונות להעביר את האחריות למפתחים לימדו כי יש צורך בפיקוח על עשייתם. צוות הבדיקות מיומן בדיוק לזה. מה גם שהניסיונות להעביר את האחריות למפתחים אינה בת ביצוע שכן גם המתכנתים המוכשרים ביותר, אינם יכולים להיות מעודכנים לגבי מאות סוגי הפרצות שיכולות להיות בקוד, ומספיק מתכנת אחד שעושה טעות אחת, בשביל לסכן את הכל.
אז מה עושים בתכל’ס:
1. אבטחה כדרישה: בשלב הראשון, נגדיר את הדרישה להיות מוצר מאובטח כחלק מדרישות המוצר. התוצאה המיידית היא פשוטה: פרצה = באג ! ובאגים צוות הבדיקות צריך למצוא.
2. הכשרה: מניסיוני, צוותי הבדיקות היום אינם מכירים כלל את נושא האבטחה וכדאי מאוד להתחיל את התהליך בהכשרה קצרה. תהליך הכשרה ארוך ויקר בדרך כלל יוביל לבזבוז ושעמום. אני ממליץ על הרצאה או שתיים המתמקדות בהדגמות של פרצות נפוצות (SQL Injection, XSS ),שימוש בכלים ולימוד עצמי בהמשך.
3. אז איך מוצאים? צוות הבדיקות הקיים, מקצועי ככול שיהיה, כנראה שאינו מומחה באבטחה וללא שימוש בכלים יתכן שיהיה זקוק לעזרה. כמו כל באג רגיל יש דרכים שונות ומשונות לאתר פרצות אבטחה. לשמחתי יש היום כלים רבים בשוק שיכולים לעזור.
יש לזכור שעדיין הכול מתרכז סביב תהליך נכון, וכמו כל תהליך יש להגדיר שלבים וכלים מתאימים. סדר היום של בודק אבטחה הופך לפשוט ומובנה:
1. באים בבוקר ובודקים את התוצאות של ריצת הלילה של הכלי.
2. האם יש בעיות חדשות? אם כן קוראים עליהן בתעוד המצורף לכלי או אפילו באינטרנט.
3. אם יש גישה של הבודק לקוד הוא יכול לבדוק האם הבעיה אמיתית \ רלונטית? כלומר האם המסלול המתואר במימצא של התוכנה באמת משקף פריצה.
4. פתיחה של באג במערכת ניהול באגים.
פתרונות
יש גישות שונות בעניין סוגי הבדיקות המומלצות. פתרונות שונים מתאימים לשיטות שונות. הפתרונות הנפוצים היום בשוק מתחלקים לשלוש קבוצות:
1. Code review – הזמנה של חברה חיצונית לביצוע של בדיקה ידנית של הקוד.
2. Automatic Penetration Test – כלי התוקף את האפליקציה במגוון התקפות ומנסה לאתר פגיעויות.
3. Static Code Analysis – כלי הסורק את קוד המקור של הפרויקט ומוצא חשיפות פוטנציאליות בקוד.
לחצו להגדלה
Life Cycle
שילוב בדיקות האבטחה ב-Life Cycle של המוצר כדאי בדיוק מאותן סיבות של כל בדיקה אחרת. איתור מוקדם של בעיות כלכלי יותר מאשר מציאתן בשלב מאוחר. בחברות שונות ובתהליכים שונים יתכן ויהיה צורך בהתאמה, אבל הבסיס שאני ממליץ עליו נחלק לשלושה חלקים:
תכנון: כבר בשלב תכנון הפרויקט או הרכיב יש להתייחס לאבטחה, בהתחלה (עד שצוות הבדיקות יכיר את הנושא), מומחה האבטחה או המהנדס הראשי יתנו את הדגשים.
שיגרת הפיתוח: בשלב זה אני ממליץ על שילוב של כלי אוטומטי לביצוע בדיקות האבטחה (static code analysis). כלי כזה יוכל להצביע על פרצות אבטחה ולכוון צוות לא מיומן לבעיות.
- הרצה של הסריקה באופן אוטומטי אחרי ה-Build הלילי תבטיח מציאה מוקדמת של בעיות ומעקב טוב אחרי התיקונים.
- הצוות יעבור על דו”ח התוצאות של הסריקה, ילמד את התוצאות ויפתח באגים, ובדרך ילמד על רמות הפגיעות השונות.
- מומלץ לבחור כלי שאיננו דורש קוד מקומפל (מהודר) וקל להבנה ולתפעול.
לפני שחרור: בשלב זה אני ממליץ לצוות חדש להזמין סריקה חיצונית של הקוד (Pen testing). אם הצוות עשה עבודה טובה החברה החיצונית רק תאשר שהמוצר בטוח ולא ייווצר עיכוב בתאריך המסירה.
בחירת כלים
בחירת כלי נכון חשובה יותר מתמיד, במקרה זה אנחנו סומכים על הכלי שישלים גם את פער הידע החסר בצוות. יש לשים לב למספר דגשים בבחירת הכלי:
הטמעה פשוטה – כמו בכל כלי חדש, דרישות גדולות ארוכות ומורכבות של הכלי, יובילו לתסכול ונטישה מהירה. האם הכלי דורש קוד מקומפל? האם הכלי דורש התאמות מורכבות? כמה קשה לבצע התאמות?
תוצאות מובנות – בקשו מאיש המכירות להציג לפניכם דו”ח לדוגמה. מה הכלים שבהם הכלי מציג בהם את התשובות? האם הן מובנות לכם? האם יש בו מספיק מידע?
התאמה לטכנולוגיות – כנסו לפרטים בעניין ההתאמה, האם הכלי תומך בשפת הפיתוח הרלבנטית? האם הכלי תומך ב-Framework שבשימוש? ב-Databases?
סביבת פיתוח – האם הכלי מתממשק לסביבות הפיתוח בחברה? לכלי ניהול הקוד (TFS, SVN)? לכלים של המתכנתים (Eclipse, Visual studio)?
בעבודה ב-Water fall יש לשים דגש על כמות נמוכה של תוצאות שווא. בכלים מסויימים סריקה של פרויקט גדול עלולה להחזיר אלפי תוצאות שוא, בדרך כלל ב-Water fall אין זמן להאריך את תקופת הבדיקות באופן ניכר על מנת ללמוד את כל התשובות.
בעבודה ב-Agile יש לשים דגש על קלות העבודה. לא כל אנשי הבדיקות יהיו מיומנים מיד וב-Agile העצמאות של איש בדיקות בודד חשובה.
תמיכה – יצרן הכלי הוא בדרך כלל מקור טוב לידע והדרכות. האם העסקה כוללת מעבר משותף על תוצאות והכוונה במקרה הצורך?
סיכום
בעזרת כלים פשוטים יכול גם צוות לא מיומן להשיג תוצאות טובות מאוד ושמירה על מוצר מאובטח. טלפון קצר לאחת מיצרניות הכלים או חברות הייעוץ יפתח לפניכם עולם שלם של יכולות חדשות.
קרדיט תמונה: Shutterstock.
כתב אורח
אנחנו מארחים מפעם לפעם כותבים טכנולוגים אורחים, המפרסמים כתבות בתחומי התמחות שלהם. במידה ואתם מעוניינים לפרסם פוסט בשמכם, פנו אלינו באמצעות טופס יצירת קשר באתר.
הגב
11 תגובות על "אז איך לכם לא יפרצו?"
* היי, אנחנו אוהבים תגובות!
תיקונים, תגובות קוטלות וכמובן תגובות מפרגנות - בכיף.
חופש הביטוי הוא ערך עליון, אבל לא נוכל להשלים עם תגובות שכוללות הסתה, הוצאת דיבה, תגובות שכוללות מידע המפר את תנאי השימוש של Geektime, תגובות שחורגות מהטעם הטוב ותגובות שהן בניגוד לדין. תגובות כאלו יימחקו מייד.
כל זה טוב ויפה לחברות שמפתחות כלים או תוכנות כבדות.
מה לגבי מישהו שבונה אתר? כמו בדוגמא המפורטת לעיל.
איך נמנעים מSQL Injection ועוד רעות חולות?
בתודה
1. בוחרים בונה אתרים טוב או מתכנת טוב לבניית האפליקציה שלך. לא הילד של השכן.
2. חותמים על חוזה תחזוקה טוב עם בונה האתרים או המתכנת ומבינים שאתר צריך תמיכה, עדכון ושדרוג מעת לעת וזה עולה כסף.
3. דואגים לשדרוג ועדכון המערכת.
4. מאחסנים באחסון אתרים נורמלי.
5. מגבים וממשיכים לתחזק את הגיבוי.
משתמשים ב framework כמו Django או Rails עם ORM שמגן עליך ולא כותבים שאילתות SQL בתוך הקוד של הדפים.
אני משתמש בשירות בדיקת פרצות חינמי בשם scanmyserver:
http://www.scanmyserver.com
יעיל מאוד במציאת SQLI ופרצות אחרות, והמחיר (חינם) בהחלט אטרקטיבי…
והכי הכי חשוב.. לא משתמשים באקספלורר
והנה התגובה הפרסומית שחיכינו לה עוד מקריאת הכתבה.
נ.ב. האתר שלכם למטה … מביך
מרשים שהצלחת לכתוב תגובה בזמן שהאתר למטה…
Security by design
שלב הבדיקות הטוב ויפה לסגירת פרצות קטנות של אבטחה.
פעמים רבות אנחנו נתקלים במוצר או אתר שלא תוכנן כלל כדי לתת מענה להבטי אבטחת מידע.
לעלות על זה בשלב ה QA פשוט מאוחר מידי ולא מאפשר התמודדות אמיתית.
אבטחת מידע היא צורך עסקי שצריך להתיחס אליך כבר מהרגע הראשון.
דרך ממש טובה להגן על המוצרים שלכם היא לדעת איך פורצים מוצרים לחסום את האפשרות הזו.
יש אתר שמאפשר אתגרים “לפרוץ” אליו (משימות מוכוונות באתר):
http://hackthissite.org/
צר לי לומר שהרמה שם די בסיסית (פענוח ססמאות מוצפנות ברמה נמוכה ופרצות אבטחה די אלמנטריות) אבל רוב האתרים שאני מכיר גם לא מאובטחים ברמה הבסיסית הזו.
שווה הצצה, עוזר לעבור על כל הפריצות הבסיסיות האפשריות למוצר שלכם.
כמי שנמצא בשלב פיתוח אפליקציה , באמצעות חברה מקצועית
כיזם – מה עלי לדרוש כדי לקבל אבטחת מידע לאתר המקצועית והאפשרית ביותר
ולייצור הגנה מקסימלית מבחינה מקצועית לאתר ולמידע בשרת
והאם ניתן היום להצביע על חומת הגנה מקסימלית
ואני מדבר על רכישת תוכנה או בניית חומה מקצועית שתגן על נתונים
שיצטברו באתר ובשרתים
אשמח לקבל דעה, עצה , הכוונה
תודה