Hamada Khairy — منهجية Access Control Violations

// 00 — VIDEO OVERVIEW

شرح فيديو كامل للمنهجية

شاهد شرح الفيديو الكامل لمنهجية الـ Access Control وكيفية اكتشاف الثغرات عملياً.

▶ VIDEO RUNTIME: COMPLETE WALKTHROUGH OPEN ON YOUTUBE ↗

// 01 — المبدأ الأساسي

IDOR vs Access Control — الفرق الحقيقي

الاتنين بيودوا لنفس النتيجة — بس السبب مختلف تماماً. وفهم الفرق ده هو اللي بيخليك تغطي الـ attack surface كاملة.

◆ ◇ ◆

الجانب	IDOR — Indirect Object Reference	Access Control Violation
الـ Failure	التطبيق مش بيتحقق من ملكية الـ object — هل الـ ID ده بتاعك؟	التطبيق مش بيتحقق من صلاحية الـ mechanism — هل الـ role بتاعك يسمحلك؟
السؤال الأساسي	هل الـ object ID ده بتاعي؟	هل الـ role بتاعي مسموحله يستخدم الـ mechanism ده؟
نوع الـ Bypass	تغيير الـ identifier (ID, UUID, email...)	استخدام mechanism مش مفروض يكون متاح لـ role بتاعك
مثال	GET /order?id=1001 → id=1002	GET /admin/export-users (as regular user)
الـ Accounts	حسابين بنفس الـ role (A1 و A2)	حسابين بـ roles مختلفة (Admin و User)
الـ Automation	صعب — محتاج context + IDs محددة	صعب جداً — محتاج معرفة الـ roles وكل mechanism
الـ CWE	CWE-639	CWE-284 / CWE-285
الإصلاح	WHERE id=? AND owner_id=current_user	IF current_role NOT IN allowed_roles → 403

// SCRIPT — ليه الفرق ده مهم عملياً؟0:00 – 5:00

كتير من الـ researchers بيخلطوا بين الاتنين وبيفتكروا إنهم بيغطوا كل الـ attack surface. الحقيقة هي إنهم بيضيعوا نص الـ bugs.

لو قدرت تغير ID في الـ request وشفت data حد تاني — ده IDOR. بس لو كـ regular user وصلت لـ admin endpoint أو عملت operation مفروضة بس للـ admin — ده Access Control Violation.

💡 ممكن في نفس الـ application يكون في الاتنين. الـ admin endpoint يكون vulnerable لـ Access Control Violation، وجواه يكون في IDOR. لازم تغطيهم مع بعض مش منفصلين.

الـ Access Control Violations هي أصعب من الـ IDOR من ناحية: إنت محتاج تعرف كل mechanism في التطبيق، وكل role، وإيه اللي المفروض كل role يعمله. من غير المعرفة دي، مش هتلاقي حاجة.

// 02 — التصنيف الكامل

أنواع الـ Access Control Violations

مش نوع واحد — في 5 أنواع مختلفة كل واحد ليه methodology مختلفة.

◆ ◇ ◆

TYPE 01 — Unauthenticated → Authenticated

الأبسط — الأكثر شيوعاً

Unauthenticated user يوصل لـ endpoint مفروض يكون مقفول. الـ barrier بين الـ logged-out وlogged-in state.

// EXAMPLE GET /api/dashboard/stats // No Authorization header // Expected: 401 Unauthorized // Vulnerable: 200 OK + data leaked

🔓 ANON → 👤 AUTH USER

TYPE 02 — Horizontal Role Escalation

نفس المستوى — permissions مختلفة

User A يعمل operations بتاعة User B — نفس الـ role بس account مختلف. ده بيتداخل مع الـ IDOR في بعض الأحيان.

// EXAMPLE POST /api/team/5002/settings // Logged in as User 5001 // Expected: 403 Forbidden // Vulnerable: 200 OK — changed team 5002

👤 USER A → 👤 USER B

TYPE 03 — Vertical Privilege Escalation

أخطر نوع — الـ impact الأعلى

Regular user يوصل لـ Admin functionality. ده هو الـ jackpot في الـ Access Control testing.

// EXAMPLE GET /admin/users/export // Logged in as regular Developer // Expected: 403 Forbidden // Vulnerable: 200 OK + all users CSV

👤 DEVELOPER → 👑 ADMIN PANEL

TYPE 04 — Function-Level Access Control

الـ Granular Role Bypass

في الـ application روله معين مسموحله يعمل READ بس مش UPDATE. لو قدر يبعت UPDATE request وينجح — ده function-level violation.

// EXAMPLE — Viewer role tries to UPDATE PUT /api/documents/5001 // Role: Viewer (allowed: read only) // Expected: 403 Forbidden // Vulnerable: 200 OK — document modified!

👁 VIEWER → ✏️ EDITOR

TYPE 05 — GraphQL Operation-Level Access Control

الـ Modern Challenge — GraphQL Endpoints

كل الـ requests بتروح لـ endpoint واحد: /graphql. الـ authorization بيتعمل على مستوى الـ operation مش على مستوى الـ URL. ده بيغير كل الـ methodology.

// TRADITIONAL REST — easy to test GET /api/admin/users ← blocked for user POST /api/admin/export ← blocked for user DELETE /api/admin/user/5 ← blocked for user // Each endpoint = separate auth check

// GRAPHQL — one endpoint, many operations POST /graphql ← ALL requests here // Operation 1 (allowed for all): {"query": "{ getCurrentUser { id } }"} // Operation 2 (admin only): {"query": "mutation { exportUsers { csv } }"} // Same URL — different authorization needed!

// SCRIPT — ليه الـ Complex Roles هي الـ Goldmine؟5:00 – 10:00

كل ما زادت عدد الـ roles وزادت الـ granularity، زادت فرصتك. لو التطبيق فيه بس Admin وUser — ده بسيط نسبياً. بس لو فيه Admin → Team Lead → Developer → Viewer → Auditor → External — ده 6 levels من الـ permissions، وكل level فيها عشرات الـ mechanisms.

المطور اللي بيبني الـ system ده مش مسؤول بس عن الـ features — هو لازم يتأكد إن كل mechanism بيتاكد من كل role بالظبط. ده بالإضافة للـ deadlines والـ pressure.

⚠️ "It becomes almost impossible for the developers to accurately implement that across the board." — Arson. لو إنت كـ researcher شغال بمنهجية صح، هتلاقي الـ edge cases دي قبل ما الـ dev team يلاقيها.

الـ Auditor role هو أحسن مثال: مسموحله يقرأ كل حاجة بس مش يعدل أو يحذف. الـ read-only بالنسبة للمطور = permissions كتير + restrictions كتير = كذا فرصة للـ mistake.

// 03 — اختيار الـ Target

اختيار البرنامج الصح للـ RBAC

مش كل برنامج مناسب لـ Access Control testing. في معايير خاصة مختلفة عن الـ IDOR.

◆ ◇ ◆

✦ IDEAL TARGET

