אז איך לכם לא יפרצו?

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

תמונה: Shutterstock

הפוסט נכתב על ידי אוהד רבינוביץ’, ראש צוות QA בחברת Checkmarx.

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

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

מה זו בעצם פירצת אבטחה?

אולי הדרך הטובה ביותר להסביר אך פורצים לאתר היא פשוט להדגים פריצה נפוצה בשם SQL Injection.

אז ככה, בואו נמציא לנו אתר…

pic1

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

איך הוא עושה את זה?

בוא נכניס לשדה בטקסט את הסימן ‘ ונלחץ על הכפתור – נגיע לעמוד שגיאה:

pic2

למה? כי אתר זה כתוב גרוע והסימן ‘ שובר את השאילתה שבעזרתה ניגשים למאגר הנתונים, מספר משחקים של ניסוי וטעיה יובילו את ההאקר שלנו למחרוזת הזו “union select password from users;– ‘ “, הוא ינסה אותה באתר.

pic1

והינה הסיסמאות של המשתמשים באתר חשופות.

זוהי כמובן פירצה אחת מתוך אלפי פרצות מוכרות היום.

מוטיבציה

בין אם מדובר ברגולציה ובין אם בדרישות של לקוחות רגישים, הדרישה למוצר בטוח בדרך כלל מגיעה מבחוץ. זליגת מידע מהמוצר שלנו או שימוש במוצר שלנו בכדי לחדור לשרתי לקוח יכולים לגרום לנזקים עצומים לחברה. לכן, חברות רבות נדרשות היום לספק מוצר שאינו רק איכותי (יעיל ונוח), אלא גם בטוח. בדרך כלל נידרש לעמוד בתקנים מסוימים (לדוגמה 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.

Avatar

כתב אורח

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

הגב

11 תגובות על "אז איך לכם לא יפרצו?"

avatar
Photo and Image Files
 
 
 
Audio and Video Files
 
 
 
Other File Types
 
 
 

* היי, אנחנו אוהבים תגובות!
תיקונים, תגובות קוטלות וכמובן תגובות מפרגנות - בכיף.
חופש הביטוי הוא ערך עליון, אבל לא נוכל להשלים עם תגובות שכוללות הסתה, הוצאת דיבה, תגובות שכוללות מידע המפר את תנאי השימוש של Geektime, תגובות שחורגות מהטעם הטוב ותגובות שהן בניגוד לדין. תגובות כאלו יימחקו מייד.

סידור לפי:   חדש | ישן | הכי מדורגים
שומבצל
Guest

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

בתודה

רן בר-זיק
Guest

1. בוחרים בונה אתרים טוב או מתכנת טוב לבניית האפליקציה שלך. לא הילד של השכן.
2. חותמים על חוזה תחזוקה טוב עם בונה האתרים או המתכנת ומבינים שאתר צריך תמיכה, עדכון ושדרוג מעת לעת וזה עולה כסף.
3. דואגים לשדרוג ועדכון המערכת.
4. מאחסנים באחסון אתרים נורמלי.
5. מגבים וממשיכים לתחזק את הגיבוי.

תחכמוני
Guest

משתמשים ב framework כמו Django או Rails עם ORM שמגן עליך ולא כותבים שאילתות SQL בתוך הקוד של הדפים.

חיים
Guest

אני משתמש בשירות בדיקת פרצות חינמי בשם scanmyserver:
http://www.scanmyserver.com

יעיל מאוד במציאת SQLI ופרצות אחרות, והמחיר (חינם) בהחלט אטרקטיבי…

אפי
Guest

והכי הכי חשוב.. לא משתמשים באקספלורר

הלן בראבו
Guest
לגבי פתרונות לגילוי פגיעויות של SQL Injection, קיימים הרבה כלים חינמיים המספקים פתרונות חלקיים ברמות איכות שונות כגון תמיכה מוגבלת בשפות פיתוח או בגילוי פגיעויות. לדוגמא: כלי בשם Brakeman אשר מיועד רק ל- Ruby ונחשב ככלי חזק וכדומה. מעבר לכך, ישנן חברות המייצרות מוצרים המיועדים לחברות גדולות אשר גם מספקות פתרון בר השגה לבוני אתרים וחברות קטנות. חברת Checkmarx הינה אחת מהן והיא מספקת גם פתרון SaaS לקהל זה. לגבי התגובה אודות בחירה לפנות לחברה לפיתוח תוכנה במקום הבן של השכן, ישנן חברות גדולות ומומחיות בפיתוח שלאו דווקא שמות דגש על אבטחת מידע לכן לא הייתי בונה על זה. הלן… Read more »
ירון
Guest

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

נ.ב. האתר שלכם למטה … מביך

דניאל
Guest

מרשים שהצלחת לכתוב תגובה בזמן שהאתר למטה…

רם
Guest

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

I-Care
Guest

דרך ממש טובה להגן על המוצרים שלכם היא לדעת איך פורצים מוצרים לחסום את האפשרות הזו.
יש אתר שמאפשר אתגרים “לפרוץ” אליו (משימות מוכוונות באתר):
http://hackthissite.org/
צר לי לומר שהרמה שם די בסיסית (פענוח ססמאות מוצפנות ברמה נמוכה ופרצות אבטחה די אלמנטריות) אבל רוב האתרים שאני מכיר גם לא מאובטחים ברמה הבסיסית הזו.
שווה הצצה, עוזר לעבור על כל הפריצות הבסיסיות האפשריות למוצר שלכם.

Elie Sahar
Member

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

wpDiscuz

תגיות לכתבה: