תקיפת OAuth 2.0 - תרגיל¶

תרגיל 1: מניפולציית Redirect URI¶

רקע¶

אפליקציה מאפשרת התחברות באמצעות OAuth. השרת בודק שה-redirect_uri שייך לדומיין של האפליקציה, אך הבדיקה אינה מדויקת.

משימות¶

היכנסו לאפליקציה וזהו את זרימת ה-OAuth
יירטו את בקשת ה-authorize עם Burp
נסו לשנות את ה-redirect_uri לכתובת חיצונית
אם נחסם - נסו את טכניקות העקיפה הבאות:
הוספת path אחרי ה-callback (/callback/../something)
שימוש ב-subdomain (evil.app.com)
קידוד URL כפול
הוספת פרמטרים נוספים
גנבו את ה-authorization code באמצעות ה-exploit server
החליפו אותו בטוקן והשתלטו על חשבון האדמין

מעבדת PortSwigger¶

בצעו את המעבדות:
- Authentication bypass via OAuth implicit flow
- Forced OAuth profile linking
- OAuth account hijacking via redirect_uri

תרגיל 2: CSRF ב-OAuth - חוסר פרמטר State¶

רקע¶

אפליקציה מאפשרת לקשר חשבון OAuth חיצוני לחשבון הקיים, אך לא משתמשת ב-state parameter.

משימות¶

צרו חשבון באפליקציה והתחברו
התחילו את תהליך קישור חשבון OAuth
יירטו את ה-callback עם ה-authorization code
אל תשלימו את התהליך - שמרו את ה-callback URL
שלחו את ה-callback URL לקורבן (הנחה: הקורבן מחובר לאפליקציה)
כאשר הקורבן לוחץ, חשבונו מקושר לחשבון ה-OAuth שלכם
התחברו עם חשבון ה-OAuth שלכם וקיבלו גישה לחשבון הקורבן

כתבו payload¶

<!-- השלימו את ה-HTML שישלח לקורבן -->
<html>
<body>
    <!-- iframe/img שיפעיל את ה-callback -->
</body>
</html>

תרגיל 3: דליפת טוקן דרך Open Redirect¶

רקע¶

אפליקציה מאמתת שה-redirect_uri מצביע על הדומיין שלה, אך יש בה open redirect.

משימות¶

מצאו open redirect באפליקציה (סרקו עם Burp)
שרשרו את ה-open redirect עם ה-redirect_uri של OAuth
השתמשו ב-implicit flow כדי לגנוב את הטוקן ב-fragment
הקימו שרת שקולט את הטוקן
בצעו את התקיפה על הקורבן

שאלות¶

מדוע open redirect הוא כל כך מסוכן בהקשר של OAuth?
איך fragment (#) מתנהג לעומת query parameter (?) בהפניות?
האם PKCE מגן מפני תקיפה זו? הסבירו.

מעבדת PortSwigger¶

בצעו את המעבדה:
Stealing OAuth access tokens via an open redirect

תרגיל 4: ניצול Scope ו-Profile Information¶

רקע¶

אפליקציה משתמשת ב-OAuth להתחברות ושולפת פרטי משתמש מהספק. השרת סומך על המידע שמגיע מהספק ללא אימות נוסף.

משימות¶

התחברו עם חשבון OAuth
בדקו אילו שדות האפליקציה מקבלת מהספק (email, name, role)
בדקו אם ניתן לשנות את הפרטים בספק ה-OAuth
שנו את ה-email לזה של האדמין
התחברו מחדש ובדקו אם קיבלתם גישה לחשבון האדמין

מעבדת PortSwigger¶

בצעו את המעבדה:
SSRF via OpenID dynamic client registration

תרגיל 5: PKCE Downgrade¶

רקע¶

אפליקציה מיישמת PKCE, אך שרת ה-OAuth לא דורש אותו באופן מחייב.

משימות¶

יירטו את זרימת ה-OAuth וזהו את השימוש ב-PKCE
שלחו בקשת authorize חדשה ללא code_challenge
בדקו אם השרת מקבל את הבקשה ללא PKCE
גנבו authorization code (באמצעות redirect_uri manipulation)
החליפו אותו בטוקן ללא צורך ב-code_verifier

תרגיל 6: סקריפט סריקת OAuth¶

כתבו סקריפט Python שמבצע את הבדיקות הבאות באופן אוטומטי:

# השלימו את הסקריפט
import requests

class OAuthScanner:
    def __init__(self, authorize_url, token_url, client_id, redirect_uri):
        self.authorize_url = authorize_url
        self.token_url = token_url
        self.client_id = client_id
        self.redirect_uri = redirect_uri

    def check_state_required(self):
        """בדיקה אם state נדרש"""
        # ...
        pass

    def check_redirect_uri_validation(self):
        """בדיקת אימות redirect_uri"""
        # נסו וריאציות שונות
        # ...
        pass

    def check_pkce_required(self):
        """בדיקה אם PKCE נדרש"""
        # ...
        pass

    def check_scope_validation(self):
        """בדיקה אם scope מאומת"""
        # ...
        pass

    def run_all_checks(self):
        """הרצת כל הבדיקות"""
        self.check_state_required()
        self.check_redirect_uri_validation()
        self.check_pkce_required()
        self.check_scope_validation()

הסקריפט צריך לבדוק¶

האם state parameter נדרש
האם redirect_uri מאומת (ואם כן - כמה בחוזקה)
האם PKCE נדרש
האם ניתן לבקש scope מורחב
האם authorization code חד-פעמי
האם ניתן לבצע token exchange ללא client_secret

תרגיל 7: תקיפת OAuth מלאה¶

תרחיש¶

נתונה אפליקציה שמאפשרת התחברות עם Google OAuth. בצעו את השלבים הבאים:

מפו את זרימת ה-OAuth המלאה (כל הבקשות והתגובות)
זהו את סוג הזרימה (Authorization Code / Implicit)
בדקו את כל נקודות התורפה שלמדנו
תעדו כל ממצא עם דוגמת בקשה ותגובה
הציעו תיקונים לכל חולשה שמצאתם

דוח¶

הגישו דוח שכולל:
- תרשים זרימה של ה-OAuth flow
- רשימת חולשות שנמצאו
- PoC (הוכחת יתכנות) לכל חולשה
- המלצות תיקון