Core Multiple user roles (3+)
Core Granular permissions per role
Core Collaboration/team features
Core Workspace/org concept
Core Self-service registration
Bonus Auditor/external role
Bonus Low bounty = less competition
Bonus CMS / SaaS platform

🎯 PERFECT EXAMPLES

Project management tools (Jira-like)
Website hosting platforms (Pantheon)
Collaboration SaaS (Notion-like)
Cloud dashboards (AWS/GCP programs)
CMS platforms (WordPress hosting)
Dev tools with team features
Bug bounty platforms نفسهم
Medical / Government platforms

❌ AVOID FOR RBAC

Single-user apps (no teams)
Static content sites
Apps with only user/admin (2 roles)
Programs without authenticated testing
Apps without role documentation
Extremely simple CRUD apps
Games / entertainment apps

// SCRIPT — لماذا Pantheon كان الاختيار الصح10:00 – 18:00

Arson اختار Pantheon لسببين رئيسيين. الأول هو الـ granular roles: Admin، Team Member، Developer، وUnprivileged. الثاني هو إن الـ bounties منخفضة — $0 لـ P3/P4 — وده بالتحديد هو الـ advantage.

🎯 البرامج بالـ bounties المنخفضة هي أقل في المنافسة. الـ experienced researchers بيتجنبوها. وده بيديك وقت تعمل testing عميق من غير ما تتقلق من duplicates.

الحاجة التانية المهمة: Pantheon منصة collaboration — ده بيعني في concept الـ workspace وفيه multiple users في نفس الـ workspace بـ roles مختلفة. ده بالظبط اللي محتاجه لـ RBAC testing.

لما بتلاقي في الـ program documentation جدول بيشرح إيه اللي كل role يقدر يعمله — ده الـ gift المجاني. إنت بتعرف بالظبط إيه اللي المفروض يتبعت للـ server وإيه اللي المفروض يترفض.

معيار التقييم	ليه مهم؟	كيف تتحقق منه؟	Score
عدد الـ roles (3+)	كل role إضافية = exponential complexity = أكتر bugs	الـ documentation / signup flow / team settings	HIGH
Permission table موجود	بيديك الـ blueprint بتاع الـ testing	دور على صفحة pricing أو features comparison	HIGH
Workspace/Org concept	بيعني في multi-tenant isolation = بيزيد الـ attack surface	دور على "Create team" أو "Invite members"	CRITICAL
Self-registration لكل role	بدونها مش هتقدر تعمل accounts بـ roles مختلفة	حاول تعمل account مع كل role	MUST
Low bounty ($0-500)	less competition = أكتر bugs متاحة	شوف الـ rewards table في الـ program	ADVANTAGE
Auditor/External role	الـ role ده دايماً complex ومليان edge cases	دور في الـ role settings على "read-only" أو "auditor"	BONUS

// 04 — فهم الـ Roles

Role Mapping — قبل ما تبدأ أي testing

لازم تفهم كل role: إيه اللي تقدر تعمله، وأهم من كده — إيه اللي مش المفروض تعمله.

◆ ◇ ◆

// SCRIPT — The Role Map is Your Test Plan18:00 – 28:00

أول ما تدخل التطبيق وتلاقي جدول الـ roles، إنت بتشوفه زي الـ treasure map. كل "NO" في الجدول ده هو target محتمل لـ Access Control violation.

مش بس تعرف إيه اللي كل role يقدر يعمله — لازم تفهم ليه الـ role ده اتعمل. الـ Developer role مثلاً: الـ developer شغله يكتب الكود مش يعمل deployment. لو تقدر تعمل deployment كـ developer — ده impact كبير لأنك ممكن تعمل deploy لـ backdoor.

📋 دور في الـ application على: Settings → Team → Roles / Members → Permissions. كمان pricing pages بتحتوي permission comparison tables كتير.

// ROLE MAPPING NOTE TEMPLATE — PANTHEON EXAMPLE

## Roles ### Admin Purpose: Full workspace management Can do: ALL mechanisms Testing: ← skip (baseline — can do everything) Focus on: mechanisms admin CAN do that others CANNOT ### Team Member Purpose: DevOps / infrastructure management Can do: Deploy, test, manage sites, invite users CANNOT do: Delete sites, remove users, create custom upstreams Mechanisms to test: → DELETE /site/{id} ← team member should get 403 → DELETE /workspace/users/{id} ← team member should get 403 → POST /upstreams/custom ← team member should get 403 → GET /workspace/export-csv ← team member should get 403 → PUT /users/{id}/role ← team member should get 403 ### Developer Purpose: Write code only Can do: Access dashboard, work in environments, create sites CANNOT do: Deploy, test live, manage team, create upstreams Mechanisms to test: → POST /deploy ← developer should get 403 ⭐ HIGH IMPACT → POST /test-live ← developer should get 403 → PUT /workspace/team/manage ← developer should get 403 → POST /upstreams/custom ← developer should get 403 [+ everything team member cannot do] ### Unprivileged (Unknown Role) Purpose: ❓ unclear — possibly read-only external auditor? Can do: Create sites (only) CANNOT do: Almost everything Testing priority: HIGHEST — most restrictions = most potential violations First target: → GET /workspace/dashboard ← can they even see this?

Mechanism	ADMIN	TEAM MEMBER	DEVELOPER	UNPRIVILEGED	TEST PRIORITY
View Dashboard	✓	✓	✓	?	MEDIUM
Invite Users	✓	✓	✗	✗	HIGH
Remove Users	✓	✗	✗	✗	CRITICAL
Change User Role	✓	✗	✗	✗	CRITICAL
Export Members CSV	✓	✗	✗	✗	HIGH
Deploy Live	✓	✓	✗	✗	CRITICAL
Test Live	✓	✓	✗	✗	CRITICAL
Create Custom Upstream	✓	✗	✗	✗	HIGH
Delete Site	✓	✗	✗	✗	CRITICAL
Create Site	✓	✓	✓	✓	SKIP

✦ الصفوف اللي فيها ✗ لـ roles متعددة هي الـ targets. كل ✗ = potential Access Control Violation.

// 05 — رسم خريطة البيئة

Environment Mapping — ابدأ بالصورة الكبيرة

قبل ما تبدأ الـ testing، إنت لازم تفهم التطبيق من الخارج للداخل — زي ما بتقسم العالم لقارات.

◆ ◇ ◆

// SCRIPT — كيف تبني Mental Model للتطبيق28:00 – 40:00

الطريقة بتاعت Arson: ابدأ بالـ Environments (= القارات). كل environment هو تطبيق منفصل ليه الـ mechanisms والـ roles بتاعته. في Pantheon، عندنا Personal Workspace وTeam Workspace.

بعدين جوا كل environment، عندنا الـ Mechanisms (= المدن). كل mechanism هو operation ممكن تعمله في الـ application: deploy، delete، export، إلخ.

🗺️ "It's almost like if you're looking at a picture of the world right, the first thing we want to do is we want to divide the world up into continents." — Arson

