מידול איומים עם STRIDE: מודל ראשון של אפליקציית web

#מה זה STRIDE

STRIDE היא רשימה של שש קטגוריות איומים: spoofing, ‏tampering, ‏repudiation, ‏information disclosure, ‏denial of service ו-elevation of privilege. Microsoft משתמשת בה בהנחיות מידול האיומים שלה. STRIDE לא מוצאת איומים במקומך. היא נותנת שש שאלות לשאול על כל חלק בתכנון, כך שהתוצאה לא תלויה במה שבמקרה עולה בזיכרון באותו אחר צהריים.

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

#למה זה חשוב

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

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

#אבני הבניין

#דיאגרמות זרימת נתונים

בדיאגרמת זרימת נתונים (DFD) יש ארבעה סוגי רכיבים:

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

הדיאגרמה נשארת בעמוד אחד. אם צריך עמוד שני, כנראה שמצוירות בה שתי מערכות.

#גבולות אמון

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

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

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

כל קטגוריה שוברת תכונת אבטחה אחת.

אלה תואמים לתיאורים בתיעוד מידול האיומים של Microsoft. Spoofing, למשל, פירושו שימוש בפרטי האימות של משתמש אחר.

לא כל קטגוריה חלה על כל רכיב. מיפוי התחלתי נפוץ, שמשמש כלים רבים למידול איומים, הוא: ישויות חיצוניות מקבלות spoofing ו-repudiation; תהליכים מקבלים את כל השש; מאגרי נתונים מקבלים tampering, ‏repudiation, ‏information disclosure ו-denial of service; זרימות נתונים מקבלות tampering, ‏information disclosure ו-denial of service. המיפוי הוא נקודת התחלה לחשיבה. אם קטגוריה נראית לא רלוונטית לרכיב, כותבים למה, כדי שסוקר יוכל לערער על כך.

#איך זה עובד, שלב אחר שלב

1. מגדירים סקופ. כותבים משפט אחד שמציין את המערכת, את הגרסה ומה מחוץ לסקופ. "אפליקציית ה-web של Juice Shop וה-API שלה, בהרצה מקומית, ללא מערכת ההפעלה של המארח" מספיק.
2. מציירים את דיאגרמת זרימת הנתונים. מוסיפים את הישויות החיצוניות, התהליכים, מאגרי הנתונים והזרימות. מתייגים כל זרימה לפי מה שהיא נושאת.
3. מציירים את גבולות האמון. מעבירים קו בכל מקום שרמת האמון משתנה.
4. מעבירים כל רכיב דרך הקטגוריות. לכל קטגוריה רלוונטית שואלים את השאלה מהטבלה וכותבים את האיום במשפט קצר. מבנה שימושי הוא מי עושה מה ומה משתבש: "טוקן סשן גנוב מאפשר לתוקף לבצע הזמנות בשם הקונה."
5. בוחרים תגובה לכל איום: מיטיגציה, סיכון שמקבלים עם נימוק כתוב, או העברה לגורם אחר. איום בלי תגובה עדיין פתוח.
6. שומרים את המודל בניהול גרסאות ליד הקוד וקובעים תאריך לחזור אליו.

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

#תרגיל מעשי: מידול OWASP Juice Shop

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

מריצים את המעבדה רק על המחשב שלך, כשהיא קשורה לכתובת 127.0.0.1. אם הקונטיינר עוד לא הוקם, כדאי קודם לעבור על OWASP Juice Shop עם Docker.

#דרישות מקדימות

צריך:

• Docker, כדי להריץ את קונטיינר המעבדה
• Git, כדי לבצע commit למודל
• OWASP Threat Dragon בגרסת desktop, חינמי וקוד פתוח, מ-https://github.com/OWASP/threat-dragon/releases
• תיקייה ריקה ל-repository של המעבדה

במחשב הבדיקה של המאמר הזה, git --version הדפיס:

git version 2.49.0.windows.1

#שלב 1: הפעלת המעבדה

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

החלק -p 127.0.0.1:3000:3000 מפרסם את הפורט רק על ממשק ה-loopback, כך שמחשבים אחרים ברשת שלך לא יכולים להגיע אליו.

מוודאים שאפליקציית ה-web עונה:

curl -sI http://127.0.0.1:3000/ | head -n 1

במחשב הבדיקה, השורה הראשונה בפלט הייתה:

HTTP/1.1 200 OK

מוודאים שה-API עונה. זו בקשת GET פשוטה לרשימת מוצרים:

curl -s -o /dev/null -w "products %{http_code} %{content_type}\n" http://127.0.0.1:3000/api/Products

פלט:

products 200 application/json; charset=utf-8

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

curl -s http://127.0.0.1:3000/rest/admin/application-version

