OWASP Top 10 למפתחים: הסבר על הקטגוריות

#מה זה OWASP Top 10

OWASP Top 10 היא רשימה קצרה של עשר קטגוריות הסיכון המשמעותיות ביותר לאפליקציות ווב. OWASP, ה-Open Worldwide Application Security Project, הוא ארגון ללא מטרות רווח שמפרסם הנחיות אבטחה בחינם. המהדורה הנוכחית היא 2025, השמינית בסדרה.

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

מהדורת 2025 משלבת שני סוגי ראיות. הסוג הראשון הוא נתוני בדיקות: שלושה עשר ארגונים מזוהים וכמה תורמים אנונימיים דיווחו על תוצאות מיותר מ-2.8 מיליון אפליקציות, וספרו בכמה מהן נמצא לפחות מופע אחד של כל חולשה. הסוג השני הוא נתוני חולשות: כ-220,000 רשומות CVE מ-National Vulnerability Database האמריקאי, ממופות ל-643 CWEs. בדיקות אוטומטיות לא רואות הכול, ולכן שתיים מעשר הקטגוריות הגיעו מסקר קהילתי.

כל קטגוריה מקבצת CWEs קרובים, מתוך Common Weakness Enumeration ש-MITRE מתחזק. לפי OWASP, רשימת 2025 מכסה 248 CWEs.

#למה זה חשוב למפתחים

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

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

#עשר הקטגוריות

הסדר הוא הסדר של מהדורת 2025. הוא נועד לקריאה ואינו קובע מה לתקן קודם באפליקציה שלך. בכל סעיף יש דוגמה פשוטה, ההגנה העיקרית, ה-CWEs ש-OWASP ממפה לקטגוריה ו-Cheat Sheet.

#A01:2025 Broken Access Control

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

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

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

CWEs: CWE-284 Improper Access Control, CWE-639 Authorization Bypass Through User-Controlled Key, CWE-862 Missing Authorization, CWE-918 Server-Side Request Forgery (SSRF), מתוך 40 רשומות ממופות.

Cheat Sheet: Authorization Cheat Sheet.

#A02:2025 Security Misconfiguration

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

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

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

CWEs: CWE-16 Configuration, CWE-260 Password in Configuration File, CWE-15 External Control of System or Configuration Setting, מתוך 16 רשומות ממופות.

מקור: פרק V13 Configuration ב-ASVS. ל-OWASP אין Cheat Sheet לקטגוריה הזו.

#A03:2025 Software Supply Chain Failures

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

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

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

CWEs: CWE-1104 Use of Unmaintained Third Party Components, CWE-1395 Dependency on Vulnerable Third-Party Component, ועוד ארבע רשומות ממופות.

Cheat Sheets: Vulnerable Dependency Management Cheat Sheet ו-Dependency Graph SBOM Cheat Sheet.

#A04:2025 Cryptographic Failures

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

דוגמה: טופס כניסה שולח סיסמאות ב-HTTP גלוי, או שומר אותן עם hash מהיר ובלי salt.

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

CWEs: CWE-261 Weak Encoding for Password, CWE-319 Cleartext Transmission of Sensitive Information, CWE-321 Use of Hard-coded Cryptographic Key, מתוך 32 רשומות ממופות.

Cheat Sheets: Transport Layer Protection Cheat Sheet ו-Password Storage Cheat Sheet.

#A05:2025 Injection

הזרקה קורית כשקלט לא מהימן מגיע למפרש, כמו מנוע SQL, shell של מערכת ההפעלה או דפדפן, והמפרש מריץ חלק מהקלט כהוראות. OWASP מונה הזרקות SQL, NoSQL, פקודות OS, ORM, LDAP ו-expression language כצורות נפוצות. במהדורת 2025 גם cross-site scripting (XSS) נמצא בקטגוריה הזו.

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