أهم اكتشاف في الـ Pantheon testing: في الأول ظن إن في بيئتين مختلفتين تماماً. بعد كده اكتشف إنهم نفس الـ application بـ features مختلفة حسب النوع. ده غيّر كل الـ testing approach.

🚨 لو بنيت mental model غلط للتطبيق، هتضيع ساعات في الـ testing على assumptions خاطئة. خد وقتك في الـ exploration phase.

// ENVIRONMENT MAPPING TEMPLATE

# [TARGET] — ACCESS CONTROL TESTING ## Environments ### Environment 1: Personal Workspace Type: Single-user workspace Roles: Admin only (creator) RBAC target: LOW — no role granularity Notes: Can CREATE team workspace from here Has: personal settings, sites, billing ### Environment 2: Team/Professional Workspace Type: Multi-user collaborative workspace Roles: Admin, Team Member, Developer, Unprivileged RBAC target: HIGH ⭐ — primary testing environment Notes: Team workspace name must be unique (slug) Role granularity documented in permissions table Most requests go through GraphQL endpoint ## Key Observations 1. [OBS] Personal vs Team = same app, different features (not different apps!) 2. [OBS] All major operations go through /graphql endpoint 3. [OBS] Additional traditional API found: /api/v1/* (site creation) 4. [OBS] Upstreams feature only available in Team workspace 5. [?] Does personal workspace user have admin-equivalent role?

إزاي تعمل Environment Exploration صح

1

اعمل account وافتح Burp

Scope = target domain فقط. افتح كل صفحة واعمل كل action وهمي عشان تملي الـ sitemap.

2

ابحث عن "Team" أو "Workspace"

أي حاجة بتقول "Invite members"، "Create team"، "Manage roles" — ده هو الـ RBAC entry point.

3

افتح الـ Settings كامل

كل section في الـ settings ممكن يحتوي على mechanisms للـ testing. حتى الـ billing وSSH keys.

4

ابحث عن الـ Permission Table

في الـ docs، الـ pricing page، أو الـ signup flow. ده هو الـ gold — بيديك الـ test plan مجاناً.

الحاجات اللي لازم تدوّنها في الـ Notes

Env كل environment/workspace موجود في التطبيق
Roles كل role وlist بالـ permissions الخاصة بها
Diff الفروقات بين الـ environments
Bug? أي mechanism غير واضح — هل مسموح بيه ولا لأ؟
Q أسئلة محتاج تجاوب عليها أثناء الـ testing
Tech الـ tech stack (REST vs GraphQL vs gRPC)
Auth كيفية الـ authentication في كل environment
Target أعلى priority mechanisms لاختبارها

// 06 — إعداد الحسابات

حساب لكل Role — مش حسابين بس

في الـ IDOR عندك حسابين. في الـ RBAC عندك حساب لكل role موجودة في التطبيق.

◆ ◇ ◆

I

الـ Workspace Creator = Admin

الأول تعمل الـ workspace — إنت أصبحت admin تلقائياً. ده الـ admin account. من هنا بتدعو الـ roles التانية.

II

Plus Notation لكل Role

استخدم you+admin@hackerone.com، you+teammember@، you+developer@. بدل الأرقام (demo1, demo2) — استخدم اسم الـ role مباشرة. ده بيخليك دايماً عارف إنت شغال بأنهو account.

III

Activate في Browsers مختلفة

Admin في normal Firefox. Team Member في Incognito. Developer في Burp's Browser. لو في role رابعة، استخدم Chrome. الـ goal: كل session منفصلة تماماً.

IV

وثق Session Tokens كل Role

كل account بعد login: افتح Burp → proxy → اعمل أي action → جيب الـ session token من الـ cookies. وثقه في الـ notes مع اسم الـ role بتاعه.

V

تحدي الـ Incognito Sharing

Firefox Incognito windows بتشارك نفس الـ session! الحل: استخدم Burp browser كـ third window — بيعمل session منفصلة تماماً لأنه مستقل عن الـ OS browser.

// ACCOUNTS SECTION — RBAC VERSION

## Accounts ### Admin (Workspace Creator) Email: you+admin@bugcrowd.ninja Session: ABC123DEF... ← get from browser storage or Burp Browser: Firefox normal Can do: EVERYTHING — baseline ### Team Member Email: you+teammember@bugcrowd.ninja Session: XYZ789GHI... Browser: Firefox Incognito Testing: Can they do what only Admin should do? ### Developer Email: you+developer@bugcrowd.ninja Session: JKL456MNO... Browser: Burp Browser Testing: Can they deploy? Can they manage team? Can they export? ### Unprivileged (if accessible) Email: you+unprivileged@bugcrowd.ninja Session: PQR789STU... Status: Note: Server may reject — test client-side vs server-side Testing: HIGHEST PRIORITY — most restrictions = most potential bugs

// SCRIPT — مشكلة إدارة الـ Roles أثناء الـ Testing40:00 – 50:00

أصعب حاجة في الـ RBAC testing هو إنك تتأكد دايماً إنك شغال بالـ session الصح. Arson ذكر إنه اتفتح على account غلط أكتر من مرة أثناء الـ recording.

👥 الحل الأمثل: اعمل الـ testing مع group من 3-4 persons. كل واحد يأخد role. لما تلاقي mechanism بتقول لـ admin "أنا لقيت إن developer قدر يعمل X — تقدر تعملها؟" ده بيسرع الـ testing ضعف.

لو بتعمل solo testing: خلي قاعدة ثابتة — دايماً اعمل screenshot للـ URL والـ session في كل browser قبل ما تبدأ أي test. ده بيمنع الـ confusion.

// 07 — جرد الـ Mechanisms

Mechanism Inventory — اعرف كل حاجة ممكن تعملها

قبل ما تبدأ تهاجم، إنت لازم تعمل inventory كامل لكل mechanism في التطبيق.

◆ ◇ ◆

// SCRIPT — ليه الـ Inventory ده مش Boring بل ضروري50:00 – 60:00

الـ Mechanism Inventory هو الفرق بين researcher بيلاقي bugs وراسرcher بيلف. إنت بتعمل map كاملة للتطبيق، وبعدين بتهاجم كل نقطة فيها بالترتيب.

في Pantheon، الـ inventory بدأ من الـ permission table الموجودة في الـ documentation. بعدين Arson اكتشف mechanisms إضافية من خلال الـ testing نفسه — زي الـ change user role والـ export members CSV اللي مش كانوا في الـ original table.

💡 الـ granularity بتيجي من الـ application نفسه. الـ permission table بيقولك "modify user" — بس لما تدخل التطبيق بتلاقي إن في "change role" و"remove user" وده بيزود الـ testing surface بضعف.

// MECHANISM INVENTORY — FULL TEMPLATE