פלט:

{"version":"20.3.0"}

זו הגרסה שה-image דיווח עליה ב-8 בנובמבר 2026 במחשב הבדיקה. ה-image שלך עשוי לדווח על גרסה אחרת. כדאי לרשום את הגרסה שמופיעה אצלך, כי מודל האיומים מתאר גרסה מסוימת.

#שלב 2: התקנת Threat Dragon

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

#שלב 3: ציור הדיאגרמה

יוצרים מודל איומים חדש ומוסיפים את הרכיבים האלה:

• שחקן חיצוני בשם Browser, עם התיאור "הדפדפן של הקונה, מחוץ לשליטתנו".
• תהליך בשם Juice Shop web and API, עם התיאור "אפליקציית web ו-API בכתובת 127.0.0.1:3000".
• מאגר נתונים בשם SQLite database, עם התיאור "קובץ נתוני האפליקציה".
• שתי זרימות מהדפדפן לתהליך: בקשות HTTP, ותגובות HTTP בחזרה.
• שתי זרימות מהתהליך למאגר: שאילתות SQL, והשורות שחוזרות.
• גבול אמון שמפריד בין הדפדפן לבין התהליך והמאגר.

המודל אמור להיראות כך:

Browser (external actor)
   |  HTTP requests and responses
   v
=================== trust boundary ===================
   Juice Shop web and API (process, 127.0.0.1:3000)
   |  SQL queries and rows
   v
SQLite database (data store)

הסקיצה הטקסטואלית היא רק להכוונה. הקובץ האמיתי הוא מה ש-Threat Dragon שומר.

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

#שלב 4: רשימת איומים לכל רכיב

מחילים את המיפוי ההתחלתי שלמעלה. הדפדפן הוא ישות חיצונית, ולכן הוא מקבל spoofing ו-repudiation. כל זרימה מהדפדפן ל-API מקבלת tampering, ‏information disclosure ו-denial of service. תהליך ה-API מקבל את כל שש הקטגוריות. מאגר ה-SQLite מקבל tampering, ‏repudiation, ‏information disclosure ו-denial of service.

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

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

ב-Threat Dragon מוסיפים כל איום לרכיב שאליו הוא שייך, עם כותרת, תיאור ומיטיגציה. אם יש בגרסה שלך שדה סטטוס, מגדירים אותו ל-open עבור מיטיגציות שעוד לא נבנו.

#שלב 5: ייצוא ו-commit

מייצאים את המודל כ-JSON מתפריט הקובץ ונותנים לקובץ את השם juice-shop-threat-model.json. אחר כך, בתיקיית המעבדה:

git init
cp /path/to/juice-shop-threat-model.json .
git add juice-shop-threat-model.json && git commit -m "First STRIDE model"

Git מדפיס תקציר קצר עם שם ה-branch והודעת ה-commit. הטקסט המדויק תלוי בגרסת ה-Git ובהגדרות שלך. אם Git מבקש זהות, מגדירים את הזהות שלך עם git config user.name וגם git config user.email, ומבצעים commit בשם שלך.

לפני ה-commit קוראים את הקובץ. לא אמורים להיות בו שמות מארחים אמיתיים, טוקנים או נתוני לקוחות. המודל הזה משתמש רק בכתובת 127.0.0.1.

עוצרים את המעבדה בסיום:

docker stop juice-shop-lab
curl -s -o /dev/null -w "%{http_code}\n" --max-time 2 http://127.0.0.1:3000/

במחשב הבדיקה הפלט היה:

juice-shop-lab
000

השורה הראשונה היא הפלט של docker stop. הערך 000 אומר ש-curl לא קיבל תשובה מהפורט, כלומר המעבדה למטה.

#מודל איומים הוא מסמך חי

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

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

Threat Modeling Manifesto אומר שמידול איומים צריך ללכת בעקבות שינויי תכנון, באיטרציות, כל אחת על חלק של המערכת שאפשר לנהל. בפועל מדובר בשלושה הרגלים. שומרים את קובץ ה-JSON ב-repository ליד הקוד. מוסיפים שאלת סקירה ל-pull requests שנוגעים באימות, בזרימות נתונים או באינטגרציות חיצוניות: האם מודל האיומים עדיין תואם? רושמים את התאריך ואת גרסת האפליקציה שהמודל מתאר. איומים שסומנו כמטופלים הם עדיין היסטוריה שימושית, ולכן משאירים אותם.

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

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

#איך ממשיכים

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

#מקורות

• Microsoft: Threat modeling tool threats
• OWASP Threat Modeling Cheat Sheet
• OWASP Threat Dragon
• Threat Modeling Manifesto
• OWASP Juice Shop project
• Docker port publishing