הגנה עיקרית: להשתמש ב-API בטוח שמפריד בין נתונים לפקודות, כמו שאילתות עם פרמטרים או ORM. לאמת קלט בשרת עם allow lists. כשאי אפשר להימנע מפלט דינמי, להשתמש בכללי ה-escaping של המפרש שאליו הפלט מגיע. על שמות טבלאות ועמודות אי אפשר להחיל escaping כזה, ולכן הם צריכים להישאר מחוץ לקלט המשתמש לגמרי.

CWEs: CWE-20 Improper Input Validation, CWE-74 Injection, CWE-78 OS Command Injection, CWE-79 Cross-site Scripting, מתוך 37 רשומות ממופות.

Cheat Sheets: Injection Prevention Cheat Sheet ו-SQL Injection Prevention Cheat Sheet.

#A06:2025 Insecure Design

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

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

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

CWEs: CWE-269 Improper Privilege Management, CWE-256 Unprotected Storage of Credentials, CWE-73 External Control of File Name or Path, מתוך 39 רשומות ממופות.

Cheat Sheet: Secure Product Design Cheat Sheet.

#A07:2025 Authentication Failures

הכשלים האלה מכניסים את האדם הלא נכון, או מאפשרים לתוקף לנסות שוב ושוב עד שניסיון אחד מצליח. הם כוללים credential stuffing, password spraying, שחזור חשבון חלש, היעדר אימות רב־שלבי (MFA) ו-sessions שנשארים תקפים אחרי התנתקות.

דוגמה: בכניסת האדמין אין מגבלת קצב ואין MFA. התוקף מנסה צמדי שם משתמש וסיסמה מדליפות קודמות עד שאחד מהם עובד.

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

CWEs: CWE-287 Improper Authentication, CWE-259 Use of Hard-coded Password, CWE-290 Authentication Bypass by Spoofing, מתוך 36 רשומות ממופות.

Cheat Sheet: Authentication Cheat Sheet.

#A08:2025 Software or Data Integrity Failures

שלמות פירושה שהקוד או הנתונים הם מה שמצפים לקבל, ושאף אחד לא שינה אותם בדרך. הקטגוריה כוללת עדכונים אוטומטיים בלי בדיקת חתימה, סקריפטים שנטענים מ-CDN בלי בדיקת שלמות, צינורות CI/CD שמושכים artifacts ממקומות לא מאומתים, ו-deserialization של אובייקטים לא מהימנים.

דוגמה: דף טוען קובץ JavaScript מ-CDN של צד שלישי בלי מאפיין integrity. אם הקובץ משתנה, כל מבקר מריץ את הקוד ששונה.

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

CWEs: CWE-345 Insufficient Verification of Data Authenticity, CWE-494 Download of Code Without Integrity Check, CWE-502 Deserialization of Untrusted Data, מתוך 14 רשומות ממופות.

Cheat Sheet: Software Supply Chain Security Cheat Sheet.

#A09:2025 Security Logging and Alerting Failures

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

דוגמה: כניסות כושלות לחשבון אדמין לא נרשמות בכלל, ושורת הלוג של איפוס סיסמה מכילה את הסיסמה החדשה.

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

CWEs: CWE-778 Insufficient Logging, CWE-532 Insertion of Sensitive Information into Log File, CWE-117 Improper Output Neutralization for Logs, מתוך 5 רשומות ממופות.

Cheat Sheets: Logging Cheat Sheet ו-Application Logging Vocabulary Cheat Sheet.

#A10:2025 Mishandling of Exceptional Conditions

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

דוגמה: קריאת תשלום נתקעת ב-timeout, הקוד מתייחס ל-timeout כהצלחה, וההזמנה נשלחת בלי תשלום.

הגנה עיקרית: לתפוס שגיאות במקום שבו הן קורות ולטפל בהן במכוון. להוסיף exception handler גלובלי כרשת ביטחון. כשפעולה מרובת שלבים נכשלת באמצע, לעשות לה rollback ולהיכשל למצב סגור (fail closed).

CWEs: CWE-209 Generation of Error Message Containing Sensitive Information, CWE-252 Unchecked Return Value, CWE-248 Uncaught Exception, מתוך 24 רשומות ממופות.