## Mechanisms ### Team Management INVITE USER = POST → /api/workspace/members ← GraphQL: inviteUser mutation REMOVE USER = DELETE → /api/workspace/members/{id} ← GraphQL: removeMember mutation CHANGE USER ROLE = PUT → /api/workspace/members/{id}/role ← GraphQL: updateMemberRole ⭐ HIGH VALUE EXPORT MEMBERS = POST → /graphql {triggerWorkspaceExport} ← Admin ONLY target ### Site Management CREATE SITE = POST → /api/v1/sites ← ALL roles — skip DELETE SITE = DELETE → /api/v1/sites/{id} ← Admin only target ⭐ DEPLOY LIVE = POST → /api/v1/sites/{id}/deploy ← Team Member+ ONLY ⭐⭐ HIGH IMPACT TEST LIVE = POST → /api/v1/sites/{id}/test ← Team Member+ ONLY ### Configuration CREATE UPSTREAM = POST → /graphql {createCustomUpstream} ← Admin only target ⭐ WORKSPACE SETTINGS= GET/PUT → /graphql {workspaceSettings} ← investigate read vs write ## Testing Queue (Priority Order) 1. CRITICAL: triggerWorkspaceExport — test with: TeamMember, Developer 2. CRITICAL: deploy + test live — Developer should get 403 3. CRITICAL: updateMemberRole — TeamMember + Developer should get 403 4. HIGH: createCustomUpstream — TeamMember + Developer should get 403 5. HIGH: removeMember — TeamMember + Developer should get 403 6. MEDIUM: all READ operations — check with each role

// 08 — CRUD × Role

CRUD per Role — الـ Matrix الكاملة

كل mechanism بيتقسم لـ CRUD operations — وكل operation ليها authorization requirement مختلف.

◆ ◇ ◆

ليه الـ CRUD Granularity مهمة في RBAC؟

المطور ممكن يتذكر يمنع الـ DELETE لكن ينسى الـ UPDATE. أو يمنع الـ POST لكن ينسى إن الـ PATCH بيعمل نفس الشيء.

// DEVELOPER ROLE — what to test // Allowed: GET /api/v1/sites ← list sites (OK) GET /api/v1/sites/{id} ← view site (OK) // Blocked (should be): POST /api/v1/sites/{id}/deploy ← 403? POST /api/v1/sites/{id}/test ← 403? PUT /api/v1/workspace/settings ← 403? DELETE /api/v1/sites/{id} ← 403? PUT /api/v1/members/{id}/role ← 403?

الـ HTTP Method Switching Trick

بعض الـ servers بيطبق الـ authorization على HTTP method معينة بس. جرب نفس الـ endpoint بـ methods مختلفة.

// METHOD SWITCHING — same endpoint GET /api/v1/users/export ← 403 (blocked) POST /api/v1/users/export ← 200?? (forgotten) PUT /api/v1/users/export ← 200?? (different code path) OPTIONS /api/v1/users/export ← reveals allowed methods // Also try: GET /api/V1/users/export ← case sensitivity bypass GET /api/v1/users/export/ ← trailing slash bypass GET /api/v1/users/export; ← semicolon bypass

Object / Resource	CREATE	READ	UPDATE	DELETE	WHO CAN DO ALL?	RBAC TEST?
Site	ALL roles	ALL roles	Admin+TM	Admin only	ADMIN	YES — DEL
Deployment	Admin+TM	ALL roles	Admin+TM	Admin+TM	TEAM MEMBER	YES — ALL
Workspace Member	Admin+TM	ALL roles	Admin only	Admin only	ADMIN	CRITICAL
Member Role	N/A	ALL roles	Admin only	N/A	ADMIN	CRITICAL
Custom Upstream	Admin only	Admin+TM	Admin only	Admin only	ADMIN	YES
Member Export	N/A	Admin only	N/A	N/A	ADMIN	YES — EASY
Workspace Settings	N/A	ALL roles	Admin only	N/A	ADMIN	MEDIUM

// 09 — التحدي الحديث

GraphQL — كل الـ Requests في مكان واحد

GraphQL بيغير كل الـ methodology. مفيش endpoints — في operations. والـ authorization بيتعمل على مستوى الـ operation مش الـ URL.

◆ ◇ ◆

// SCRIPT — لما تشوف /graphql بدل /api/60:00 – 80:00

في الـ traditional REST: كل endpoint = URL مختلف. في الـ GraphQL: كل حاجة بتروح لـ /graphql. التطبيق بياخد الـ operation name من الـ body ويحدد إيه اللي هيتعمل.

ده بيعني إن الـ Access Control مش بيتطبق على الـ URL — بيتطبق على الـ operation name. وأحياناً الـ developers بينسوا يضيفوا الـ auth check على بعض الـ operations.

⚠️ "The task was matching these GraphQL operations to the high-level mechanisms that the individual user roles are either supposed to or not supposed to be able to use." — Arson

الـ approach في GraphQL: بدل ما تدور على endpoints، بتجمع كل الـ operation names من الـ Burp sitemap (ابحث عن "operationName")، وبتعملهم test بـ sessions مختلفة.

كيف تجمع GraphQL Operations

1

Burp Search → "operationName"

في الـ proxy tab، افتح search، ابعت operationName مع auto-scroll. هيطلعلك كل operation جت من التطبيق.

2

انقل لـ Repeater

كل operation مهمة: send to Repeater وسميها باسم الـ operation (مش "Request 1"). ده بيساعدك لما تيجي تعمل test بالـ roles المختلفة.

3

Introspection Query

ابعت {"query": "{ __schema { mutationType { fields { name } } } }"} — ده بيجيبلك كل الـ mutations حتى اللي ما شفتهاش في الـ UI.

4

Fuzz Operation Names

Burp Intruder على الـ operationName field بـ wordlist من known GraphQL operations. ممكن تلاقي hidden operations مش موجودة في الـ docs.

// GRAPHQL RBAC TEST TEMPLATE // For each operation: test ALL role sessions POST /graphql Authorization: Bearer [SESSION_ADMIN] ← baseline { "operationName": "triggerWorkspaceExport", "variables": { "workspaceId": "WORKSPACE_UUID", "exportType": "ALL_WORKSPACE_MEMBERS" }, "query": "mutation triggerWorkspaceExport($workspaceId: ID!) { ... }" } // Then swap session to test each role: Admin: 200 OK → YES (baseline) Team Member: ??? → should be 403 Developer: ??? → should be 403 Unprivileged: ??? → should be 403

GraphQL vs REST — الـ Testing Difference

REST: test per URL → GraphQL: test per operation name
REST: 403 = blocked URL → GraphQL: 403 = blocked operation
GraphQL: same URL returns different data per operation
Use Burp's InQL extension للـ GraphQL testing
Introspection = free documentation of all operations

// 10 — تحليل الـ Session Token

كيف الـ Server يعرف Role بتاعك؟

قبل ما تبدأ الـ testing، لازم تفهم كيفية الـ role validation. الـ answer في الـ session token.

◆ ◇ ◆

// SCRIPT — الأسئلة الثلاثة الأساسية80:00 – 100:00

لازم تجاوب على 3 أسئلة قبل ما تبدأ:

