אב

הוראות בטיחות לפיתוח קיץ

היום אני מאד גאה לארח בבלוג שלי את אבי דוגלן, יועץ אבטחת מידע אפליקטיבי ותיק ומנוסה (וגם בעלה של חברה שלי… ). את המוניטין הבינלאומי שלו אפשר לראות בפרופיל שלו באתרsecurity.se שהוא נמנה בין ה-moderator-ים שלו.

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

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

 

גם מתכנתים נוהגים למצוא את עצמם על ענף גבוה, ללא דרך ירידה חוץ משימוש בכוח המשיכה. רובנו גם לא אוהבים לקרוא מגילות ארוכות… מה שמייצר בעייתיות מסוימת – כמו שאומרים, ההאקרים ממשיכים לקרוא את המדריך משתמש עוד כמה דפים אחרי המקום שהמפתחים מפסיקים….

 

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

 

בטיחות? אבטחת מידע? אבל בשביל מה, הרי יש לנו פיירוול…?

 

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

אבל רק שתדעו, בימינו רוב ההתקפות (למעלה מ-80%, על פי חלק מהסקרים) מתבצעות בשכבת האפליקציה, ולא ברמת מערכת ההפעלה, התקשורת, או כל שכבה אחרת. סתם, שתדעו.

 

חובה להתקין (וגם להשתמש)

 

דבר ראשון שכל מתכנת מערכות Web צריך לעשות – זה להתקין כלי פרוקסי (proxy). אני מניח שמי שקורא את הבלוג הזה, כבר משתמש בכלי כזה. נכון? מה לא? טוב, מי שאין לו פרוקסי מותקן על המחשב, שיתקין מהר לפני שמישהו אחר מגלה. נו נו, עכשיו. כולנו מחכים. באותה הזדמנות, אני מציע לכל אחד ואחת לעדכן את רשימת הכלים שצריך למחשב חדש… 😉

למי שבכל זאת לא מכיר, אני לא מתכוון לאותו שרת ארגוני שמאפשר גישה לאינטרנט, תוך כדי שעושה סינון לחומרים מסוכנים והזויים – אלא לתוכנה שמותקנת על תחנת העבודה של המפתח, ותופסת את כל תעבורת ה-Web. זה מאפשר לך לראות מה באמת מועבר ברשת הפתוחה, ואיך משתמש רגיל יוכל להשתמש ב-API של המערכת שלך. (כן, לכל מערכת Web יש API. לא מאמין? תפתח פרוקסי ותסתכל.)

אישית אני אוהב את Fiddler – כלי חינמי שפותח על ידי אחד המהנדסים המובילים של מיקרוסופט, ויש לו הרבה פלאגאינים מעניינים – אבל כאלה יש עוד רבים, כמו למשל Burp Proxy הידוע, או ZAP של OWASP.

כלים כאלה פתאום פותחים לך את העיניים, למי שעוד לא הכיר, איך באמת עובד פרוטוקול HTTP בפועל. (דוגמה אהובה – איך עובד מנגנון הזדהות מבוסס HTTP Basic Authentication? מי שיודע מבלי לבדוק מקבל 2 נקודות. מי שהשתמש אי פעם ב-Basic Authentication ולא יודע – מינוס אלף נקודות).

 

הכלי גם מאפשר לך לשנות את הערכים הנשלחים (למשל ב-FORM שנשלח ב-POST) תוך כדי שליחה, ולבדוק את המערכת גם בערכים שלא אמורים להישלח באופן עבודה תקני.

כמו, למשל, מה היה קורה אילו משתמש זדוני רוצה לעקוף את הבדיקות שביצעת ב-JavaScript….

 

כל מה שרצית לדעת על מה שיעשו לכם (ולא חשבתם לשאול)

 

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

 

ארגון OWASP מוציא כל כמה שנים – מה, איך לא מכירים את OWASP?? הארגון הזה – Open Web & Application Security Project – מורכב ממתנדבים בכל העולם, עם התמחות באבטחת מידע אפליקטיבית, למערכות Web, Mobile, ולא רק. המטרה שלהם היא לשפר את רמת האבטחה של כל המערכות המפותחות, על ידי שיתוף מידע, בניית כלים, פיתוח ספריות, ועוד.

אחד התוצרים העיקריים שלהם זה רשימת ה- OWASP Top Ten – עשרת החשיפות הנפוצות ביותר, ברמת האפליקציה, בכל העולם. הרשימה נחשבת לסטנדרט de facto, וסטנדרטים גדולים מסתמכים עליו – כגון PCI-DSS, תקן אבטחת מידע של חברות כרטיסי האשראי.

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

אז הנה לכם הרשימה, בקצרה (לכל מי שלא מכיר, מאוד מומלץ לקרוא עוד על כל אחד מהנושאים באתר OWASP):

 

  1. הזרקת קוד זדוני (Injection)

כגון SQL Injection, או LDAP Injection, או OS Command Injection, וכדומה… מתרחשות כאשר מידע לא מאומת נשלח לרכיב התרגום כחלק מפקודה / שאילתה. המידע העוין של התוקף עלול להטעות את רכיב התרגום ולהפעיל פקודות לא רצויות או לחילופין לאפשר גישה למידע לא מורשה.

 

  1. Cross-Site Scripting / XSS

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

 

  1. הזדהות שבורה ומנגנון ניהול שיחה

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

 

  1. אזכור ישיר לרכיב לא מאובטח

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

 

  1. Cross-Site Request Forgery / CSRF

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

 

  1. ניהול תצורה לא מאובטח

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

 

  1. אחסון מידע מוצפן בצורה לא מאובטחת

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

 

  1. כישלון בהגבלת גישה לכתובת אתר

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

 

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

לעתים קרובות, יישומים נכשלים באימות, הצפנה והגנה נאותה על הסודיות והשלמות של תעבורת הרשת הרגישה. לפעמים יישומים אלו מממשים אלגוריתמים חלשים, משתמשים בתעודות שגויות או שפג תוקפם, או במקרים אחרים משתמשים בהם לא כראוי. שימו לב, לא תמיד מדובר רק בהגדרה של HTTPS (כלומר HTTP מעל SSL/TLS) בשרת ה-Web בלבד, אלא ישנם מקרים בהם קוד המערכת עצמו פונה בצורה מפורשת לכתובות HTTP, או שההטמעה של HTTPS בקוד המערכת איננה נעשית בצורה תקנית.

 

  1. הפניות והעברות לא מאומתות

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

 

נקודה אחרונה – בטוחני שכולכם מכירים את Stack Overflow, אחד המשאבים האהובים על מארחינו. אחד האתרים המקבילים של SO, הינו IT Security – בכתובת http://security.stackexchange.com . כמובן, אפשר לשאול כל שאלה ספציפית שיש לכם, בדיוק כמו ב-SO – אבל הפעם בנושאי אבטחת מידע, אפליקטיבית או לא. התשובות שמתקבלות שם ברמה גבוהה במיוחד, כמובן.

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

 

תגובה 1 על “הוראות בטיחות לפיתוח קיץ

כתבו תגובה

כתובת הדוא"ל שלכם לא תוצג.