Cheat Sheet: Error Handling Cheat Sheet.

#מה ה-Top 10 אינו

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

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

וגם הדרישות לא נמצאות בה. בשבילן OWASP מפרסם את Application Security Verification Standard (ASVS), אוסף דרישות אבטחה לתכנון, בנייה ובדיקה של אפליקציות ושירותי ווב. הגרסה הנוכחית היא 5.0.0, שפורסמה ב-30 במאי 2025. ב-Top 10 משתמשים כדי להסביר סיכון ולהחליט איפה להסתכל קודם. ב-ASVS, כשצריך דרישות לבנות ולאמת מולן.

#איך משתמשים ברשימה על פיצ׳ר אמיתי

1. לבחור פיצ׳ר אחד, כמו כניסה, תשלום או העלאת קובץ.
2. לעבור על עשר הקטגוריות ולרשום אילו מהן רלוונטיות.
3. לכל אחת, לציין את הבקרה בתכנון ואת הבדיקה שמוכיחה אותה. מי שעובד עם ASVS רושם גם את מזהה הדרישה.
4. לרשום את התוצאה במודל האיומים או ב-backlog, עם הקטגוריה וה-CWE ולא רק עם כותרת הבאג. לחזור על הסקירה אחרי שינויי תלויות ודיפלוי, כי A02, A03 ו-A08 משתנים יחד עם הסביבה.

#מעבדה מעשית: מיפוי שלוש קטגוריות של Juice Shop

בתרגיל מריצים על המכונה שלך את OWASP Juice Shop, אפליקציית ווב שפגיעה בכוונה, קוראים את לוח התוצאות וממפים שלוש קטגוריות של אתגרים לסעיפים ב-Top 10. לא מנצלים שום חולשה. קוראים את תיאורי האתגרים, בלי פתרונות, ומשאירים את האפליקציה קשורה ל-localhost.

צריך Docker. הפלט למטה הגיע מ-Docker 29.8.2 על Windows 11 עם Git Bash. הפקודות עובדות בכל shell של POSIX.

#שלב 1: לבדוק את Docker

docker --version
docker info --format '{{.ServerVersion}}'

הפלט שהתקבל:

Docker version 29.8.2, build 7fc2dff
29.8.2

#שלב 2: להפעיל את Juice Shop על loopback בלבד

docker run -d -p 127.0.0.1:3000:3000 bkimminich/juice-shop

הקידומת 127.0.0.1: מפרסמת את הפורט רק בממשק ה-loopback, ולכן מכונות אחרות לא יכולות להגיע אליו. במכונה שבה הרצתי את השלבים האלה כבר רץ קונטיינר מאותו image בשם juice-local, אז לא הפעלתי עוד אחד. כדי לבדוק מה רץ:

docker ps --format '{{.Names}} {{.Image}} {{.Ports}}'

השורה של Juice Shop מתוך הפלט שהתקבל:

juice-local bkimminich/juice-shop 127.0.0.1:3000->3000/tcp

#שלב 3: לבדוק שהאפליקציה עונה

curl -s -o /dev/null -w '%{http_code}\n' http://127.0.0.1:3000/
curl -s http://127.0.0.1:3000/rest/admin/application-version

הפלט שהתקבל:

200
{"version":"20.3.0"}

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

#שלב 4: לספור את האתגרים לפי קטגוריה

curl -s http://127.0.0.1:3000/api/Challenges/ -o challenges.json
python -c "import json,collections; d=json.load(open('challenges.json'))['data']; print(len(d)); [print(v,k) for k,v in sorted(collections.Counter(x['category'] for x in d).items())]"

הפלט שהתקבל:

116
12 Broken Access Control
4 Broken Anti Automation
9 Broken Authentication
5 Cryptographic Issues
12 Improper Input Validation
14 Injection
3 Insecure Deserialization
6 Miscellaneous
4 Observability Failures
5 Security Misconfiguration
3 Security through Obscurity
17 Sensitive Data Exposure
2 Unvalidated Redirects
9 Vulnerable Components
9 XSS
2 XXE

