عملية أساسية في أمن المعلومات، مسؤولة عن التحقق من هوية المستخدمين أو الأنظمة اللي بتحاول الوصول للموارد. الهدف الأساسي: ضمان إن المستخدمين الشرعيين بس هم اللي يقدروا يوصلوا للبيانات أو الأنظمة أو الوظائف الحساسة.
المصادقة بتتحقّق من هوية المستخدم، بينما التفويض بيحدّد إيه اللي المستخدم المصادَق عليه مسموح له يعمله.
| الجانب | Authentication | Authorization |
|---|---|---|
| التعريف | التحقق من هوية المستخدم أو النظام | تحديد ما يُسمح للمستخدم المصادَق عليه بفعله |
| الغرض | إثبات "مين المستخدم" | تحديد الموارد والإجراءات المتاحة له |
| العملية | فحص بيانات اعتماد (كلمات مرور، توكنات) | فحص الصلاحيات والأدوار مقابل الموارد |
| النتيجة | هوية مؤكَّدة (مسجَّل دخول أو لا) | منح أو رفض الوصول لمورد/إجراء محدَّد |
| مثال | تسجيل الدخول باسم مستخدم وكلمة مرور | تحديد هل المستخدم المسجَّل يقدر يوصل لمورد معيّن |
هي خط الدفاع الأول ضد الوصول غير المصرَّح به — بتحمي من اختراق البيانات، الاستيلاء على الحسابات، وغيرها من التهديدات، عبر ضمان إن المستخدمين الشرعيين بس هم اللي يتفاعلوا مع مناطق التطبيق المقيَّدة.
عملية إنشاء وصيانة وتأمين جلسة المستخدم بعد المصادقة. بما إن HTTP بروتوكول عديم الحالة (Stateless)، إدارة الجلسات ضرورية لتتبّع هوية المستخدم عبر طلبات متعددة. الوظائف الأساسية: إنشاء الجلسة (توليد Session ID عند المصادقة)، صيانة الجلسة (تذكّر المستخدم عبر الطلبات)، أمان الجلسة (حماية من Hijacking/Fixation عبر HTTPS وأعلام الكوكيز الآمنة)، وإنهاء الجلسة (بعد فترة خمول أو تسجيل خروج).
إدارة الجلسات مش دايمًا مرتبطة بالمصادقة — تطبيقات الويب الحديثة ممكن تبدأ جلسات حتى قبل المصادقة، لتتبّع مستخدمين مجهولين (مثلًا لحفظ تفضيل اللغة من أول طلب).
اختبار المصادقة هو عملية فحص واستغلال نقاط الضعف في آليات التحقق من الهوية — نماذج تسجيل الدخول، إعادة تعيين كلمة المرور، MFA، وآليات القفل. الهدف: تحديد واستغلال نقاط ضعف تسمح بالوصول غير المصرَّح به أو تصعيد الصلاحيات أو اختطاف الجلسات الشرعية.
| ID | الاختبار | الوصف |
|---|---|---|
| ATHN-01 | نقل بيانات الاعتماد عبر قناة مشفَّرة | التحقق من نقل بيانات الاعتماد عبر HTTPS لمنع الاعتراض أو التلاعب |
| ATHN-02 | بيانات اعتماد افتراضية | فحص وجود بيانات اعتماد افتراضية لسه مستخدَمة |
| ATHN-03 | آلية قفل ضعيفة | تقييم آليات القفل لمنع هجمات Brute-force على الحسابات |
| ATHN-04 | تجاوز مخطط المصادقة | تحديد عيوب تسمح بتجاوز عملية المصادقة بالكامل |
| ATHN-05 | دالة "تذكّرني" ضعيفة | تقييم إذا كانت ميزة Remember Me مُطبَّقة بأمان |
| ATHN-06 | ضعف ذاكرة التخزين المؤقت للمتصفح | التأكد إن معلومات حساسة مش متخزّنة بشكل غير آمن في الكاش |
| ATHN-07 | سياسة كلمة مرور ضعيفة | فحص إنفاذ التعقيد وانتهاء صلاحية كلمات المرور |
| ATHN-08 | مصادقة ضعيفة في قنوات بديلة | اختبار قنوات مصادقة بديلة (APIs، تطبيقات موبايل) لممارسات أمنية أضعف |
تقنية لاختبار هل المهاجم يقدر يحدّد إن اسم مستخدم معيّن موجود في النظام — غالبًا بتُنفَّذ على نماذج تسجيل الدخول والتسجيل واسترجاع كلمة المرور. الهدف: تجميع مجموعة أسماء مستخدمين صالحة عبر التفاعل مع آلية المصادقة، وده مفيد لاختبار Brute-force لاحقًا.
التطبيق بيستجيب بشكل مختلف حسب صحة اسم المستخدم — مثلًا رسالة خطأ منفصلة لـ "اسم مستخدم غير صحيح" مقابل "كلمة مرور غير صحيحة". المهاجم يقدر يستخدم الفرق ده لتأكيد أسماء مستخدمين صالحة، ثم يستخدمها في هجوم Brute-force موجَّه. الثغرة ممكن تظهر كمان في شكل رموز HTTP مختلفة، أوقات تحميل مختلفة، أو رسائل خطأ مختلفة.
تقييم هل التطبيق بيفرض سياسة كلمة مرور قوية — جزء حرج من اختبار المصادقة لضمان عدم قبول كلمات مرور ضعيفة أو سهلة التخمين.
تقييم هل آليات القفل زي CAPTCHA فعّالة في منع محاولات تسجيل دخول آلية بعد محاولات فاشلة متعددة. CAPTCHA ضعيفة أو مُطبَّقة بشكل سيئ ممكن تُتجاوَز، وده بيكشف إزاي آليات القفل الضعيفة ممكن تؤدّي لاختراق حسابات.
| النوع | القوة | الثغرات |
|---|---|---|
| Arithmetic-based | ضعيف | حل حسابي بسيط — يُتجاوَز بـ Brute-force أو خدمات حل CAPTCHA زي 2Captcha |
| Text-based | أساسي | عرضة لبوتات تستخدم تقنية OCR، التشويه البسيط سهل الكسر |
| Image-based | متوسط | محتاج نماذج AI أكثر تطورًا، لكن مش منيع |
| reCAPTCHA v2 | متوسط-قوي | مربّع "لست روبوت" + مهام صور أحيانًا |
| reCAPTCHA v3 | قوي جدًا | بيعمل في الخلفية بالكامل، بيقيّم سلوك المستخدم بدون تفاعل |
تقييم هل CAPTCHA أو آليات القفل التانية ممكن تُتجاوَز لمواصلة محاولات تسجيل دخول آلية (Brute-force أو Dictionary attack).
تحديد نقاط ضعف في عمليات المصادقة بتسمح للمهاجمين بتجاوز آليات المصادقة بالكامل. الهدف: اكتشاف أخطاء إعداد أو تطبيقات غير آمنة، تحديد مسارات أو Endpoints بديلة توفّر وصول غير مصرَّح به، والتحقق من Endpoints غير محمية.
| الطريقة | الوصف | ملاحظة أمنية |
|---|---|---|
| Cookie-Based | الأكثر شيوعًا — Session ID في كوكي بيتبعت مع كل طلب | يمكن حمايتها بـ HttpOnly/Secure/SameSite |
| URL-Based | Session ID مُلحَق بالرابط كمعامل | غير آمن — يظهر في سجل المتصفح واللوجات |
| Token-Based | توكنات زي JWT — تحتوي معلومات مشفَّرة وممكن تكون Stateless | مُستخدَم بكثرة في APIs والتطبيقات الحديثة |
| Header-Based | Session ID في Header مخصَّص — شائع في RESTful APIs | أكثر أمانًا شوية لأنه بعيد عن الرابط والكوكيز |
| الاختبار | الوصف |
|---|---|
| Session Management Schema | التحقق من تخزين معرّفات الجلسة بأمان ومش سهل تخمينها |
| Cookie Attributes | فحص إعدادات HttpOnly/Secure/SameSite لمنع سرقة الكوكي عبر XSS |
| Session Fixation | تقييم هل المهاجم يقدر يحدّد أو يتنبّأ بـ Session ID قبل تسجيل الدخول |
| Session Expiration | ضمان انتهاء الجلسة بعد فترة خمول أو تسجيل خروج |
| Session Timeout | تقييم هل الجلسات مُعدَّة لإنهاء نفسها بعد فترة معقولة |
قطع بيانات صغيرة مخزَّنة على متصفح المستخدم بواسطة المواقع اللي بيزورها — بتحتفظ بمعلومات بين الجلسات زي حالة تسجيل الدخول والتفضيلات.
POST /login HTTP/1.1
Host: example.com
Content-Type: application/x-www-form-urlencoded
username=testuser&password=examplepassword
HTTP/1.1 200 OK
Set-Cookie: session_id=abc123xyz; HttpOnly; Secure; SameSite=Lax; Path=/; Max-Age=3600
Content-Type: text/html
تقييم أمان تصميم وقوة مخطط إدارة الجلسات — فحص إزاي التطبيق بيدير إنشاء وصيانة وإنهاء توكنات الجلسة.
| التقنية | الوصف | الثغرة |
|---|---|---|
| Predictable Session IDs | تحليل عشوائية التوكنات | المهاجم يقدر يخمّن أو يولّد توكنات صالحة |
| Session Fixation | تثبيت Session ID قبل التسجيل | استيلاء على الجلسة بعد مصادقة الضحية |
| Session Expiration | التحقق من انتهاء الجلسة بعد Timeout وتسجيل الخروج | جلسات لا تنتهي ممكن تُعاد استخدامها |
| Session Hijacking | إعادة تشغيل كوكي الجلسة من أجهزة/مواقع مختلفة | اختطاف لو التوكن مش مرتبط بخصائص المستخدم |
| Cookie Security Flags | فحص HttpOnly/Secure/SameSite | غيابها يعرّض لـ XSS وCSRF وMitM |
| Session Token in URLs | التأكد إن التوكنات مش في الرابط | تسريب عبر Referrer headers واللوجات والتاريخ |
فحص بنية الكوكي بحثًا عن أنماط قابلة للتنبؤ أو معلومات مُرمَّزة (Base64/URL encoding) ممكن تكشف بيانات حساسة لو مش مشفَّرة فعليًا. مثال شائع: تعديل معامل role=guest إلى role=admin — لو التطبيق مش بيتحقّق من الصلاحيات من جهة السيرفر، ده ممكن يمنح صلاحيات غير مصرَّح بها.
عند تسجيل الدخول، السيرفر بيولّد Session ID ويخصّصه للمستخدم — غالبًا في كوكي أو معامل URL أو Header.
عبر Sniffing (التقاط ترافيك غير مشفَّر)، Man-in-the-Middle، XSS (حقن سكريبت لسرقة الكوكي)، أو استغلال خوارزميات توليد ضعيفة لتوكنات قابلة للتنبؤ.
المهاجم بيستخدم Session ID المسروق لانتحال المستخدم الشرعي — السيرفر مش قادر يفرّق بين المهاجم والمستخدم الحقيقي.
المهاجم بيقدر ينفّذ إجراءات كمستخدم شرعي — عرض بيانات حساسة، معاملات غير مصرَّح بها، أو تعديل إعدادات الحساب.
بينشئ أو يحصل على Session ID صالح (مثلًا ببدء جلسة مع التطبيق الهدف) أو بيخمّن واحد قابل للتنبؤ، وبيبعته للضحية عبر رابط أو كوكي أو حقن JavaScript.
الضحية من غير ما يعرف بيستخدم Session ID اللي زرعه المهاجم — التطبيق بيربط المعرّف ده بجلسة الضحية المصادَق عليها.
بما إن المهاجم أصلًا عارف Session ID، بيقدر يستخدمه للوصول لجلسة الضحية بدون الحاجة لبيانات اعتماد الدخول.
ثغرة أمنية بتخلّي المهاجم يخدع المستخدم عشان ينفّذ إجراءات على تطبيق ويب من غير علمه أو موافقته — الهجوم بيستغل الثقة اللي التطبيق عنده في متصفح المستخدم.
تغييرات غير مصرَّح بها في إعدادات الحساب، تحويلات أموال أو إجراءات نيابة عن المستخدم بدون موافقته، أو إجراءات خبيثة زي تغيير كلمات المرور والبريد الإلكتروني ومعلومات البروفايل.
طريقة حديثة للتحقق والتفويض الآمن للمستخدمين أو التطبيقات — بدل الاحتفاظ بحالة الجلسة على السيرفر، التوكنات بتتصدر للعميل وبتُمرَّر ذهابًا وإيابًا لمصادقة الطلبات.
| الموقع | الاستخدام | ملاحظة أمنية |
|---|---|---|
| Authorization Header | الأكثر شيوعًا وأمانًا — Authorization: Bearer <token> | يبعد التوكن عن الرابط، يمنع تسريبه عبر اللوجات |
| Query Parameters | التوكن مُلحَق بالرابط | خطر — يظهر في التاريخ واللوجات ويُخزَّن Cache |
| Request Body | غالبًا في طلبات POST | مناسب لإرسال بيانات، تجنّبه في GET |
| Cookies | تُضاف تلقائيًا للطلبات لنفس النطاق | يحتاج HttpOnly + Secure، وعرضة لـ CSRF بدون حماية إضافية |
| Custom Headers | Header مخصَّص (مثلًا X-Auth-Token) | أقل قياسية لكن مفيد لأنظمة بمتطلبات أمنية خاصة |
استخدم Authorization Header دايمًا ما أمكن، تجنّب معاملات الرابط، أمّن أي توكن في كوكيز بـ HttpOnly وSecure وSameSite، وشفّر النقل دايمًا بـ HTTPS بغضّ النظر عن مكان التوكن.
طريقة مدمجة وآمنة للرابط (URL-safe) ومكتفية ذاتيًا لنقل المعلومات بأمان بين الأطراف — بتُستخدم بكثرة للمصادقة والتفويض وتبادل المعلومات. بتتكوّن من ثلاثة أجزاء مفصولة بنقاط: HEADER.PAYLOAD.SIGNATURE.
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImV4cCI6MTcxNjQ1NDY2MH0.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c
الـ Header دايمًا أولًا، بعده الـ Payload، وأخيرًا الـ Signature — التوقيع بيتولّد من تجزئة Header وPayload معًا، وأي تبديل في الترتيب ده بيُبطِل التوكن.
iss (المُصدِر)، sub (الموضوع/ID المستخدم)، aud (الجمهور المستهدَف)، exp (وقت الانتهاء)، iat (وقت الإصدار)، nbf (غير صالح قبل).role، email، permissions.department، cartId.HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload),
secret
)
عند تسجيل الدخول الناجح، السيرفر بيولّد JWT يحتوي Claims خاصة بالمستخدم، بيوقّعه بمفتاح سرّي/خاص، وبيبعته للعميل. في الطلبات التالية، العميل بيضمّن الـ JWT في Authorization header، والسيرفر بيتحقّق منه لمصادقة المستخدم — بدون أي تخزين جلسة من جهة السيرفر (Stateless)، وده بيحسّن قابلية التوسّع والمصادقة عبر الأنظمة الموزَّعة.
بتحدث لما يُوقَّع JWT بخوارزمية none — ده بيسمح للمهاجم بالتلاعب في التوكن وتجاوز آليات التحقق لأن التوقيع إما مفقود أو مُتجاهَل.
none لأغراض الاختبار، ولو مش مُعدَّة صح ممكن تقبل توكنات بدون التحقق من سلامتهاalg بالـ Header — لو التطبيق بيثق فيه بدون تحقق، المهاجم يقدر يعدّله لـ none ويتجاوز التحقق من التوقيعالمهاجم بيصنع JWT بحقل alg مضبوط على none — ده بيخبر السيرفر إنه مش هيتحقّق من التوقيع.
المهاجم بيعدّل التوكن ويشيل التوقيع — جزء التوقيع بعد النقطة الثانية بيفضل فارغ.
السيرفر بيعتبر التوكن صالح لأنه مش بيتحقّق من التوقيع لما alg يكون none — المهاجم يقدر يعدّل الـ Payload لانتحال أي مستخدم أو تصعيد الصلاحيات.
{
"alg": "none",
"typ": "JWT"
}
eyJhbGciOiJub25lIiwidHlwIjoiSldUIn0.eyJ1c2VyIjoiYWRtaW4ifQ.
تصعيد الصلاحيات (تغيير role: "user" إلى role: "admin")، انتحال الهوية (تزوير توكنات لمستخدمين آخرين)، واختطاف الجلسة بالكامل عبر Payload مستخدم شرعي مزوَّر.
OAuth2 هو المعيار الأساسي للويب للتفويض بين الخدمات — بيُستخدم لتفويض تطبيقات طرف ثالث للوصول لخدمات أو بيانات من مزوّد عندك حساب فيه.
| الهجوم | الآلية |
|---|---|
| Unvalidated Redirect URI | عدم التحقق من إن redirect_uri ملك للـ Client → Open Redirect واختطاف حساب عبر سرقة Authorization Code |
| Weak Authorization Codes | أكواد تفويض ضعيفة يمكن تخمينها عند Token Endpoint خصوصًا لو client secret مخترَق أو غير مُتحقَّق منه |
| Everlasting Authorization Codes | أكواد تفويض غير منتهية الصلاحية بتوسّع نافذة استغلال الأكواد الملتقَطة أو المخمَّنة |
| Codes Not Bound to Client | إمكانية تبديل كود تفويض مُلتقَط/مخمَّن مع Client آخر للحصول على Access Token |
| Weak Handle-Based Tokens | توكنات وصول/تجديد ضعيفة يمكن تخمينها عند Resource Server أو Token Endpoint |
| Insecure Token Storage | تخزين التوكنات كنص عادي غير مُجزَّأ في قاعدة البيانات |
| Refresh Token Not Bound to Client | استبدال Refresh Token صادر لـ Client بتوكن Client آخر لو الربط غير مُتحقَّق منه |
# الرابط الأصلي اللي بيستخدمه الـ Client:
http://gallery:3005/OAuth/authorize?response_type=code&redirect_uri=http%3A%2F%2Fphotoprint%3A3000%2Fcallback&scope=view_gallery&client_id=photoprint
# تعديل قيمة redirect_uri لجهة المهاجم:
http://gallery:3005/OAuth/authorize?response_type=code&redirect_uri=http%3A%2F%2Fattacker%3A1337%2Fcallback&scope=view_gallery&client_id=photoprint
معامل redirectUrl كان عرضة لـ Reflected XSS بسبب تنظيف غير كافٍ للمدخلات. المهاجم حقن JavaScript خبيث، أنشأ Iframe خفي لصفحة تسجيل الدخول (بسبب X-Frame-Options: SAMEORIGIN)، واستغلّ تفعيل Autocomplete لسرقة بيانات اعتماد المستخدم عبر مستمع Netcat. السلسلة دمجت XSS مع ضعف X-Frame-Options مع CSRF على وظيفة إنشاء API Key.
إجراء أمني بيتطلّب من المستخدم إثبات هويته بعاملين مستقلين — شيء يعرفه وشيء يملكه — بيقلّل خطر الوصول غير المصرَّح به حتى لو اتسرّبت كلمة المرور.
| النوع | الإيجابيات | السلبيات |
|---|---|---|
| SMS-based | سهل الاستخدام ومنتشر | عرضة لـ SIM Swapping والاعتراض والتصيّد |
| Email-based | مش محتاج جهاز إضافي | خطير لو البريد الإلكتروني نفسه مخترَق |
| TOTP | أكثر أمانًا من SMS/Email | محتاج إعداد وجهاز ثانوي |
| Authenticator Apps | بدون اعتماد على قنوات اتصال خارجية | غير مريح لو الجهاز ضاع أو اتعطّل |
كلمات مرور مؤقتة أحادية الاستخدام بتُولَّد وتُرسَل لجهاز المستخدم المسجَّل للتحقق من هويته. ميزتها الأساسية: حساسة للوقت وتنتهي بسرعة، مما يصعّب إعادة استخدامها من المهاجمين. TOTP بيولّد أكواد مبنية على مفتاح سرّي مشترك ووقت متزامن، صالحة عادة لـ30 ثانية فقط. Rate Limiting أساسي لمنع هجمات Brute-force على الـ OTPs — تقييد عدد محاولات التحقق خلال فترة زمنية محدَّدة.
# ابحث في Set-Cookie headers عن:
HttpOnly → غيابه = عرضة لسرقة عبر XSS
Secure → غيابه = عرضة للاعتراض عبر HTTP
SameSite → غيابه أو None بدون Secure = عرضة لـ CSRF
Max-Age → طويل جدًا أو غائب = جلسات لا تنتهي
# جرّب تعديل alg إلى none وإزالة التوقيع
# جرّب تبديل الخوارزمية من RS256 إلى HS256 (Algorithm Confusion)
# افحص الـ exp — هل منتهي الصلاحية بيُرفَض فعليًا؟
# افحص الـ Payload — هل فيه بيانات حساسة غير مشفَّرة؟
# جرّب تعديل role/admin claims وأعد توقيع التوكن بمفاتيح مُخمَّنة أو مكشوفة
| # | التحقق | الأداة/الطريقة | النتيجة المحتملة |
|---|---|---|---|
| 1 | رسائل خطأ تسجيل الدخول مختلفة لاسم المستخدم/كلمة المرور؟ | فحص يدوي + Burp Repeater | Username Enumeration |
| 2 | فيه Rate Limiting على محاولات الدخول؟ | Burp Intruder | Brute-force ممكن |
| 3 | Session ID بيتغيّر بعد تسجيل الدخول؟ | مقارنة الكوكي قبل/بعد | Session Fixation |
| 4 | JWT بدون تحقق صارم من alg؟ | jwt_tool / تعديل يدوي | None Algorithm Bypass |
| 5 | redirect_uri في OAuth بدون Whitelist صارمة؟ | تعديل المعامل يدويًا | Token Theft / Open Redirect |
الموديول ده غطّى اختبار المصادقة وإدارة الجلسات بعمق — من المفاهيم الأساسية ومنهجية WSTG-ATHN، مرورًا بالجلسات والكوكيز وCSRF، ووصولًا لتحليل متقدّم لـ JWT وOAuth وتقنيات تجاوز 2FA.
الفكرة الجوهرية للموديول: المصادقة وإدارة الجلسات مترابطتان بشكل عميق — ثغرة في أي طرف من السلسلة (كلمة مرور، جلسة، توكن، أو عامل ثانٍ) ممكن تُسقِط الدفاع بالكامل. المختبر المحترف بيفحص السلسلة كلها كوحدة واحدة، مش كل مكوّن بمعزل عن التاني.
في أي تقييم: ابدأ دايمًا بفهم نوع آلية المصادقة والجلسة المستخدَمة قبل أي استغلال. افحص رسائل الخطأ بعناية — غالبًا هي مصدر التسريب الأول. لو التطبيق بيستخدم JWT أو OAuth، خصّص وقت كافٍ لفحص بنية التوكن والتحقق من التوقيع قبل الانتقال لأي هجوم متقدّم. ووثّق كل خطوة، حتى الفاشلة.
نهاية نوتس الموديول الثاني — Authentication & Session Management Testing (eWPTXv3)