السؤال الأول: إيه اللي بيتاستخدم للـ authentication؟ Session cookie؟ JWT؟ Custom cookie؟

السؤال التاني: كيف الـ server بيعرف الـ role؟ بيجيبها من الـ session في الـ DB؟ موجودة في الـ JWT payload؟ موجودة في custom cookie؟

السؤال التالت: هل ممكن نتلاعب بالـ role؟ لو موجودة في JWT مش validated — ده jackpot. لو في الـ DB — لازم نستخدم الـ session token بتاع كل role.

🔍 في Pantheon، الـ session token بيحتوي على 3 values مفصولة بـ %. كل محاولة لتعديلها أرجعت 401. يعني الـ server بيتحقق من الـ signature. Solution: استخدم الـ session token الكاملة بتاع كل role.

// SESSION TOKEN ANALYSIS TREE

After login — examine cookie/header

TYPE IDENTIFICATION

Starts with "eyJ"?→JWT — decode at jwt.io

Random opaque string?→Session-based — role in DB

Delimiters (: or %3A)?→Custom format — decode and analyze

IF JWT — CHECK PAYLOAD

→role: "admin" in payload?YES→Test: shorten sig → change role → JACKPOT

→Only user_id in payload?YES→Role fetched from DB — need valid sessions per role

RBAC TESTING APPROACH

Role in JWT (not validated)→Change "role":"developer" to "role":"admin"

Role in JWT (validated HS256)→Try alg:none, brute force weak secret

Role in DB (opaque session)→Use valid session token per role → test operations

// JWT WITH ROLE — TARGET FOR MODIFICATION Header: {"alg": "HS256"} Payload: { "userId": "DEV-8821", "role": "developer", ← change to "admin"? "workspace": "WS-4401" } // TEST: Shorten signature Still 200? → Change role → admin Got 401? → Validated → try alg:none // alg:none payload (base64): eyJhbGciOiJub25lIn0. eyJ1c2VySWQiOiJERVYtODgyMSIsInJvbGUiOiJhZG1pbiJ9. (empty sig — just trailing dot)

// PANTHEON CUSTOM SESSION COOKIE // Raw cookie value (URL decoded): a1b2c3d4e5f6:USER-UUID-8821:f7e8d9c0b1a2 // Analysis: // Part 1: unknown (session token?) // Part 2: user ID (confirmed via Burp search) // Part 3: unknown (signature?) // TEST: Swap Part 2 with Admin user ID → 401 Unauthorized (tamper detected) // Conclusion: integrity check exists // Solution: use FULL session token per role

// 11 — عملية الـ Testing

Testing Operations — الخطوة بالخطوة

بعد ما عملت الـ inventory وفهمت الـ session structure — ابدأ الـ testing بشكل منهجي.

◆ ◇ ◆

01

الـ Admin Baseline

قبل أي حاجة، اتأكد إن الـ operation شغالة مع الـ admin. لو الـ admin بيرجع error — في مشكلة في الـ request نفسه مش في الـ access control. وثّق الـ expected response كـ baseline.

02

Test المفروض يتبلوك أولاً

ابدأ بـ Team Member على mechanism المفروض يكون Admin-only. لو رجع 403 — confirmed correct. لو رجع 200 — FOUND IT!

03

اعمل test كل role على كل mechanism

لا تفترض إن لأن Team Member اتبلوك، Developer برضو اتبلوك. اعمل test كل role على كل mechanism منفصل. الـ edge cases هي في اللي بيكون فيه role معين اتنسي.

04

في GraphQL — غير الـ session token في نفس الـ Repeater tab

خد الـ admin request في Repeater. بدّل بس الـ Authorization header / session cookie بـ session بتاع كل role. نفس الـ operation name، نفس الـ variables، بس session مختلف.

05

وثّق كل response

في الـ notes: triggerWorkspaceExport: Admin=200, TeamMember=403, Developer=403. لو أي واحد رجع 200 لما المفروض يرجع 403 — ده هو الـ finding.

06

اعمل Bypass Attempts

لو اتبلوكت — جرب: HTTP Method switching، URL path variations، header injection، parameter pollution. الـ server ممكن يبلوك DELETE بس ينسى POST /delete.

// TESTING RESULTS DOCUMENTATION

## Testing Results ### triggerWorkspaceExport (EXPORT MEMBERS CSV) Expected: Admin=YES, Others=NO (403) Admin → 200 OK ← baseline confirmed ✓ Team Member→ 403 Forbidden ← CORRECT ✓ (no bug) Developer → 403 Forbidden ← CORRECT ✓ (no bug) ### deployLive (DEPLOY TO PRODUCTION) Expected: Admin+TeamMember=YES, Developer=NO Admin → 200 OK ← baseline ✓ Team Member→ 200 OK ← correct ✓ Developer → ??? → TEST NOW ### updateMemberRole (CHANGE USER ROLE) Expected: Admin ONLY Admin → 200 OK ← baseline ✓ Team Member→ ??? → TEST NOW ⭐ HIGH PRIORITY Developer → ??? → TEST NOW ⭐ HIGH PRIORITY

// 12 — التكتيكات المتقدمة

Advanced Exploitation — تقنيات الـ Bypass المعقدة

لما الـ Access Control العادي (زي تغيير ID) يترفض، لازم تلجأ لتقنيات معقدة بتستغل أخطاء الـ Architecture والـ Frameworks. الـ 4 تقنيات دول هما الـ Core بتاع الـ Advanced Bugs.

◆ ◇ ◆

1. Mass Assignment & Parameter Pollution

في الـ Frameworks الحديثة (زي Spring, Laravel, Rails)، الـ Developer بياخد الـ JSON Object كله من الـ Request وبيرميه مباشرة في الداتابيز أو في الـ Model Object (حاجة اسمها Auto-Binding أو Mass Assignment). دي كارثة لو مفيش Allowlist!

// HOW MASS ASSIGNMENT WORKS // Developer Code (Vulnerable): User.update(req.body); // Accepts EVERYTHING // Your Request (Normal): PUT /api/profile { "email": "user@test.com", "name": "Hamada" } // Your Request (Exploit): PUT /api/profile { "email": "user@test.com", "name": "Hamada", "role": "admin", "is_superuser": true, "plan": "enterprise" }

// SCRIPT — إزاي تجيب أسماء الـ Parameters؟

عشان تنجح في الـ Mass Assignment، لازم تعرف اسم الـ Parameter الحساس (role, is_admin, permission_level). بتجيبه إزاي؟

من الـ GET Request: لما بتعمل GET /api/profile، السيرفر بيرجع الـ User Object كله. بص على الحقول اللي راجعة وخد الحساس منها وحطه في الـ PUT/POST Request.
من الـ JavaScript Files: ابحث في الـ Source Code عن user.role أو admin.
Brute-forcing: استخدم أداة زي ParamMiner أو ابعت قائمة طويلة من الـ admin parameters المشهورة في الـ JSON body.

2. HTTP Method/Verb Tampering

