סיכום אבטחת מערכות תוכנה מתקדמות - PDF

‫סיכום אבטחת מערכות תוכנה מתקדם‬ ‫יחידה ‪ - Introduction & Overview - 1‬מבוא וסקירת הקורס‬ ‫שיעור ‪:1‬‬ ‫שכבה ‪- Knowledge Tier - of basic concepts in the world of i...

‫סיכום אבטחת מערכות תוכנה מתקדם‬ ‫יחידה ‪ - Introduction & Overview - 1‬מבוא וסקירת הקורס‬ ‫שיעור ‪:1‬‬ ‫שכבה ‪- Knowledge Tier - of basic concepts in the world of information security 1‬‬ ‫‪ -CVE‬קטלוג של חולשות במוצרי תוכנה או רכיבי צד שלישי‪.‬מקוטלג באמצעות מס' סידורי ייחודי‪.‬שפה משותפת‬ ‫בכל העולם בנוגע לסוג החולשה ואופייה‪.‬יש מקום מרכזי שמרכז את כל עניין החולשות וה ‪ patch‬לתיקונים‪.‬‬ ‫ ‪ - Vulnerability‬החולשה עצמה (בתוכנה ‪ ,software‬בחומרה ‪ ,hardware‬או במערכות הפעלה)‪.‬‬ ‫ ‪ - Exploit‬חומרת החולשה כלומר כמה קל לנצל את החולשה לתקיפה משמעותית‪.‬‬ ‫ ‪ -Threat‬איום‪ ,‬הקוד הזדוני שגורם לתקיפה ע"י ניצול החולשה‪.‬‬ ‫ ‪ -DREAD‬מודל שעוזר לנו להעריך את רמת הסיכון בחולשה מסויימת ועוזר לנו להעריך את רמת הנזק‬ ‫האפשרית ומה הסיכוי שהיא תקרה‪.‬ראינו בקורס הקודם בהרחבה‪.‬‬ ‫‪ - Log4j / Log 4 Shell‬ספריית צד שלישי של שימוש בלוגים‪.‬מיקרוסופט השתמשה בספרייה זו לצורך שימוש‬ ‫במשחק מיינקראפט‪.‬בספריה זו התגלתה חולשה קריטית שמאפשרת הזרקת קוד לתוכנה‪ ,‬מה שאפשר להאקרים‬ ‫הנתקף‪.‬‬ ‫במחשב‬ ‫זדוני‬ ‫קוד‬ ‫ולהריץ‬ ‫זאת‬ ‫לנצל‬ ‫החולשה נוצלה ע"י שימוש ב ‪ Lightweight Directory Access Protocol - LDAP‬שזה בעצם אופציה שקיימת‬ ‫בשפת ‪ JAVA‬של טעינת קטעי קוד והרצתם ממקור מרוחק ‪Remote Code Execution - RCE.‬‬ ‫ההאקרים גרמו לשרת הנתקף להריץ את הקוד הזדוני שהם כתבו בצ'אט של המשחק ובכך גרמו נזק‪.‬‬ ‫שלבי ההתקפה‪:‬‬ ‫‪.1‬שליחת בקשה נגועה לשרת הנתקף ע"י ההאקר‪(.‬שליחת הודעה בצ'אט המכילה קוד זדוני)‪.‬‬ ‫‪.2‬השרת שהיה אמור לכתוב ללוג את הבקשה כטקסט הריץ אותה כקוד‪ ,‬וכיוון שהטקסט הכיל קוד של ‪,RCE‬‬ ‫השרת שולח בקשת טעינת קוד מרוחק ממקור זדוני‪.‬‬ ‫‪.3‬הקוד הזדוני נטען לשרת ומורץ על ידו ובכך מזיק לשרת‪.‬‬ ‫)‪ - Open SSL) Heartbleed‬פגיעות בספריה שמימשה את פרוטוקול ‪.SSL‬אופן הפגיעות התבסס על בקשת‬ ‫בדיקה שהשרת אכן פעיל‪.‬בתהליך הלקוח שולח מילה ואת אורכה (אורך הבאפר)‪ ,‬והשרת אמור לענות לו כתשובה‬ ‫את המילה שנשלחה‪.‬הפגיעות ‪ -‬אם המילה הייתה קצרה‪ ,‬אך הצהרת אורך הבאפר הייתה גדולה מאורך המילה‪,‬‬ ‫השרת החזיר מילה באורך שהוצהר ולא באורך המקורי‪ ,‬וע"י כך נחשף מידע רגיש שהיה רשום לו בזיכרון‪.‬‬ ‫‪ - Secure Software Development Lifecycle - SSDLC‬תהליך פיתוח תוכנה מאובטחת שמשולב מתחילת‬ ‫הפיתוח ועד שלב הפצתה ותחזוקה‪.‬‬ ‫‪ - SHIFT LEFT‬מושג חשוב שאומר ששילוב רכיבי האבטחה משולבים ומתוכננים מראש‪ ,‬ולא נזכרים בהם בשלב‬ ‫מאוחר אשר מקשה על מימוש דרישות האבטחה כיאות‪.‬חשוב להדגיש שבכל שלב פיתוח מתעסקים גם באבטחת‬ ‫התוכנה ולא רק בפיתוח‪.‬‬ ‫‪1‬‬  ‫‪ - Maintaining security Balance‬נקודת האיזון בין האבטחה לבין הפונקציונליות והשימוש נוח באפליקציה‪.‬‬ ‫הסיבות לכתיבת קוד לא מאובטח‪:‬‬ ‫ ‪ - Lack of Resources and Time‬חוסר במשאבים וזמן ‪ -‬לחץ באספקת מוצר ללקוח ועמידה בדרישות‬ ‫המעסיק לטווח הקצר‪.‬‬ ‫ ‪ - Lack of Education‬חוסר מודעות‪.‬‬ ‫ ‪ - Security and Development Silos‬הפרדה בצוותי הפיתוח‪ ,‬קיימים צוותי פיתוח וקיימים צוותי‬ ‫אבטחה והם לא עובדים יחד‪.‬‬ ‫ ‪ - Not Seeing Security as a Top Priority‬גישה שאומרת‪" ,‬קודם נביא מוצר עובד ובסוף נדאג‬ ‫לאבטחה שלו"‪(.‬לא מומלץ בכלל ואף מסוכן)‪.‬‬ ‫שכבה ‪- Principles Tier - Understanding and grasping the principles of secure development2‬‬ ‫‪ - Consider Software Security as a Priority Right From The Start.1‬מחשבה על אבטחה‬ ‫כמרכיב משמעותי בשלבים ההתחלתיים של הפרויקט‪.‬ושימוש באוטומציות לצורך בדיקות אבטחה בשלבי‬ ‫הפיתוח השונים‪.‬‬ ‫‪ - Defining Project’s Security Requirements.2‬הגדרת דרישות אבטחה‪.‬‬ ‫‪ - Identify Potential Security Threats.3‬זיהוי פגיעויות ואיומים רלוונטים‪.‬חשוב לבדוק שיש לנו את‬ ‫הכלים לבחון את המערכת ולחפש את החולשות‪.‬צריך גם לשים לב שאנחנו מתקנים את החולשות שאנחנו‬ ‫מוצאים ולא מסתפקים רק לגלות אותם‪.‬‬ ‫‪ - Have Secure Coding Guidelines and Standards.4‬קווי אבטחה מנחים כסטנדרט בפיתוח‪.‬חשוב‬ ‫להצמד לסטנדרטים מוכרים וידועים כגון ‪ OWASP‬או ‪ NIST‬ולא להמציא את הגלגל מההתחלה‪.‬‬ ‫‪ - Use Up-To-Date Frameworks and Libraries.5‬שימוש בספריות עדכניות‪ ,‬מוכרות ומתוחזקות‬ ‫בצורה נכונה‪.‬לבדוק שאכן הקהילה מאמינה בספריות האלה‪.‬יש גם ספריות אבטחה חשובות שכדאי ורצוי‬ ‫להשתמש בהם‪.‬בנוסף חשוב שיהיה גורם אשר מבקר את הקוד שנכנס לתוך הארגון‪.‬‬ ‫‪ - Conduct Security Awareness Training.6‬אימון עובדים באבטחה והעלאת מודעות‪.‬פגישות בין‬ ‫העובדים ושיתוף במקרי אבטחה שכל אחד חשב עליהם‪.‬‬ ‫‪ - Securing Access to Databases.7‬גישה מאובטחת לבסיסי הנתונים‪.‬למנוע גישה לא מורשית ומניעת‬ ‫דלף מידע של בסיס הנתונים‪.‬‬ ‫‪ - Implement Digital User Identity.8‬זיהוי נכון של המשתמשים ובדיקת אישורי גישה‪.‬‬ ‫‪ - Handle Errors and Exceptions in All Areas.9‬טיפול בשגיאות ותגובה נכונה בהתאם‪.‬‬ ‫‪ - Monitor Security Information.10‬בקרה ומידע על רכיבי האבטחה‪.‬שימוש בלוגים לצורך בקרה ע"י‬ ‫מעקב אחריהם‪.‬הלוגים עוזרים לנו לתעד דברים חשובים שקורים במערכת שלנו‪.‬‬ ‫שיעור ‪:2‬‬ ‫שכבה ‪- Risk Tier - Knowing the attack surface and possible threats3‬‬ ‫‪ - Information Security‬הכרת משטח התקיפה‪ ,‬יישום הגנות‪ ,‬תרגול המתקפה והתמגנות ממנה‪.‬לדעת מה‬ ‫ההתקפות הרלוונטיות ביותר על הארגון שלנו ואיך ניתן למנוע אותם‪.‬‬ ‫‪2‬‬ ‫‪ - Attack Vector‬משטח התקיפה‪ ,‬הוא דרך הפעולה של התוקף ומה החולשה אותה הוא מנצל‪.‬חשוב להכיר את‬ ‫משטחי התקיפה ולמגן אותם‪.‬ככל שיש לנו יותר מידע על המערכת ועל הסיכונים האפשריים‪ ,‬כך נוכל להגן על‬ ‫המערכת שלנו בצורה טובה ונכונה יותר‪.‬‬ ‫‪ - OWASP top 10‬חשוב תמיד להכיר מה הם ההתקפות הכי נפוצות‪ ,‬להתעדכן כל הזמן וללמוד עליהם‪.‬הרשימה‬ ‫הזו תמיד משתנה‪ ,‬ולכן חשוב לעקוב‪.‬‬ ‫שכבה ‪- Controls Tier - Knowing a wide spectrum of defense methods4‬‬ ‫‪ - Security Controls‬בקרות אבטחה‪.‬‬ ‫ ‪ - Input Validation‬בדיקת קלט‪ ,‬לבדוק גם מצד לקוח וגם מצד השרת‪.‬חשוב מאוד לבדוק את הקלט‬ ‫שאנחנו מקבלים לשרת‪.‬כדאי לעשות ‪ - whitelist‬כלומר מה מותר (אם נאמר רק מה אסור‪ ,‬יכול להיות‬ ‫שלא נשים לב שאנחנו מפספסים דברים)‪.‬הדגש הוא לבדוק גם צד לקוח וגם צד שרת‪.‬‬ ‫ ‪ - Authentication Controls‬כדאי לשים יותר מרכיב אימות אחד‪ ,‬ככל שיש יותר רכיבים המנגנון יותר‬ ‫חזק‪.‬‬ ‫○ ‪ - KNOW‬משהו שאני יודע‪.‬‬ ‫○ ‪ - HAVE‬משהו שיש לי‪.‬‬ ‫○ ‪ - ARE‬משהו שהוא אני‪.‬‬ ‫○ ‪ - WHERE‬המקום שאני נמצא‪.‬‬ ‫אפשר להשתמש במנגנון כמו ‪Kerberos‬או ‪SSO‬שבו‪ :‬אחרי שבוצעה הזדהות אחת‪ ,‬ניתן להשתמש‬ ‫במגוון שירותים בארגון ואף בארגונים אחרים ללא צורך בהזדהות נוספת‪.‬‬ ‫‪ - Encryption‬הצפנה סימטרית או אסימטרית‪ ,‬שימוש באלגוריתמים יעודיים בהתאם לסוג המידע‪.‬צריך‬ ‫‬ ‫לדעת איך עושים את הפצת המפתחות וכו'‪.‬‬ ‫‪ - Web Best Practices‬הגנות אבטחה ברמת הרשת‪.‬‬ ‫‬ ‫○ ‪ - HTTP Cookies Defended with‬שימוש בדגלי אבטחה כגון‪:‬‬ ‫ ‪HttpOnly = True‬‬ ‫ ‪Secure = True‬‬ ‫ ‪SameSite = Lax/Strict‬‬ ‫○ ‪ - HTTP Security Headers‬לבדוק את הבקשה בהתאם ל ‪ Header‬שלה ולקבוע חוקים מה‬ ‫אנחנו מוכנים לקבל‪.‬‬ ‫○ ‪ - Referer validation‬חסימת גישה שאנחנו לא רוצים לקבל‪ ,‬זה נמצא בתוך הבקשת ה ‪HTTP‬‬ ‫הוא אומר מאיזה דומיין ומאיזה שרת הבקשה הגיעה‪.‬‬ ‫‪ - HTTP Cookies‬שימוש בעוגיות על מנת לשמור את הסשן ‪ ID‬שלנו‪.‬יש בזה גם משהו מסוכן ולכן חשוב‬ ‫‬ ‫לשמור על ה ‪ Cookies‬בצורה טובה ולהשתמש בשיטות וספריות מתאימות‪.‬‬ ‫שכבה ‪- Architecture Tier - Design secure solutions5‬‬ ‫חשוב שנבנה ארכיטקטורה טובה ובטוחה‪.‬‬ ‫‪3‬‬ ‫‪ - Information Security‬בניית מערכת בצורה מאובטחת עוד משלב ההתחלה ולאורך כל שלבי הפיתוח‬ ‫‬ ‫כגון‪DevSecOps :‬ו ‪SDLC.‬‬ ‫‪ - Security by Design‬אבטחה משלב הבנייה של המערכת‪.‬‬ ‫‬ ‫○ ‪ - Defense in Depth‬הגנה בשכבות‪.‬‬ ‫○ ‪ - Privacy by Design‬התייחסות לפרטיות משלב תכנון המערכת ושימוש בהצפנה ומפתחות‬ ‫לצורך שמירה על מידע רגיש‪.‬‬ ‫○ ‪ - Least privilege & Need to know‬אבטחה באמצעות מניעת גישה‪ ,‬כמה שפחות ורק מה‬ ‫שחייבים‪.‬‬ ‫○ ‪ - Segregation of Duties, Dual Control‬הפרדת רשויות‪ ,‬לא לתת לאדם אחד לשלוט על‬ ‫הכל‪ ,‬אלא לחלק את התהליך לכמה אנשים שונים‪.‬‬ ‫○ ‪ - (Shared responsibility (Cloud‬אחריות שיתוף בענן‪.‬‬ ‫○ ‪ - Secure by defaults‬לאבטח הגדרות ברירת מחדל‪.‬‬ ‫○ ‪ - (Fail security (vs Fail open‬לבחור מה קורה כאשר המערכת קורסת‪ ,‬סגור או פתוח‪.‬‬ ‫○ ‪ - keep it simple - KISS‬לשמור על פשטות הקוד והמערכת תוך שמירה על תפקוד מקסימלי‪.‬‬ ‫○ ‪ - Trust but verify‬מחלק את המשתמשים לקטגוריות‪ ,‬ובהתאם לזה מבצעים בדיקות זהות על‬ ‫המשתמש‪.‬‬ ‫○ ‪ - Zero trust‬לא לסמוך על אף אחד‪ ,‬תמיד לבדוק זהות משתמש‪.‬‬ ‫‪Control types‬‬ ‫‬ ‫○ ‪ - (Administrative (policies, procedures‬בקרה אדמיניסטרטיבית (מנהלית)‪.‬‬ ‫○ ‪ - (Technical control (VPN, FW, Patches‬הגנה טכנית באמצעות חומרה או תוכנה‪.‬‬ ‫○ ‪ - (Physical controls (Door's lock‬בקרה פיזית כגון גדר‪.‬‬ ‫‪ :Functionalities of security controls‬סוגים של בקרות‪.‬‬ ‫‬ ‫○ ‪ - (Preventive (FW‬מניעה‪.‬‬ ‫○ ‪ - (Detective (IDS‬גילוי‪.‬‬ ‫○ ‪ - (Corrective (fixing scripts‬מתקנת‪.‬‬ ‫○ ‪ - (Deterrent (light, warning signs‬התראה‪.‬‬ ‫○ ‪ - (Recovery (backup‬שחזור‪.‬‬ ‫○ ‪ - (Compensating (statement‬בקרה מפצה‪.‬‬ ‫‪ - Least privilege‬גישת הרשאה לפי תפקיד‪.‬‬ ‫‬ ‫‪ - Need to know‬רק מה שאדם חייב לדעת ולא מעבר‪.‬‬ ‫‬ ‫‪ - Now It’s the Human Mind‬כדאי לחשוב בראש של אבטחת מידע‪ ,‬חשיבה של תוקפים וחשיבה מחוץ‬ ‫‬ ‫לקופסא‪.‬כלומר להיות תמיד בראש שצריך תוכנה מוגנת ומאובטחת‪.‬‬ ‫‪ - Threat Modeling Methodologies‬תמיד להיות ‪ shift left‬כלומר תמיד להיות בבניית מוצר‬ ‫‬ ‫שהאבטחה באה שלב לפני הפיתוח‪ ,‬וכן צריך לבצע בכל שלב את בדיקת האיומים האפשריים ולפעול על‬ ‫פיהם‪.‬‬ ‫‪4‬‬  ‫‪Overview‬‬ ‫‪Secure Coding Frameworks and Standards‬‬ ‫‪Standards and Awareness‬‬ ‫‪ -NIST's Secure Software Development Framework - SSDF‬פרוטוקול של ‪NIST‬‬ ‫‬ ‫להקמת תשתיות אבטחה בארגון נועד גם לאנשים לא טכנולוגים שיוכלו ליישם את הדברים בארגון‪.‬‬ ‫ ‪ -OWASP’s Application Security Verification Standard - ASVS‬סטנדרטים לתוכנה‬ ‫מאובטחת מיועד למפתחים מבית ‪.OWASP‬‬ ‫ ‪ - The OWASP Top Ten Proactive Controls‬הגנות אקטיביות של ‪.OWASP‬‬ ‫‪DevSec in DevSecOps Culture‬‬ ‫ ‪ - DevOps vs DevSecOps‬שילוב אבטחה תוך כדי כל שלבי הפיתוח‪ ,‬כמחזור מעגלי וקבוע‪.‬‬ ‫ ‪ - Objectives and Topics‬הכרת תהליכי פיתוח התוכנה ואיך משלבים בהם את האבטחה‪.‬‬ ‫‪Advanced API Threats and Secure Coding‬‬ ‫ ‪ - OWASP Top 10 API Security Risks‬להכיר את הסיכונים ב ‪ API‬ואיך להתמגן מהם‪.‬‬ ‫ה ‪ API‬מאוד רווח היום‪ ,‬ולכן כדאי לבנות מערכות עם ‪ ,API‬וכן צריך גם להגן עליו‪.‬‬ ‫‪Advanced AI / LLM Threats and Secure Coding‬‬ ‫ ‪ - OWASP Top 10 for LLMs Applications‬שישמוש במודלי ‪.GEN AI‬צריך להכיר את‬ ‫האיומים הקיימים בנושא‪ ,‬לדעת איך להתמגן מהם ולהבין מושגים שמשתמשים וקשורים ב ‪.AI‬‬ ‫‪Advanced Deep Inspection for NGFWs and WAFs‬‬ ‫ ‪ - Level of inspection for SPI, MPI and DPI in OSI model‬מודלים נפוצים ומה מתפתח‬ ‫בתעשייה‪ ,‬להבין לעמוק‪.‬‬ ‫[ לא בחומר של המבחן ‪ -‬להעשרה בלבד ]‬ ‫יחידה ‪ - Secure Coding Frameworks and Standards - 2‬סביבת‬ ‫קידוד מאובטחת וסטנדרטים‬ ‫שיעור ‪:3‬‬ ‫‪ Adopt the NIST SSDF -‬סטנדרט ברור ומונגש (מבחינת ניסוח) לסביבה מאובטחת‪ ,‬הכוללת תהליך שלם‬ ‫מפיתוח ועד הפצה ‪" -‬קוד מאובטח לא מספיק כדי שהתוכנה שלנו תהיה בטוחה"‪ ,‬עוזר לנו לא להמציא את הגלגל‬ ‫מחדש‪.‬נועד גם לאנשים לא טכנולוגים שיוכלו ליישם את הדברים בארגון‪.‬‬ ‫‪SSDF StructureSSDF Structure:‬‬ ‫‪ - Prepare the organization - PO.1‬הכנת צוותי הפיתוח והארגון לפיתוח מאובטח‪.‬‬ ‫‪.1‬הכנת הארגון‪.‬‬ ‫‪5‬‬ ‫‪.2‬הגדרת דרישות אבטחה לפיתוח וגם לספריות צד ‪ 3‬שנצטרך לצרוך או לגורמים צד ‪ 3‬ששותפים‬ ‫לפיתוח‪.‬‬ ‫‪.3‬זיהוי אנשים מתאימים לצורך יישום הדרישות‪.‬‬ ‫‪.4‬יצירת תפקיד חדש של אחראי אבטחה (‪.)security champions‬‬ ‫‪.5‬לתת הכשרה לפיתוח מאובטח למפתחים ובעיקר ל ‪.security champions‬‬ ‫‪.6‬מחויבות לפיתוח מאובטח ‪ -‬מהמתכנת הפשוט ועד למנהלים הבכירים שמעורבים בתהליך‪.‬‬ ‫‪.7‬אספקת כלים נדרשים ‪ -‬שילוב אוטומציות שימנעו טעויות ושיאכפו את כללי אבטחה‪.‬‬ ‫‪.8‬יצירת סביבות נפרדות לפיתוח‪ ,‬בדיקה ו "העולם האמיתי"‪.‬‬ ‫‪.9‬אבטחת מחשבי הקצה לפי הצורך‪.‬‬ ‫‪.10‬יצירת צ'ק ליסט או מבחנים לצורך מעבר ובדיקה שלא התפספס משהו ושהכל קשורה‪.‬וכמובן‬ ‫כדאי לתעד את תוצאות המבחנים‪.‬‬ ‫‪ -Protect Software - PS‬הגנת כלל הרכיבים בתוכנה בצורה מובנית ומסודרת‪.‬‬ ‫‪.2‬‬ ‫‪.1‬ניהול בקרת תצורה של הקוד (‪)GIT‬‬ ‫ דלף מידע בעקבות העלאת סיסמה לבקרת תצורה‪.‬‬ ‫ הכנסת קוד לא מעודכן או קוד שדרס תיקון באג‪.‬‬ ‫ מחיקה בטעות של הקוד‪.‬‬ ‫ מניעת מניפולציה לקוד‪.‬‬ ‫ גישה לא מורשית‪.‬‬ ‫ זליגה בין רפוזיטורי‪.‬‬ ‫ מתקפת כופר‪.‬‬ ‫ ספריות צד שלישי עם הרשאות מסוכנות‪.‬‬ ‫‪.2‬לנהל ארכיון גרסאות במקום נפרד מהקוד והתוצרים וכן קבצי הגדרות‪.‬‬ ‫‪.3‬לנהל הרשאות גישה גם לגישה בטעות וגם גישה זדונית‪.‬‬ ‫‪.4‬לספק אוטומציה של חסימת העלאה של מידע רגיש‪.‬‬ ‫‪.5‬אוטומציה שחוסמת העלאת קוד שובר שלמות‪ ,‬לדוגמה לא מתקמפל‪.‬‬ ‫‪.6‬לתעד מי עשה ומה עשה‪.‬‬ ‫‪.7‬לייצר כלי שמוודא שהקוד לא עבר שינויים לדוגמה ע"י חתימה דיגיטלית של ‪.HASH‬‬ ‫‪ - Produce well secure software - PW.3‬יצירת גרסה מאובטחת בתהליך סדור‪.‬‬ ‫‪.1‬בכל שלבי התוכנה‪ ,‬גרסת התוכנה‪ ,‬צריכה לעמוד בדרישות האבטחה‪.‬‬ ‫‪.2‬הערכת סיכונים והתאמת רכיבי אבטחה בהתאם‪.‬‬ ‫‪.3‬להשתמש בקוד בטוח שכבר נכתב‪.‬בנוסף עלינו לעקוב על פרסומי הקהילה בענייני האבטחה של‬ ‫הקוד ולעדכן אם צריך‪.‬‬ ‫שיעור ‪:4‬‬ ‫‪ - code review.4‬חשוב כדי לקבל מבט חיצוני שיכול לחשוף בעיות‪.‬זה כמו עוד עין נוספת שעוברת‬ ‫על הקוד שלנו ובודקת את תקינותו ואיכותו‪.‬הדגש כאן שזה צריך להיות בודק מהצד‪ ,‬שבודק את‬ ‫הקוד בהתאם לדרישות שקיבלנו‪ ,‬מטרתו לבדוק שאכן בוצע מה שנדרש‪.‬‬ ‫‪ - Reuse Existing, Well-Secured Software.5‬שימוש בספריות שכבר נכתבו ונבדקו‪ ,‬במקום‬ ‫ליצור הכל מחדש‪.‬זה חוסך הרבה באגים ופגיעויות‪ ,‬אך עדיין חשוב להקפיד על דרישות האבטחה‪,‬‬ ‫כמו קוד חדש ולעקוב אחרי עדכוני אבטחה על הספריות האלו‪.‬‬ ‫‪6‬‬ ‫‪ - Secure Coding Practices.6‬צריך ליצור לעצמנו פרקטיקה לקיום קוד מאובטח‪.‬להגדיר איך‬ ‫אנו צריכים לפעול‪.‬נביא כמה דוגמאות לפרקטיקות‪:‬‬ ‫ ולידציה לקלט ו ‪ENCODING‬‬ ‫ אי שימוש בספריות לא בטוחות או שלא נבדקו מספיק‪.‬‬ ‫ יצור לוגים ומעקב עליהם‪.‬‬ ‫ שימוש בסביבה עם מערכות אוטומטיות לבדיקת הקוד‪.‬‬ ‫‪ - Configure the Compilation, Interpreter.7‬קינפוג נכון של הקומפיילר אשר יתריע על‬ ‫בעיות אבטחה וכן עלינו לפעול על מנת לתקן את הקוד ע"פ ההמלצות‪(.‬להתייחס לאזהרות של‬ ‫הקומפיילר כמו שאנו מטפלים בשגיאות)‪.‬‬ ‫‪ - Review and/or Analyze Human.8‬בדיקות אנושיות‪ ,‬אין תחליף לבדיקה האנושית‪ ,‬יש דברים‬ ‫שהמכונה לא תראה‪.‬‬ ‫‪- Test Executable Code to Identify Vulnerabilities and Verify Compliance.9‬‬ ‫בדיקות סטטיות ודינמיות‪ ,‬כדי לשפר את מנגנון הבדיקות ע"י בניית בדיקות אחרי שאנחנו רואים‬ ‫כבר את הקוד הכתוב ולחשוב על דברים נוספים שכדאי לבדוק‪.‬‬ ‫‪ - Regression & DAST Vulnerability Testing.10‬רגרסיה של בדיקות פונקציונליות ישנה‬ ‫לוודא שלא נפגע‪.‬כלומר תמיד אנחנו מבצעים עוד בדיקות‪ ,‬אך זה בנוסף על הבדיקות שכבר יש‬ ‫לנו‪ ,‬אנחנו תמיד צריכים לשאוף שגם הבדיקות הישנות שעשינו יעברו בצורה תקינה‪.‬‬ ‫בדיקות ‪ - SAST‬הם בדיקות קופסה לבנה‪ ,‬בדיקות ‪ DAST‬הם בדיקות קופסה שחורה‪.‬‬ ‫ככל שנבדוק ונגלה שגיאות בשלב יותר מוקדם כך עלות וקלות התיקון יהיו נמוכים בהתאם‪.‬‬ ‫הבדיקות האלו (סטטי ודינמי) משלימות אחת את השניה ונותנות לנו תמונה רחבה על תקינות‬ ‫הקוד ואיכותו‪.‬‬ ‫‪ - References Configure Software to Have Secure Settings by Default.11‬הזכרנו‬ ‫קודם שחשוב לעשות בייסליין לקונפיגורציות‪ ,‬נגיד סקריפט שיוצר שרת בסיסי מאובטח לתחילת‬ ‫פיתוח חדש‪.‬בגלל שאנחנו יודעים שהבסיס הזה של השרת מאובטח ובנוי נכון‪ ,‬מכאן נוכל לבנות‬ ‫את המשך הפיתוח ולבדוק מכאן ואילך‪.‬‬ ‫‪Infrastructure as Code - IAC -.12‬עוסק באוטומציה של אספקת תשתית‪ ,‬הכוללת שרתים‪ ,‬מסדי‬ ‫נתונים‪ ,‬רשתות ורכיבי חומרה או תוכנה אחרים‪.‬‬ ‫‪Configuration-as-Code - CAC -.13‬עוסק בניהול ההגדרות והפרמטרים שאפליקציה או רכיב‬ ‫מערכת צריכים לפעול כהלכה‪.‬‬ ‫‪Responds to Vulnerabilities - RV -‬תחזוק נכון ומאובטח של התוכנה לאחר הפצתה‬ ‫‪.4‬‬ ‫‪ - CVE.1‬לעקוב אחרי העדכונים עבור חולשות ידועות‪ ,‬ובניית תהליך תגובה בהתאם לאיומים‬ ‫ולהערכת הנזקים האפשריים‪.‬צריך שיהיה לנו שיטת פעולה כאשר מתגלה פגיעות בקוד‪.‬‬ ‫‪.2‬חיפוש באגים‪.‬‬ ‫‪.3‬התקנת פאצ'ים הכרחיים מיד כאשר מתגלים חולשות ופרצות אבטחה‪.‬‬ ‫‪.4‬כאשר מוציאים גרסה חדשה‪ ,‬חשוב לרשום תיאור לגרסה‪ ,‬כלומר מה התיקונים שנוספו או פיצ'רים‬ ‫שנוספו‪.‬‬ ‫‪OWASP Top TEN Proactive Controls‬‬ ‫עשרת ה ‪ controls‬אשר מומלצים מטעם ‪ OWASP‬לצורך הגנת התוכנה שלנו‬ ‫‪7‬‬ ‫‪ - Define Security Requirements.1‬להגדיר דרישות אבטחה ‪ -‬הוא הכי חשוב‪ ,‬הוא הבסיס לכל שאר‬ ‫רכיבי האבטחה‪.‬ולכן כדאי להתייחס אליו משלב הכי מוקדם שאפשר בפיתוח התוכנה‪.‬‬ ‫ ‪ -Application Security Verification Standard - ASVS‬סטנדרט מפורט שמפתחים כתבו‬ ‫למפתחים אחרים לצורך פיתוח מאובטח של אפליקציות‪.‬מכיל מספר רמות אבטחה שנדרש‬ ‫לאפליקציה‪.‬לכל רמת אבטחה‪ ,‬מתאימים את הבקרות הנדרשות אליה ואת הסעיפים הנדרשים‬ ‫למימוש האבטחה‪.‬‬ ‫‪.1‬רמה ‪ - 1‬ללא דרישות אבטחה גבוהות‪(.‬הרמה הקלאסית והבסיסית ביותר שכל‬ ‫אפליקציה תרצה לעמוד בה לפחות)‪.‬‬ ‫‪.2‬רמה ‪ - 2‬עם דרישות אבטחה אבל לא הכי קריטי‪.‬‬ ‫‪.3‬רמה ‪ - 3‬דרישות אבטחה ברמה קריטית (ככל שרמת האבטחה הנדרשת יותר גבוהה‪,‬‬ ‫יהיה עלינו לממש יותר פעולות אבטחה‪ ,‬יש טבלאות שמראות לנו כמה מנגנוני אבטחה‬ ‫עלינו ליישם בכל רמה ובהתאם לסוג האפליקציה שאנו בונים)‪.‬‬ ‫שיעור ‪:5‬‬ ‫‪ - Leverage Security Frameworks & Libraries.2‬שימוש בספריות בצורה מאובטחת ‪ -‬רצוי‬ ‫להשתמש רק בספריות מוכרות ושיש להם קהילה פעילה‪.‬לא כדאי להשתמש בספריות לא מוכרות כי יכול‬ ‫להיות שיהיה בהם פגיעויות‪.‬יש כלי מיוחד ש ‪ OWASP‬הוציאו שבודק את הקוד שלנו‪ ,‬הוא עובר על הקוד‬ ‫ועל כל הספריות שהשתמשנו בהם ונותן בסוף דוח מסודר האם פורסמו על הספריות שהשתמשנו בהם‬ ‫פגיעויות כאלה ואחרות‪.‬לכלי הזה קוראים ‪OWASP Dependency Check.‬‬ ‫קיימים כמה כלים מחברות שונות המבצעות בדיקות אלו‪ ,‬הקטגוריה הכללית לכלים מסוג זה נקראת ‪:‬‬ ‫‪Dependency-Check is a Software Composition Analysis - SCA.‬‬ ‫‪ - Secure Database Access.3‬ניהול גישות ל ‪ - DB‬אנו צריכים לבחון את הגישה לשרת המידע שלנו‬ ‫בצורה מבוקרת ולבדוק שאין אפשרות לדלף מידע‪.‬לבדוק שהקוד לא חשוף ל ‪.SQL injection‬‬ ‫נביא דוגמה‪ ,‬למשל אנו רוצים לקבל קלט מהמשתמש ולהשתמש בזה לצורך בניית שאילתה של ‪SQL‬‬ ‫והמשתמש בחר להכניס לנו קוד זדוני הבא‪ 1'='1' X' or'-- :‬ואז נקבל תנאי שתמיד נכון ומינוס מינוס אשר‬ ‫מבטל את כל מה שבא אחריו‪,‬הוא כאילו אומר ל ‪ SQL‬תתעלם מהשאר‪ ,‬כמו הערה‪.‬וכך יכול לצאת לנו‬ ‫מידע מתוך הדטה בייס בלי שרצינו שזה יקרה‪.‬‬ ‫ניתן להגן מפני מקרים אלו ע"י שימוש בספריות מתאימות שהופכות את הקלט ל ‪ string‬ובודקות אותו‬ ‫בדיוק איך שהוא‪ ,‬ללא אפשרות שהוא יתורגם לקוד‪ ,‬לשיטה זו קוראים ‪parameterized query.‬‬ ‫ ‪ - Cross-Site Scripting Protection - XSS‬התקפה באמצעות הזרקת קוד זדוני בד"כ הקוד‬ ‫הזדוני נכתב ב‪:java script -‬‬ ‫קיימים שני סוגים מרכזיים‪:‬‬ ‫○ ‪Reflective XSS -‬הכנסת קוד זדוני לתוך שאילתה או לתוך האתר‪ ,‬והאתר נפגע מהקוד‬ ‫הזדוני‪.‬הוא לא נשמר בדטה בייס אלה מתבצע בתוך ‪ request‬מסויים בלבד‪.‬‬ ‫○ ‪ - Persistent XSS‬שותלים בתוך האתר קוד זדוני‪ ,‬כך שכל מי שיטען את האתר יפגע‬ ‫מקוד זה‪.‬זה קוד שמוטמע בתוך הדטה בייס עצמו של האתר‪.‬‬ ‫דוגמה‪:‬‬ ‫‪8‬‬ ‫‪ - Encode and Escape Data.4‬שימוש בטכניקות למניעת הזרקה של פקודות ‪ -‬הרעיון הכללי של שיטות‬ ‫אלו הוא המרת הקלט של המשתמש לטקסט אשר ממיר תווים מיוחדים לצורה ייחודית כך שהתו המיוחד‬ ‫יהפוך למחרוזת ‪ string‬ולא כחלק מקוד‪.‬ההמרה מתבצעת בצורה כזו שקלט המשמש הופך להיות טקסט‬ ‫בלבד ומבטל את האפשרות שטקסט זה יהפוך לקוד בר הרצה‪.‬‬ ‫ההבדל בין ‪ encoding‬לבין ‪ escaping‬הוא‪:‬‬ ‫‪ encoding‬ממיר כל תו מיוחד בטקסט לקידוד ממשי לדוגמא‪ / :‬יהפוך להיות ‪%20‬‬ ‫לעומת ‪ escaping‬שלפני כל תו מיוחד יש ‪ backslash‬לדוגמא‪ =\ :‬או \‪./‬‬ ‫‪ Encode -‬המרה של תווים מיוחדים לקידוד מיוחד המבטא את הסימן המיוחד‪.‬‬ ‫‬ ‫‪Escape -‬תרגום הקלט והוספה של באקסלאש "\" לפני כל תו מיוחד‪.‬‬ ‫‬ ‫‪ Sanitize -‬פילטור נכון של הטקסט שהתקבל ע"י הבנת ההקשר והתוכן‪.‬זה כלי ברמה יותר‬ ‫‬ ‫גבוהה כי יש לו כבר המלצות מובנות וידע מוקדם איך להתמודד עם סוגים שונים של קלט‪.‬‬ ‫כלי לדוגמא‪OWASP Java HTML Sanitizer Project :‬‬ ‫החשיבות הרבה לשימוש בטכניקות אלו הוא למנוע התקפות מסוג ‪ XSS‬או ‪SQL injection‬‬ ‫שהזכרנו לעיל‪.‬‬ ‫כדאי ליישם את ההגנות האלו (ע"י שימוש בספריות ייעודיות) גם בצד הלקוח וגם בצד השרת‪.‬‬ ‫שיעור ‪:6‬‬ ‫‪ - Implement Digital Identity‬הגנה על הזהות הדיגיטלית ושמירה מחטיפת סשנים ועוגיות‬ ‫‬ ‫‪.)(Cookie‬נתמקד ב ‪ HTTP security headers‬שיכולים לעזור לנו בזה‪.‬‬ ‫○ ‪ -HTTP Strict Transport Security header - HSTS‬הוא מנגנון אשר השרת מוסיף‬ ‫לתשובה אותה הוא עונה למשתמש שפנה אליו ומודיע לו מעתה לא תקבל מענה ללא‬ ‫שימוש ב ‪.HTTPS‬הפקודה אומרת בעצם לדפדפן "אני לא מוכן שתפנה אלי יותר ב‬ ‫‪ HTTP‬אלא רק ב ‪ "HTTPS‬וגם אם הלקוח ינסה לפנות שוב ב ‪ HTTP‬הדפדפן שלו‬ ‫יחליף מייד ל ‪ HTTPS‬וכך זה מגן על הלקוח מ‪:‬‬ ‫‪(MITM - man-in-the-middle attacks) -.1‬מתוקף שיכול להאזין לסשיין או‬ ‫לחטוף אותו ולתווך בין הלקוח לשרת‪.‬‬ ‫‪SSL Striping Attack -.2‬הרצת סקריפט זדוני שהושתל אצל הלקוח שינסה‬ ‫לפנות לשרת בעצמו ב ‪ HTTP‬אך לא יצליח כי זה יחסם‪.‬‬ ‫‪cookie hijacking -.3‬גנבת עוגיה המכילה פרטי סשיין כיוון שמעתה זה יועבר‬ ‫בצורה מוצפנת‪.‬‬ ‫ההגנה הזו מגינה על המשך השיחה למעט הפניה הראשונה של הלקוח‪ ,‬אך זה מצמצם‬ ‫את משטח התקיפה משמעותית‪ ,‬לפניה הראשונה בלבד‪.‬לכן זה נחשב יחסית מוגן‪.‬‬ ‫כדי להבהיר למה זה לא עוזר לפניה הראשונה נתבונן בתרשים הבא‪:‬‬ ‫הסבר‪ :‬בתמונה אנו רואים שהתוקף בעצם נכנס באמצע הבקשה הראשונה‪ ,‬מה שקורה‬ ‫הוא שהתוקף ממשיך לנהל את השיחה עם השרת ב ‪ HTTPS‬ואילו מחזיר ללקוח את‬ ‫‪9‬‬ ‫התשובות ב ‪ HTTP‬בלי שהלקוח יכול לדעת‪.‬התוקף בעצם משמש כמעין ‪ Proxy‬בין‬ ‫הלקוח לבין האתר‪.‬‬ ‫דרך ההגנה‪:‬‬ ‫‪.1‬הוספת פקודה לאפצ'י אשר מונעת תקשורת שלא באמצעות ‪.HTTPS‬‬ ‫ ‪ - expire time‬זמן תפוגה‪.‬‬ ‫ ‪ - includesubdomains‬רק מהדומיין הנוכחי‪.‬‬ ‫‪.2‬טכניקה דומה בתוצאה אך לא בדרך‪ ,‬נחשבת לבטוחה יותר כיוון שהיא מגנה גם‬ ‫על פניה ראשונה‪.‬רישום האתר שלנו מראש במאגר נתונים עולמי מיוחד‪ ,‬כאשר‬ ‫הדפדפן יראה שהאתר נמצא במאגר‪ ,‬הוא אוטומטית ימיר את הבקשות ל‬ ‫‪ HTTPS‬באופן מיידי‪.‬‬ ‫‪ - X-XSS Header‬הגנה שפועלת כמו ‪ HSTS‬שמוסיפים כמה הגדרות פשוטות ב‪-‬‬ ‫○‬ ‫‪ Header‬וזה אומר לדפדפן לחסום ניסיונות של ‪ XSS attack‬מהאתר שלנו תוספת‬ ‫מעניינת מאפשרת לדפדפן לדווח על ניסיונות לא חוקיים‪.‬כאשר אנחנו מגדירים ‪ 1‬זה‬ ‫אומר שזה פעיל ועל זה ניתן להוסיף עוד אופציות‪.‬‬ ‫ ‪ - 0‬לא פעיל‪.‬‬ ‫ ‪ - 1‬פעיל‪.‬‬ ‫ ‪ - 1;mode=block‬הדפדפן מונע טעינה של כל הדף בעת התקפת ‪.xss‬‬ ‫ >‪ - 1;report=