تأمين تطبيقات Electron: دليل عملي
إدارة الأسرار وIPC بأمان في تطبيقات سطح المكتب الحديثة.
لماذا يتطلب Electron عناية؟
يجمع تطبيق Electron متصفحًا وبيئة تشغيل Node.js. إذا تمكن عارض يحمل محتوى بعيدًا أو متأثرًا بالمهاجم من الوصول إلى Node، يتحول XSS واحد إلى تنفيذ كود عن بُعد على جهاز المستخدم. يعتمد تأمين Electron أساسًا على فصل هذين العالمين. يجب أن يحقق GitSwitch، عميل Git المبني على Electron وReact 19 والمحتفظ برموز GitHub ومفتاح Gemini API، هذا الفصل بدقة.
عقد العزل
| الإعداد | القيمة | السبب |
|---|---|---|
contextIsolation | مفعّل | يعمل preload والصفحة في سياقي JS منفصلين حتى لا تعبث الصفحة بالمتغيرات العامة ذات الصلاحيات |
sandbox | مفعّل | لا يملك العارض وصولًا مباشرًا إلى Node.js أو require أو fs أو child_process |
nodeIntegration | معطّل | لا ترى الصفحة وحدات Node المدمجة |
| الواجهة المكشوفة | قائمة سماح contextBridge | يعرض preload مجموعة صغيرة من الدوال المسماة بدلًا من ipcRenderer الخام |
IPC بوصفه حدًا للثقة
يمر كل فعل ذي صلاحيات عبر ipcMain.handle / ipcRenderer.invoke بقائمة صريحة للقنوات المسموح بها. تعامل العملية الرئيسية كل رسالة كمدخل غير موثوق: تتحقق من القنوات وتضبط الوسائط، وتضع مهلًا للعمليات الطويلة حتى لا يجمّد أمر Git متوقف التطبيق. لا يوجد جسر لتنفيذ أوامر اعتباطية؛ لكل قناة مهمة ضيقة.
التعامل مع الأسرار
لا تصل الرموز إلى localStorage ولا تبقى في العارض:
- عند التخزين: توجد رموز الوصول الشخصي إلى GitHub ومفتاح Gemini في مخزن أسرار النظام: Keychain على macOS وCredential Manager على Windows وlibsecret على Linux، بدلًا من ملف إعدادات نصي.
- عند الاستخدام: تُحجب المفاتيح من السجلات وتُمسح من الذاكرة بعد الاستخدام، حتى لا تسرّبها ملفات الأعطال أو السجلات المشتركة.
- عند النقل: Gemini API هو المسار الصادر الوحيد، وتُحصر الفروق المرسلة لتوليد رسالة commit في التغييرات التي يسجّلها المستخدم.
الخلاصة
الخيارات التي تسهّل Electron، مثل Node داخل العارض ووحدة remote القديمة وIPC الواسع، هي أيضًا مصدر الخطر. يعكس GitSwitch هذه الخيارات: عزل مفعّل، وsandbox مفعّل، وجسر صغير قابل للتدقيق، وأسرار في مخزن النظام. والنتيجة تطبيق مكتبي بواجهة ويب لا يمكن دفعه إلى تنفيذ كود لم يُبنَ لتنفيذه.