לדלג לתוכן

תקיפת תהליכים מרובי שלבים - תרגול

תרגיל 1 - דילוג על שלב אימות (Apprentice)

מעבדה: 2FA simple bypass (PortSwigger)

רקע:
מערכת התחברות עם אימות דו-שלבי (2FA). המטרה: לדלג על שלב הזנת קוד ה-OTP ולגשת ישירות לחשבון.

שלבים:

  1. התחברו עם חשבון הבדיקה שלכם (wiener:peter) ועברו את כל תהליך ה-2FA
  2. שימו לב ל-URL אחרי השלמת ה-2FA (למשל /my-account)
  3. התנתקו
  4. התחברו עם פרטי הקורבן (carlos:montoya)
  5. כאשר אתם מגיעים לדף ה-2FA, במקום להזין קוד - נווטו ישירות ל-/my-account
  6. בדקו אם קיבלתם גישה ללא הזנת קוד OTP

שאלה: למה הדילוג עבד? מה השרת לא בדק?

תרגיל 2 - עקיפת 2FA באמצעות לוגיקה שבורה (Practitioner)

מעבדה: 2FA broken logic (PortSwigger)

רקע:
מערכת 2FA שבה ניתן לשנות את המשתמש בבקשת האימות. המטרה: להשתמש בקוד 2FA כדי לגשת לחשבון של משתמש אחר.

שלבים:

  1. התחברו עם החשבון שלכם ולכדו את כל הבקשות
  2. בדקו את בקשת האימות של ה-2FA:
POST /login2 HTTP/1.1
Cookie: verify=wiener

mfa-code=123456
  1. שימו לב לפרמטר verify ב-cookie - הוא קובע לאיזה משתמש מוצמד הקוד
  2. שנו את הערך ל-verify=carlos
  3. שלחו בקשת ה-2FA עם bruteforce על קוד ה-OTP (4 ספרות):
POST /login2 HTTP/1.1
Cookie: verify=carlos

mfa-code=0000
mfa-code=0001
...
  1. השתמשו ב-Burp Intruder עם payload מספרי 0000-9999

תרגיל 3 - שינוי פרמטרים בין שלבים (Practitioner)

מעבדה: Insufficient workflow validation (PortSwigger)

רקע:
חנות מקוונת עם תהליך רכישה מרובה שלבים. המטרה: לרכוש מוצר ללא תשלום.

שלבים:

  1. רכשו מוצר זול שהיתרה שלכם מספיקה לו ולכדו את כל הבקשות
  2. מפו את תהליך הרכישה:
  3. הוספה לעגלה
  4. מעבר לתשלום
  5. אישור הזמנה
  6. זהו את בקשת האישור הסופית
  7. הוסיפו את המוצר היקר לעגלה
  8. שלחו ישירות את בקשת האישור (שלכדתם בשלב 2)
  9. בדקו אם ההזמנה עברה ללא תשלום

רמז: הבקשה הסופית כנראה POST /cart/order-confirmation.

תרגיל 4 - מניפולציית תהליך שינוי סיסמה (Practitioner)

מעבדה: Password reset broken logic (PortSwigger)

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

שלבים:

  1. בקשו איפוס סיסמה לחשבון שלכם
  2. לחצו על הלינק ב-email ולכדו את בקשת שינוי הסיסמה:
POST /forgot-password?temp-forgot-password-token=TOKEN HTTP/1.1

temp-forgot-password-token=TOKEN&username=wiener&new-password-1=pass&new-password-2=pass
  1. שימו לב שה-username נשלח כפרמטר
  2. שנו את ה-username ל-carlos
  3. שלחו את הבקשה
  4. נסו להתחבר כ-carlos עם הסיסמה החדשה

שאלה: מה השרת היה צריך לבדוק ולא בדק?

תרגיל 5 - ניצול תהליך שינוי email (Practitioner)

רקע:
אפליקציה שבה שינוי email דורש אימות באמצעות לינק שנשלח ל-email הישן. המטרה: לשנות את ה-email ללא אימות.

שלבים:

  1. בצעו שינוי email רגיל ולכדו את כל הבקשות
  2. מפו את התהליך:
שלב 1: POST /profile/change-email {"newEmail": "new@example.com"}
שלב 2: לינק אימות נשלח ל-email הישן
שלב 3: GET /verify-email-change?token=abc123
שלב 4: ה-email מתעדכן
  1. נסו לגשת ישירות לשלב 4 ללא עקיפת שלב 2
  2. נסו לשנות את ה-email בבקשה אחרת:
PUT /api/profile HTTP/1.1
Content-Type: application/json

{"email": "attacker@evil.com"}
  1. בדקו אם יש נקודת קצה נוספת שמאפשרת עדכון email ללא אימות

תרגיל 6 - תקיפת שידור חוזר על תשלום (Practitioner)

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

שלבים:

  1. בצעו העברת כספים והעבירו סכום קטן (1 דולר)
  2. לכדו את בקשת האישור:
POST /transfer/confirm HTTP/1.1

token=abc123&amount=1&recipient=carlos
  1. שלחו את הבקשה שוב - האם ההעברה מתבצעת פעם נוספת?
  2. שלחו שוב ושוב
  3. בדקו את היתרה של הנמען - האם היא עלתה?

שאלה: מה ההבדל בין תקיפה זו לבין תנאי מרוץ? מתי משתמשים בכל טכניקה?

תרגיל 7 - עקיפת מנגנון אישור הזמנה (Expert)

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

שלבים:

  1. מפו את כל תהליך הרכישה (4-5 שלבים)
  2. בדקו כל שלב בנפרד:
  3. האם אפשר לדלג עליו?
  4. האם אפשר לשנות פרמטרים?
  5. האם אפשר לשדר מחדש?
  6. נסו את השילובים הבאים:
  7. הוספת מוצר זול, תשלום, שינוי המוצר ליקר, אישור
  8. דילוג על שלב התשלום ישירות לאישור
  9. שינוי הסכום בבקשת התשלום
  10. מצאו את השילוב שעובד

רמזים:
- שימו לב לסדר הבקשות וליחסים ביניהן
- בדקו מה נשמר ב-session ומה נשלח כפרמטר
- נסו לפתוח שני חלונות מקבילים

תרגיל 8 - ניתוח תהליך ותכנון תקיפה (Expert)

לפניכם תרשים של תהליך רכישה. תכננו תקיפה עבור כל וקטור אפשרי:

[לקוח]
    |
    v
POST /cart/add (productId, quantity)
    |
    v
POST /cart/apply-coupon (code)      <-- שלב אופציונלי
    |
    v
POST /checkout/start
    |
    v
POST /checkout/address (address)
    |
    v
POST /checkout/payment (cardDetails, amount)
    |
    v
POST /checkout/confirm (paymentToken)
    |
    v
[הזמנה נוצרת]

משימות:

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

שאלות נוספות:
- מה ההבדל בין נעילת העגלה לבין יצירת snapshot?
- למה טוקן חתום (HMAC) עדיף על מעקב session?
- איך תנאי מרוץ משתלב עם תקיפות מרובות שלבים?