لقد أجريت تدقيقاً أمنياً لمشاريعي الجانبية — إليكم ما وجدته
لقد أجريت مؤخراً تدقيقاً لجميع مشاريعي الجانبية. فحصت الواجهات الخلفية (backends) المبنية بـ FastAPI، وبوتات Telegram، وتطبيقات الويب. كنت أظن أنني حذر.
لكنني كنت مخطئاً.
لقد وجدت ثغرات حقيقية قمت بالفعل بإطلاقها في بيئة الإنتاج (production). هذه ليست مشكلات نظرية، بل هي أخطاء ارتكبتها أثناء محاولتي العمل بسرعة.
إليكم المشكلات الرئيسية التي وجدتها وكيفية إصلاحها:
- المصادقة المشروطة (Conditional Authentication) كتبت كوداً لا يتحقق من مفاتيح API إلا إذا كان هناك "سر" (secret) موجود. إذا نسيت ضبط هذا السر في بيئة العمل (environment)، يتم تخطي عملية التحقق تماماً، مما جعل واجهة برمجة التطبيقات (API) الخاصة بي مفتوحة للجميع.
- الإصلاح: لا تجعل المصادقة مشروطة أبداً. إذا كان السر مفقوداً، يجب أن يطلق التطبيق خطأً ويتوقف عن العمل.
- تسريب المفاتيح في سجل Git
وجدت مفاتيح API قديمة في سجل Git الخاص بي. كنت قد نقلتها إلى ملفات
.envلاحقاً، لكن Git يحتفظ بكل نسخة قديمة من الكود الخاص بك للأبد.
- الإصلاح: تعامل مع أي مفتاح تم إرساله (commit) إلى Git على أنه مخترق. قم بإبطاله فوراً. استخدم أدوات مثل
git-filter-repoلتنظيف سجلك.
- نقاط نهاية التصحيح (Debug Endpoints) المتبقية تركت نقاط نهاية (endpoints) في بيئة الإنتاج تعرض إعدادات قاعدة البيانات وإعدادات النظام الخاصة بي. هذه النقاط مفيدة أثناء التطوير ولكنها خطيرة في البيئة الفعلية.
- الإصلاح: أضف إزالة نقاط نهاية التصحيح إلى قائمة التحقق الخاصة بالنشر (deployment checklist).
- رسائل خطأ مفصلة للغاية (Verbose) كنت أرسل أخطاء النظام الخام إلى المستخدم. تكشف هذه الأخطاء عن مسارات الملفات، وأنواع قواعد البيانات، وإصدارات المكتبات المستخدمة. يمكن للمهاجم استخدام هذه البيانات لاستهداف نظامك.
- الإصلاح: قم بتسجيل الخطأ الكامل داخلياً لنفسك. أرسل رسالة عامة مثل "Internal Server Error" إلى العميل.
- ثغرات XSS عبر
innerHTMLاستخدمتinnerHTMLلعرض بيانات المستخدم في الواجهة الأمامية (frontend). هذا يسمح للمهاجمين بحقن برمجيات (scripts) في موقعك.
- الإصلاح: قم دائماً بتنقية البيانات (sanitize) أو استخدم
textContentبدلاً منinnerHTML.
- غياب تحديد معدل الطلبات (Rate Limiting) كانت لدي نقاط نهاية تستدعي نماذج ذكاء اصطناعي مكلفة دون قيود. يمكن لمستخدم واحد أن يتسبب في فاتورة ضخمة خلال دقائق.
- الإصلاح: المصادقة تمنع المستخدمين غير المصرح لهم، أما تحديد معدل الطلبات فيمنع المستخدمين المصرح لهم من إساءة استخدام نظامك. أنت بحاجة لكليهما.
- إعدادات CORS متساهلة
استخدمت
allow_origins=["*"]في البرمجيات الوسيطة (middleware). هذا يسمح لأي موقع إلكتروني بإرسال طلبات إلى واجهة برمجة التطبيقات (API) الخاصة بك.
- الإصلاح: اسمح فقط بنطاقاتك (domains) المحددة في بيئة الإنتاج.
- تسريب الملفات لقد كتبتُ كوداً يقوم بإنشاء ملفات مؤقتة، لكنه فشل في حذفها إذا تعطلت العملية. هذه الملفات تبقى على خادمك للأبد.
- الحل: استخدم كتلة
try-finallyلضمان حذف الملفات حتى في حالة حدوث خطأ.
نادراً ما تكون المشكلات الأمنية مقصودة، بل هي نتيجة لقول "سأقوم بإصلاح هذا لاحقاً". ولكن "لاحقاً" لا يأتي أبداً.
اجعل الأمن جزءاً من سير عملك منذ اليوم الأول. افحص الكود الخاص بك قبل الـ commit وقبل الـ deploy.
المصدر: https://dev.to/justjinoit/i-audited-my-own-side-projects-for-security-issues-heres-what-i-found-1ahb