هجمات الـ Session والـ CSRF
رقم الـ session بقى زي مفتاح البيت. الدرس ده بيوريك 3 طرق الهاكر بياخد بيها المفتاح ده أو بيستغله: يسرقه، أو يزرعهولك قبل ما تدخل، أو يخلي متصفحك يفتح الباب بنفسه.
- تفرّق بين Session Hijacking و Session Fixation، وتعرف حماية كل واحد
- تشرح هجوم الـ CSRF من الأول للآخر، وليه الهاكر مش محتاج يشوف الكوكي
- تجرّب بنفسك
HttpOnlyوSecureوSameSiteوالـ CSRF token قدام هجمات حقيقية - تجاوب: ليه الـ Bearer token مش محتاج CSRF؟ وهل CORS بيحمي؟ وليه GET ميغيّرش داتا؟
1. Session Hijacking (خطف الجلسة)
دوس ▶ وتابع الكوكي وهو بيتنقل بين التلاتة.
| بيسرقه إزاي | الحماية |
|---|---|
XSS: كود JavaScript متحقن في صفحتك، زي review لمنتج، بيقرا document.cookie ويبعته للهاكر |
HttpOnly، وإنك تعمل escape لكل حاجة بتعرضها. {{ }} في Blade بتعمل كده، و {!! !!} لأ |
| التنصت على واي فاي مفتوح في كافيه | HTTPS و Secure |
| Malware على جهاز المستخدم | خارج إيدك، بس تقدر تقلل الضرر: عمر session قصير، وتطلب الباسورد تاني قبل العمليات الحساسة بـ password.confirm |
2. Session Fixation (تثبيت الجلسة)
دوس ▶ وتابع الكوكي وهو بيتنقل بين التلاتة.
لو السيرفر غيّر الرقم بعد الدخول، الـ AAA اللي مع الهاكر يبقى رقم لـ session فاضية ملهاش لازمة.
الحماية: غيّر رقم الـ session فوراً بعد الدخول، وبعد أي تغيير في الصلاحيات. لارافيل بيعمل كده جوه login()، والدوكيومنتيشن برضه بتقولك تنادي regenerate() بعد Auth::attempt. اعملها وإنت فاهم السبب.
| Hijacking | Fixation | |
|---|---|---|
| التوقيت | بعد الـ login | قبل الـ login |
| الهاكر بيعمل إيه | بيسرق رقمك | بيديك رقمه |
| الحماية الأساسية | HttpOnly و Secure و HTTPS ومنع XSS | تغيير رقم الـ session بعد الدخول |
في الـ Session Hijacking الهاكر بيسرق Session ID موجود، وفي الـ Session Fixation بيفرض على الضحية Session ID هو عارفه قبل الدخول. والحماية من التانية إن الـ ID يتعمله regenerate بعد الـ login.
3. CSRF (Cross-Site Request Forgery)
إنت عامل login في shop-lab، وفي tab تانية فتحت موقع شكله بريء: “اكسب آيفون مجاناً”. الموقع ده فيه form مخفي بيتبعت أول ما الصفحة تفتح:
<form action="https://shop-lab.test/account/email" method="POST">
<input type="hidden" name="email" value="hacker@evil.com">
</form>
<script>document.forms[0].submit()</script>دوس ▶ شغّل، أو امشي خطوة خطوة بالأسهم.
السيرفر شاف session صحيحة، فنفّذ. لاحظ إن الهاكر عمره ما شاف الـ cookie بتاعتك. هو بس استغل إن المتصفح بيبعتها لوحده.
الحماية الأولى: CSRF Token
- السيرفر بيحط token عشوائي في الـ session، وبيحطه كمان جوه كل form كـ hidden input. ده اللي
@csrfبيعمله في Blade. - لما الـ form يتبعت، السيرفر بيقارن الـ token اللي جه مع الـ form باللي في الـ session.
- الموقع الشرير ميقدرش يعرف الـ token، لأن الـ Same-Origin Policy بتمنع أي موقع يقرا صفحات موقع تاني. يقدر يبعت request، بس ميقدرش يقرا الرد.
في لارافيل، لو الـ token غلط أو مش موجود هيرجّع 419 Page Expired. اسمها “expired” لأن أكتر سبب للخطأ ده إن الـ session خلصت فالـ token القديم بطل.
الحماية التانية: SameSite
| القيمة | إمتى الـ cookie تتبعت من موقع تاني | مثال |
|---|---|---|
Strict |
عمرها ما تتبعت | حتى لو ضغطت لينك من فيسبوك لموقعك، هتوصل مش عامل login |
Lax |
بس لما تتنقل لصفحة بـ GET (زي إنك تدوس لينك)، ومش مع POST ولا مع الصور | الـ default الحديث، وتوازن ممتاز |
None |
دايماً، ولازم يبقى معاها Secure |
widget جوه iframe في موقع تاني |
جرّب كل ده بنفسك
ابدأ والحمايات كلها مقفولة وأطلق الهجمات. وبعدين شغّل حماية حماية، وشوف كل واحدة بتقفل أنهي باب:
3 أسئلة CSRF بتتسأل كتير
ليه الـ API اللي بيستخدم Authorization: Bearer مش محتاج CSRF token؟
لأن الـ token ده مش cookie، والمتصفح مش بيبعته لوحده. الكود بتاعك هو اللي بيحطه في الـ header بإيده، والموقع الشرير ميعرفوش. CSRF مشكلة أي حاجة المتصفح بيبعتها أوتوماتيك، زي الـ cookies و Basic Auth.
CORS بيحمي من CSRF؟ لأ، وده فخ مشهور. الـ CORS بيتحكم في مين يقدر يقرا الرد. لكن form عادي بـ POST بيتبعت من غير preflight، والسيرفر بينفّذه قبل ما المتصفح يقرر يدّي الرد للـ JavaScript ولا لأ. يعني الضرر بيكون حصل خلاص. CORS بيحمي الداتا إنها تتقري، مش السيرفر إنه ينفّذ.
ليه ممنوع تغيّر داتا بـ GET؟
- الـ GET المفروض يبقى safe، يعني ميغيّرش أي حاجة.
- لينك في أي موقع بيوديك على
/cart/clearهيفضّي سلتك بضغطة واحدة، لأنLaxبتبعت الـ cookie مع التنقل بـ GET. ومعSameSite=Noneأو في المتصفحات القديمة، حتى<img src="/cart/clear">يكفي من غير ولا click. - المتصفحات ومحركات البحث بتعمل prefetch للينكات، يعني ممكن Google نفسه يفضّي سلتك.
الـ CSRF بيستغل إن المتصفح بيبعت الـ cookies لوحده، والحماية منه CSRF Token و SameSite، ومفيش GET بيغيّر داتا.
أسئلة الإنترفيو
فكّر في إجابتك الأول، وبعدين افتح السؤال.
01الفرق بين Session Hijacking و Session Fixation؟
في الـ Hijacking الهاكر بيسرق الـ ID بعد الدخول، والحماية HttpOnly و Secure و HTTPS ومنع XSS. في الـ Fixation الهاكر بيزرع ID يعرفه قبل الدخول، والحماية إن رقم الـ session يتغيّر بعد الدخول.
02يعني إيه CSRF وإزاي تمنعه؟
موقع تاني بيخلي متصفحك يبعت request لموقعك، والمتصفح بيلزق الـ cookies لوحده. المنع: CSRF token في كل form بيغيّر داتا، و SameSite cookies، ومفيش GET بيغيّر داتا.
03ليه الـ API اللي بالـ Bearer token مش محتاج CSRF token؟
لأن المتصفح مش بيبعت الـ header ده لوحده، والكود هو اللي بيحطه. الـ CSRF مشكلة الـ credentials اللي بتتبعت أوتوماتيك.
04CORS بيحمي من CSRF؟
لأ. الـ CORS بيمنع قراية الرد، مش تنفيذ الـ request. والـ form العادي بـ POST مبيعملش preflight أصلاً، فالسيرفر بينفّذ قبل أي قرار من المتصفح.
05لو SameSite=Lax موجودة، لسه محتاج CSRF token؟
أيوه: defense in depth، ومتصفحات قديمة، و GET endpoints بتغيّر داتا (Lax بتبعت الكوكي مع التنقل بـ GET)، وإن الـ site معناه الـ domain الأساسي فـ subdomain متخترق يعتبر same-site.
06إيه اللي بيرجّع 419 في لارافيل؟
CSRF token مش موجود أو مش مطابق للي في الـ session. اسمها Page Expired لأن أشهر سبب إن الـ session خلصت فالـ token القديم بطل.
07إزاي XSS بيوصّل لسرقة الحساب، وإيه أول خط دفاع؟
الـ script المتحقن بيقرا document.cookie ويبعت الـ session للهاكر. أول خط دفاع إنك تعمل escape لكل output (في Blade {{ }} مش {!! !!})، وبعده HttpOnly عشان حتى لو XSS حصل ميقدرش يقرا الكوكي.