الـ Authorization Middlewares أحياناً بتتبرمج بطريقة غبية. المبرمج بيقول: "امنع أي يوزر عادي إنه يعمل POST على المسار ده". طب ماذا لو اليوزر العادي بعت PUT أو PATCH؟

// SCRIPT — الـ Router Confusion

في بعض الـ Custom Routers أو سيرفرات الـ Java القديمة، لو غيرت הـ HTTP Verb، الـ Middleware Security Rule مش بتعمل Match، بس الـ Backend Controller بينفذ الطلب عادي!

💡 الخطوات: 1. ابعت POST /api/admin/delete → هيجيلك 403 Forbidden. 2. غير في الـ Burp הـ Method لـ PUT /api/admin/delete بنفس الـ Body. 3. لو رجعلك 200 OK، يبقى إنت عملت Bypass للـ Middleware Rule!

3. Client-Side State Trust & Hydration (UI-to-API)

في عصر الـ React والـ Next.js، الـ Frontend بياخد بيانات الجلسة ويخزنها في الـ Browser عشان يحدد إيه اللي يترسم على الشاشة. المشكلة بتحصل لما الـ Backend يثق في اللي الـ Frontend بيبعتهوله!

Local Storage Manipulation

افتح الـ DevTools (F12) → Application → LocalStorage. هتلاقي حاجات زي {"userRole": "guest"}. غيرها بإيدك لـ admin واعمل Refresh.

لو الـ UI رسم زراير الأدمن (زي Delete User)، والـ Backend نفذ الطلب لما ضغطت عليها بدون ما يتحقق من الداتابيز... دي ثغرة قاتلة!

Insecure JWT / Cookies

أحياناً الـ Role بيكون محطوط في Cookie مش متفرمة (بدون Signature)، أو JWT السيرفر مش بيتحقق من الـ Signature بتاعته.

فك الـ JWT بـ Base64، غير الـ Role، ارفعه تاني، وابعت الريكويست. لو السيرفر اعتمد على הـ Role اللي في الـ Token ومسألش الداتابيز، إنت بقيت Admin.

4. Advanced GraphQL: Aliasing & Batching

الـ GraphQL ليه أسلحة دمار شامل لتخطي الـ WAF والـ Static Middlewares اللي بتدور على كلمات معينة في الريكويست.

// GRAPHQL ALIASING BYPASS // The Firewall Rule: Block any query containing the string "systemConfig" // Normal Query (Blocked 403): query { systemConfig { db_password } } // Aliased Query (Bypasses Firewall 200 OK): query { innocentName: systemConfig { harmlessField: db_password } } // The WAF sees "innocentName" and allows it. // The GraphQL engine translates it back and executes it!

// 13 — إثبات الـ Impact

Impact Building — ليه الـ Bug ده خطير؟

في الـ RBAC، الـ impact مش دايماً واضح. إنت لازم تحكي قصة — إيه اللي يقدر يحصل لو استغل attacker الـ bug ده.

◆ ◇ ◆

// SCRIPT — بناء الـ Impact Story100:00 – 115:00

لما لاقيت إن Developer قدر يعمل deploy — مش بس "Developer accessed restricted function". القصة هي: Developer كتب backdoor code، عمله deploy بنفسه، والـ company ما عرفتش.

لما لاقيت إن Team Member يقدر يعمل export users CSV — القصة هي: Team Member اللي اتفصل من الشركة أخد كل بيانات الـ customers قبل ما يمشي.

📋 كمان: فهم الـ compliance context بيزود الـ impact. لو التطبيق بيخدم European users — GDPR violation. Medical platform — HIPAA. الـ compliance mention بيرفع الـ severity.

الـ Violation	الـ Impact Level	السيناريو الحقيقي	الـ Compliance Factor
Developer → Deploy Live	CRITICAL	Rogue developer deploys backdoor, ransomware, defacement. No peer review bypass.	SOC2, ISO27001 — change management violation
Team Member → Change User Role	CRITICAL	Escalate own role to Admin → full workspace takeover. Demote Admin → lockout.	Privileged access management controls
Team Member → Export Users CSV	HIGH	Disgruntled employee leaving the company takes full member list with roles + emails.	GDPR — personal data export, data minimization
Developer → Create Upstream	HIGH	Custom upstream = data routing. Developer routes production traffic to malicious endpoint.	Data integrity, supply chain security
Any Role → Admin Dashboard	MEDIUM	Information disclosure — billing, user list, workspace config exposed.	Data classification policy violation

لما تكتب الـ Report — الـ Structure

1

الـ Vulnerability

Developer role can access triggerDeployLive GraphQL mutation which should be restricted to Team Member role and above.

2

الـ Steps to Reproduce

الـ exact request مع session token بتاع Developer role والـ response اللي جاب 200 OK.

3

الـ Business Impact

A developer with malicious intent can deploy arbitrary code to production without peer review, enabling backdoor installation or service disruption.

4

الـ Remediation

Add role check in deployment mutation resolver: IF current_user.role NOT IN [admin, team_member] → return 403.

الـ Impact Multipliers

Critical يؤدي لـ Account Takeover أو code execution
Critical يكشف sensitive customer data
Critical Role escalation = full privilege
High يؤدي لـ data exfiltration
High GDPR/HIPAA compliance violation
High Disrupts business operations
Medium Information disclosure عن roles/structure
Medium يؤثر على audit trail integrity

// 14 — الفلسفة

Thoughtful Testing — وقت التفكير أهم من وقت الـ Keyboard

الـ concept الأهم في الـ RBAC testing. إنت مش بتهاجم — إنت بتفهم، وبعدين بتهاجم.

◆ ◇ ◆

// SCRIPT — الـ Recording دي اخدت 3 أيام115:00 – 130:00

Arson وضح إن الـ recording بتاعت الـ part 2 اخدت 3 أيام. مش عشان التطبيق كان صعب — عشان الـ testing من النوع ده بيحتاج وقت تفكير حقيقي.

لاحظت في الـ recording إنه وقف كتير، راح يجيب قهوة، بعيد عن الشاشة، رجع بفكرة جديدة. الـ process الحقيقي للـ RBAC testing مش بس في الـ keyboard — هو في الـ head.

💭 "Thoughtful testing — as you're going through, you really should be spending more time thinking than you are in front of a computer." — Arson

الـ RBAC testing مش fun زي الـ exploitation. بس هو الـ most rewarding لأن الـ bugs دي نادراً بتتلاقى بالـ automation وكتير من الـ researchers بيتجنبوها.

✓ "This is the best way for beginners to find their first bug. I cannot stress that enough." — Arson

الـ 3 Phases بتاعة كل Testing Session

A

Exploration (50% of time)

كلّك فضول. افتح كل صفحة، اقرأ الـ docs، افهم الـ business logic. مفيش testing هنا.

B

Mapping (30% of time)

وثق كل حاجة. Role map، mechanism inventory، session structure. Notes أولاً دايماً.

C

Testing (20% of time)