#שלב 5: לפתוח את לוח התוצאות

לפתוח בדפדפן את http://127.0.0.1:3000/#/score-board ולהשוות את הקטגוריות שלו למספרים שלמעלה. אם המספרים שונים, כדאי לרשום את גרסת Juice Shop.

#שלב 6: למפות שלוש קטגוריות ל-Top 10

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

למה כל שורה מתאימה:

• A01. הבקרה שקובעת מי יכול להגיע לאזור ניהול חסרה או שגויה, והאתגר מגדיר את האזור הזה כיעד.
• A05. הקטגוריה עוסקת בקלט לא מהימן שמגיע למפרש. התיאור לא מציין איזה מפרש, ולכן צריך לומר שההתאמה היא לקטגוריה ולא לטכניקה מסוימת.
• A02. פלט שגיאות וטיפול בהן הם החלטות תצורה. אותה התנהגות מתאימה גם ל-A10, כי CWE-209 רשום תחת A10 במהדורת 2025. צריך לציין איזה סעיף נבחר ולמה.

שמות הקטגוריות ב-Juice Shop הם תוויות של הפרויקט. קטגוריית ה-XSS שלו, למשל, ממופה ל-A05 ברשימת 2025. ממפים לפי שורש הבעיה ומציינים את ה-CWE.

#שלב 7: לעצור ולהסיר את המעבדה

docker ps --format '{{.Names}} {{.Image}}'
docker stop <container-name>
docker rm <container-name>

במקום <container-name> צריך לכתוב את השם מהפקודה הראשונה. הקונטיינר הופעל עם -d ובלי --rm, ולכן הוא נשאר בדיסק גם אחרי העצירה, עד שמסירים אותו.

#טעויות נפוצות

• לקרוא את הרשימה כשלמה. סיכונים רבים לא מופיעים בה כקטגוריה. כשצריך דרישות, פונים ל-ASVS.
• למפות לפי כותרת הבאג. ממפים לפי שורש הבעיה ומציינים את ה-CWE. כותרת כמו "XSS" מובילה ל-CWE, והקטגוריה נגזרת ממנו.
• לתקן את הדוגמה ולהשאיר את הדפוס. אם ה-endpoint של המחיקה בודק בעלות וה-endpoint של העדכון לא, A01 עדיין פתוח.
• לחשוף מעבדה. פרסום Juice Shop על 0.0.0.0 או על שרת בענן שם באינטרנט אפליקציה פגיעה בכוונה.
• לבדוק מחוץ למעבדה. סריקות וצעדי תקיפה מיועדים רק למערכות בבעלותך או כאלה שיש לך היתר לבדוק.
• לרשום סודות בלוג בזמן דיבוג. A09 כולל לוגים שמדליפים פרטי גישה, וזה קורה בקלות בזמן איתור תקלות.

#איך ממשיכים

• לקרוא את פרקי ASVS שמתאימים לקטגוריות שלך. לבקרת גישה, כדאי להתחיל ב-ASVS V8 Authorization.
• לקרוא את ה-Cheat Sheets שמופיעים בכל סעיף. הם קצרים ונכתבו בשביל מי שמממש את הבקרות.
• לפתוח את דפי ה-CWE של החולשות שקיימות בפועל בקוד שלך.
• בהמשך, לעבור על הסבר על SQL injection עם Juice Shop, שמעמיק בקטגוריית ה-Injection באותה מעבדה.

#מקורות

• OWASP Top 10:2025, https://owasp.org/Top10/ (מפנה אל https://top10.owasp.org/)
• OWASP Application Security Verification Standard, https://owasp.org/www-project-application-security-verification-standard/
• OWASP Cheat Sheet Series, https://cheatsheetseries.owasp.org/
• MITRE Common Weakness Enumeration, https://cwe.mitre.org/
• OWASP Juice Shop project, https://owasp.org/www-project-juice-shop/
• Docker port publishing, https://docs.docker.com/engine/network/port-publishing/