بس بعد الـ A وB — الـ testing نفسه بيكون سريع ومنظم لأن عارف بالظبط إيه اللي بتدور عليه.

علامات إنك على الطريق الصح

بتسأل "ليه" مش بس "إيه"
بتفهم business logic وراء كل role
Notes بتاعتك قابلة لحد تاني يفهمها
بتلاقي mechanisms مش موجودة في الـ docs
بتستغرب من بعض القرارات التصميمية
بتحدد الـ target قبل ما تبدأ الـ testing
بتعمل step away بعد كل finding مهم

علامات إنك على الطريق الغلط

NO بتحاول كل endpoint من غير فهم
NO مش بتعمل notes — بتعتمد على memory
NO بتستخدم automated scanner بدل الـ manual
NO مش بتعرف الـ role purpose
NO بتفتكر 403 = no bug وتمشي
NO بتعمل test نفس الـ role بأكتر من account

// 15 — Decision Trees الكاملة

كل قرار ليه مساره

من لحظة ما تفتح البرنامج لحد ما تكتب الـ report.

◆ ◇ ◆

// MASTER RBAC HUNTING TREE — FROM PROGRAM SELECTION TO FINDING

◆Target selected — start here

PHASE 1 — PROGRAM QUALIFICATION

→Has 3+ distinct user roles?YES→PROCEED

→Has 3+ distinct user roles?NO→Consider another program for RBAC

→Self-registration available?YES→PROCEED

→Permission table documented?YES→GOLD — has test plan

PHASE 2 — ENVIRONMENT MAPPING

→How many environments/workspaces?

Personal + Team→Map both — identify which has RBAC

Single workspace→Simpler — focus on role levels

PHASE 3 — ROLE MAPPING

→Create one account per role

→For each role: what CAN they do? What CANNOT they do?

→Mark every "CANNOT" as a test target

PHASE 4 — TECHNOLOGY DETECTION

Backend type?GraphQL→Collect operation names → test per operation

Backend type?REST API→Collect endpoints → test per URL + method

PHASE 5 — SESSION ANALYSIS

Session contains role in JWT?YES (not validated)→Change role directly → JACKPOT

Session contains role in JWT?YES (validated)→alg:none / brute force

Session opaque?YES→Use full valid session per role → test operations

PHASE 6 — TESTING

→For each [mechanism × role] that should be blocked:

Admin: 200 OK (baseline)?→Confirmed operation works

Lower role: 200 OK?YES→🏆 ACCESS CONTROL VIOLATION FOUND!

Lower role: 403?403→Try bypass techniques → move to next

// 403 BYPASS TECHNIQUES TREE

Got 403 — try these before moving on

HTTP Method Switch

→GET blocked?→Try POST / PUT / PATCH / OPTIONS

→DELETE blocked?→Try POST /resource/delete or PUT with delete flag

URL Path Manipulation

→/admin/users → /Admin/users (capitalization)

→/admin/users → /admin/users/ (trailing slash)

→/admin/users → /%61dmin/users (URL encoding)

→/admin/users → /admin/./users (path traversal)

Header Injection

→X-Original-URL: /admin/users

→X-Rewrite-URL: /admin/users

→X-Forwarded-For: 127.0.0.1 (localhost bypass)

→X-Custom-IP-Authorization: 127.0.0.1

Content-Type Manipulation

→application/json → application/xml

→application/json → text/plain

GraphQL-specific

→Batch queries: combine forbidden op with allowed op

→Alias confusion: rename forbidden field in query

→Introspection to find undocumented operations

// ROLE CONFUSION DETECTION TREE

Unexpected behavior found

Lower role accessed admin function?YES→Vertical Privilege Escalation

User accessed another user's data?YES→Horizontal Escalation (overlaps IDOR)

Unauthenticated accessed auth endpoint?YES→Missing authentication check

Role can READ admin data but not WRITE?Partial→Test every CRUD operation separately

403 on UI but 200 via API?YES→Client-side enforcement only — RBAC bug!

// 16 — الملخص

RBAC Cheatsheet الكامل

◆ ◇ ◆

Program Selection Checklist

3+ distinct roles documented?
Collaboration/team workspace concept?
Self-registration for each role?
Permission table available in docs?
Low bounty = less competition?
Auditor/read-only external role?
SaaS/CMS type platform?

Role Setup Checklist

One account per role via plus notation
Different browser per role (no session sharing)
Session token documented per role in notes
Role name in email alias (not demo1/2)
Admin account = workspace creator
Test Burp browser for 3rd+ session
Verify each role can do its expected operations

403 Bypass Techniques

HTTP method switching (GET→POST→PUT)
URL capitalization (/Admin/)
Trailing slash (/admin/users/)
URL encoding /%61dmin/
X-Original-URL header injection
X-Forwarded-For: 127.0.0.1
GraphQL batch query with allowed op

GraphQL RBAC Testing

Burp search "operationName" → collect all ops
Introspection query → find hidden operations
Test each op with each role session
Fuzz operation names with wordlist
Batch queries to bypass auth checks
Use InQL Burp extension
Check field-level permissions in schema

// RBAC TESTING CHECKLIST — لكل mechanism × role [ ] 1. Admin baseline → confirm 200 OK → log response [ ] 2. Team Member → swap session → send same request → 200 or 403? [ ] 3. Developer → swap session → send same request → 200 or 403? [ ] 4. Unprivileged → swap session → send same request → 200 or 403? [ ] 5. If 403: try HTTP method switch (GET→POST→PUT→PATCH) [ ] 6. If 403: try URL path variations (/admin/ /Admin/ /%61dmin/) [ ] 7. If 403: try X-Original-URL, X-Forwarded-For headers [ ] 8. Log result: [Op Name]: Admin=200, TM=403, Dev=200 ← BUG! [ ] 9. If found: document full request + response for report [ ] 10. Build impact story: what can attacker do with this access? [ ] 11. Step away → think → confirm before submitting [ ] 12. Check compliance factor (GDPR/HIPAA/SOC2) for severity

Bug Type	How to Find	Expected Severity	Best Target
Vertical Privilege Escalation	Lower role → Admin-only function → 200 OK	CRITICAL	Any admin-only destructive/config operation
Function-level RBAC bypass	Read-only role → write/delete operation → 200	HIGH-CRITICAL	Export, deploy, delete endpoints
Horizontal Access Violation	User A → User B's data/operations → 200	HIGH	Multi-tenant SaaS workspace isolation
Unauthenticated Access	Remove auth header → authenticated endpoint → 200	HIGH	Any endpoint found after login
JWT Role Manipulation	Role in JWT → not validated → change to admin	CRITICAL	Any JWT with role/permissions claim
GraphQL Op-level bypass	Mutation for admin-only op → non-admin session → 200	CRITICAL	Export, delete, configure mutations
Client-side only enforcement	Button hidden in UI but API accepts request	HIGH	Features that "disappear" for lower roles

// 17 — اختبر نفسك

Quiz — RBAC Methodology

5 أسئلة عن decision-making حقيقي — مش عن تعريفات.

◆ ◇ ◆

لقيت برنامج SaaS عنده Admin وUser فقط (دورين). الـ bounty منخفض $500-1000. إيه قرارك؟

A. ابعد عنه — الـ bounty منخفض جداً

B. ابعد عنه — دورين بس مش كافي لـ RBAC testing جيد

C. اعمل testing عليه — Admin vs User كافي

D. اعمل testing لأن الـ bounty المنخفض = منافسة أقل، بس ابحث كمان عن granular permissions جوا كل role

الإجابة الصح: D

الـ bounty المنخفض = منافسة أقل = فرصة أحسن. وحتى لو في دورين بس ظاهرياً، جوا كل role ممكن يكون في granular permissions (read vs write vs delete) اللي تستاهل testing. الـ rule المهم: دور على الـ granularity جوا الـ roles مش بس عدد الـ roles.

في Pantheon، جمعت الـ operations من Burp وجاب معاك: getCurrentUser, cmsIndexSiteList, triggerWorkspaceExport. كيف بتحدد أي واحد تبدأ بيه؟

A. ابدأ بـ getCurrentUser — اسمه بيقول إنه مهم

B. ابدأ بـ triggerWorkspaceExport — لأن في الـ role table الـ export هو Admin-only

C. اعمل test الثلاثة بنفس الترتيب — مفيش فرق

D. ابدأ بـ cmsIndexSiteList — لأنه READ وأسهل

الإجابة الصح: B

الـ priority بيجي من الـ role table مش من اسم الـ operation. لما تعرف إن الـ export هو Admin-only من الـ documentation، ده بيبقى أعلى priority لأنك عارف بالظبط إيه اللي المفروض يكون blocked. getCurrentUser هو operation بيشتغل مع كل role = skip. cmsIndexSiteList كمان بيشتغل مع كل role = lower priority.

بعثت الـ triggerWorkspaceExport operation بـ Team Member session فرجع 403. إيه خطوتك الجاية؟

A. ده معناه مفيش bug — مشي للـ operation التالية

B. جرب HTTP method switching: POST → GET → PUT على نفس الـ operation

C. وثّق الـ 403 وجرب bypass techniques (URL encoding, method switch, header injection) ثم انتقل للـ Developer session على نفس الـ operation

D. ابعث report فوراً — 403 ده بيثبت إن في access control implemented

الإجابة الصح: C

403 = correct behavior, NOT a bug. بس مش معناه تمشي فوراً. خطوتان: (1) جرب bypass techniques — ممكن الـ 403 بيتجاوز بـ header injection أو method switch. (2) انتقل لـ Developer session على نفس الـ operation — ممكن الـ Team Member اتبلوك بس الـ Developer اتنسي. كل role لازم تتاختبر على كل operation منفصل.

الـ JWT session بتاع التطبيق بيحتوي على: {"userId": "DEV-8821", "role": "developer"}. اختصرت آخر حرف من الـ signature وبعثت admin-only operation — رجع 401. إيه الخطوة الجاية؟

A. الـ role manipulation مش ممكن — خلص من الـ JWT attack vector

B. جرب alg:none — ابعت {"alg":"none"} في الـ header وشيل الـ signature كلها

C. الـ signature validated — استخدم valid developer session وابعت operation كده وخلاص

D. جرب alg:none، ولو فشل جرب HS256 secret brute force، ولو فشل — الـ JWT مأمون واستخدم sessions مختلفة للـ testing

الإجابة الصح: D

الـ 401 بعد اختصار الـ signature = validated. بس ده مش نهاية الـ JWT attacks. الترتيب الصح: (1) alg:none — ممكن الـ library بتقبله، (2) HS256 weak secret brute force بـ hashcat، (3) لو الاتنين فشلوا — الـ JWT مأمون واستخدم valid sessions لكل role. المهم مش تستسلم بعد الـ 401 الأولى.

Developer بيعمل click على "Deploy" button في الـ UI فمش بيلاقيه (hidden من الـ frontend). إيه اللي المفروض تعمله؟

A. ده معناه إن الـ developer مش مسموحله يعمل deploy — البرنامج OK

B. الـ UI hiding مش security — ابعت الـ deploy API request مباشرة من Burp بـ developer session

C. محتاج تعمل XSS عشان تشوف الـ hidden button

D. ده client-side enforcement فقط — مش bug لأن الـ UI مش بيسمح بيه

الإجابة الصح: B

الـ UI hiding هو client-side enforcement فقط — وده مش security! الـ API مش عارف إن الـ button hidden. إنت كـ attacker بتبعت الـ API request مباشرة من Burp. لو الـ API قبل الـ request وعمل deploy — ده هو الـ bug. الـ rule: "Never assume frontend limitations reflect backend restrictions."

منهجية صيد

شرح فيديو كامل للمنهجية

IDOR vs Access Control — الفرق الحقيقي

أنواع الـ Access Control Violations

الأبسط — الأكثر شيوعاً

نفس المستوى — permissions مختلفة

أخطر نوع — الـ impact الأعلى

الـ Granular Role Bypass

الـ Modern Challenge — GraphQL Endpoints

اختيار البرنامج الصح للـ RBAC

Role Mapping — قبل ما تبدأ أي testing

Environment Mapping — ابدأ بالصورة الكبيرة

اعمل account وافتح Burp

ابحث عن "Team" أو "Workspace"

افتح الـ Settings كامل

ابحث عن الـ Permission Table

حساب لكل Role — مش حسابين بس

الـ Workspace Creator = Admin

Plus Notation لكل Role

Activate في Browsers مختلفة

وثق Session Tokens كل Role

تحدي الـ Incognito Sharing

Mechanism Inventory — اعرف كل حاجة ممكن تعملها

CRUD per Role — الـ Matrix الكاملة

GraphQL — كل الـ Requests في مكان واحد

Burp Search → "operationName"

انقل لـ Repeater

Introspection Query

Fuzz Operation Names

كيف الـ Server يعرف Role بتاعك؟

Testing Operations — الخطوة بالخطوة

الـ Admin Baseline

Test المفروض يتبلوك أولاً

اعمل test كل role على كل mechanism

في GraphQL — غير الـ session token في نفس الـ Repeater tab

وثّق كل response

اعمل Bypass Attempts

Advanced Exploitation — تقنيات الـ Bypass المعقدة

1. Mass Assignment & Parameter Pollution

2. HTTP Method/Verb Tampering

3. Client-Side State Trust & Hydration (UI-to-API)

4. Advanced GraphQL: Aliasing & Batching

Impact Building — ليه الـ Bug ده خطير؟

الـ Vulnerability

الـ Steps to Reproduce

الـ Business Impact

الـ Remediation

Thoughtful Testing — وقت التفكير أهم من وقت الـ Keyboard

Exploration (50% of time)

Mapping (30% of time)

Testing (20% of time)

كل قرار ليه مساره

RBAC Cheatsheet الكامل

Quiz — RBAC Methodology