00:00:00هذا الأمر خطير وليس مزاحاً، لقد مرت بضع ساعات عصيبة، لأنه وقع
00:00:06هجوم ضخم على سلسلة التوريد الخاصة بـ Axios، نعم، Axios التي لديها أكثر من 80 مليون
00:00:14تحميل أسبوعي.
00:00:15الآن، لنبدأ بالأهم.
00:00:18لكي تتحقق مما إذا كنت متضرراً، ستجد مرفقاً رابطاً لمقال، و
00:00:23سأشارك المزيد من التفاصيل بعد قليل، لكن هذا مهم، لكي تتحقق مما إذا
00:00:27كنت قد تضررت، عليك اتباع هذا الرابط أدناه وتشغيل الأوامر التي تراها هناك
00:00:32الخاصة بنظام تشغيلك، Mac OS، Linux، Windows، جميعها متضررة.
00:00:37عليك تشغيل هذه الأوامر إذا كنت متضرراً.
00:00:40وخاصة إذا أظهرت هذه الخطوات هنا أن نظامك قد اختُرق، فستحتاج إلى
00:00:49تبديل أسرارك، وتغيير كلمات مرورك، واعتبار بيانات اعتمادك، ومفاتيح API
00:00:55الموجودة على نظامك، وكل شيء على نظامك، مسروقاً.
00:01:00اعتبر كلمات مرورك مسروقة، غيرها كلها، وعطل مفاتيح API، هذا أمر مهم حقاً.
00:01:07الآن، ما الذي حدث بالضبط؟
00:01:09Axios هي بالطبع مكتبة JavaScript شهيرة جداً، وهي مكتبة يمكن استخدامها لإرسال طلبات HTTP
00:01:17من تطبيق React مثلاً إلى واجهة برمجة تطبيقات خلفية (backend API).
00:01:22يتم استخدامها بكثرة كما ترون، وقد تم حقن بعض الأكواد الخبيثة في
00:01:28هذه المكتبة.
00:01:29الآن، هذا لا يعني أن المواقع التي تستخدم تلك المكتبة قد تأثرت.
00:01:36بل يعني بدلاً من ذلك أن الأنظمة التي قمت بتثبيت تلك المكتبة عليها، جهاز MacBook الخاص بك، أو
00:01:41حاسوبك الشخصي، أو ربما ذاك الخادم الافتراضي (VPS) حيث قمت ببناء موقعك، هي التي تم اختراقها.
00:01:50إذا قمت بتشغيل npm install، أو bun install، أو npm update، أو bun update، أو أي شيء من هذا القبيل في
00:01:57الساعات القليلة الماضية، فهناك خطر كبير بأنك قد تضررت.
00:02:00مرة أخرى، لقد شاركت تلك الفحوصات التي يجب عليك إجراؤها للتأكد مما إذا كنت متضرراً.
00:02:05الآن، كيف حدث كل هذا بالضبط وما هو هجوم سلسلة التوريد (supply chain attack) تحديداً؟
00:02:10سأشارك أيضاً، بالمناسبة، كيف يمكنك تأمين نفسك ضد هجمات كهذه في المستقبل.
00:02:15لكن أولاً، دعونا نفهم ما الذي يحدث بالضبط وما هو هجوم سلسلة التوريد.
00:02:20هجوم سلسلة التوريد هو ببساطة هجوم لا يستهدف كود تطبيقك مباشرة.
00:02:24فالمهاجم لا يحاول التسلل مباشرة إلى نظامك أو قاعدة الكود الخاصة بك.
00:02:31بدلاً من ذلك، يستغلون حقيقة أن كود تطبيقك عادةً ما يعتمد على مكتبات (dependencies)، والتي بدورها
00:02:37تعتمد على مكتبات أخرى.
00:02:38لذا لديك تلك السلسلة من التبعيات والهجوم يستهدف هذه السلسلة.
00:02:45لذا فهو يحدث في مرحلة تسبق الكود الخاص بك (upstream).
00:02:48حيث تحتوي إحدى هذه التبعيات على كود خبيث بسبب هجوم تم فيه
00:02:54حقن هذا الكود فيها، وليس لأن المطور المسؤول عنها يحاول مهاجمتك.
00:02:58ولكن بدلاً من ذلك، كما في هذه الحالة، يتم اختراق حساب المطور
00:03:03ويستخدم المهاجم ذلك لحقن كود خبيث في مكتبة ما، أو حزمة ما،
00:03:10والتي قد تستخدمها حزمة أخرى، ومن ثم قد يستخدم الكود الخاص بك تلك الحزمة التي
00:03:16تستخدم الحزمة الخبيثة، أو ربما يسحب كود تطبيقك التبعية الخبيثة مباشرة.
00:03:23في كلتا الحالتين، أصبحت إحدى تبعياتك الآن تأتي فجأة مع كود خبيث.
00:03:28وفي اللحظة التي تقوم فيها بتشغيل npm install أو أي شيء من هذا القبيل، أو تقوم بالتحديث، يتم
00:03:36تحميل تلك الحزمة على نظامك، الحزمة الخبيثة المتضررة، ومن ثم يمكنها تنفيذ
00:03:41كود خبيث على نظامك، وعادةً ما يكون ذلك بمساعدة سكربتات ما بعد التثبيت (post install scripts).
00:03:47في حال كنت لا تعرف، فإن npm لديه هذه الآلية من السكربتات.
00:03:56جميعنا نستخدمها في مشاريعنا، على سبيل المثال، لتشغيل خادم تطوير، أو لبناء مشروعنا،
00:04:01أو لتشغيل الاختبارات، وأمور من هذا القبيل.
00:04:04وهناك تحديداً أيضاً سكربتات ما بعد التثبيت، والتي قد لا تستخدمها عندما
00:04:11تقوم ببناء تطبيق React مثلاً، ولكن المكتبات غالباً ما تستخدمها أو
00:04:17قد تستخدمها لتشغيل بعض الأكواد على نظامك بعد تثبيت المكتبة، وعادةً ليس
00:04:23للقيام بأي شيء خبيث أو سيء، بل مثلاً لترجمة بعض الأكواد، أو إنشاء ملف ثنائي (binary) قد
00:04:31تحتاجه تلك المكتبة، أو تجهيز نظامك بأي شكل من الأشكال حتى يتمكن فعلياً
00:04:36من استخدام المكتبة التي قمت بتحميلها للتو.
00:04:40هذه هي الفكرة من سكربت ما بعد التثبيت.
00:04:42فهو يسمح للحزمة بتحديد كود يجب تنفيذه بعد أن يتم تثبيتها
00:04:49عن طريق npm install مثلاً، وهذا بالضبط ما يتم استغلاله عادةً في تلك
00:04:55الهجمات على سلسلة التوريد.
00:04:57حيث يحقن المهاجم كوداً خبيثاً في حزمة ما هو في الأساس
00:05:04سكربت ما بعد التثبيت يتم تنفيذه تلقائياً بمجرد تثبيت الحزمة المصابة.
00:05:10عادةً ما يكون هذا الكود غامضاً (obfuscated) بحيث لا يسهل قراءته.
00:05:14يمكن أن يكون مشفراً بصيغة base64 لكي لا تكتشفه الماسحات التي
00:05:20تفحص الحزم بحثاً عن كود خبيث، و/أو قد يتم تحميل الكود الخبيث.
00:05:24لذا فإن سكربت ما بعد التثبيت، كما في حالة هجوم Axios هنا، لا
00:05:30يحتوي مباشرة على الكود الخبيث.
00:05:32بدلاً من ذلك، يتصل بخادم ويقوم بتحميل الكود من هناك.
00:05:36هذا هو ما حدث هنا.
00:05:37ولدينا تقرير مفصل حول ما حدث بالضبط خلال ذلك الهجوم.
00:05:41ستجدونه مرفقاً إذا أردتم قراءة جميع التفاصيل، ولكننا نتعلم منه
00:05:45بشكل أساسي أن إصدارين من حزمة Axios، وهما 1.14.1 و 0.30.4 قد تأثرا، وتم اختراقهما
00:05:57في النهاية، وتم ذلك من خلال وصول المهاجم إلى حساب أحد
00:06:02المطورين المسؤولين عن حزمة Axios واستخدموا ذلك الحساب لنشر إصدار جديد من حزمة Axios
00:06:08يحتوي على تبعية (dependency) والتي بدورها تحتوي على سكربت ما بعد التثبيت ذاك.
00:06:14لذا لم تكن حزمة Axios نفسها هي التي تحتوي على سكربت ما بعد التثبيت، بل
00:06:19بدلاً من ذلك كانت حزمة أخرى، وهي حزمة plaincryptojs، التي أنشأها المهاجم،
00:06:25والتي غرضها الوحيد هو امتلاك سكربت ما بعد التثبيت يقوم بتحميل وتشغيل كود
00:06:31خبيث.
00:06:32لذلك تم اختراق حزمة Axios عن طريق إضافة plaincryptojs كعنصر تبعية لـ Axios.
00:06:39هذه حزمة خبيثة.
00:06:40لا تخدم أي غرض آخر سوى تحميل ذلك الكود الخبيث، وفقط بإضافة هذه
00:06:46التبعية إلى Axios، انتهى الهجوم فعلياً.
00:06:52هذه الحزمة لم يتم استيرادها في كود المصدر الخاص بـ Axios في أي مكان.
00:06:56هي تمتلك فقط سكربت ما بعد التثبيت وهذا كل شيء.
00:06:59كما ذكرنا، فهي قادرة بعد ذلك على تحميل وتشغيل كود من خوادم لـ Windows و Linux
00:07:05للقيام بماذا؟
00:07:06حسناً، لسرقة الكثير من الأشياء.
00:07:08لذا إذا تأثر نظامك، فكما ذكرت في البداية، بيانات الاعتماد، ومفاتيح API، ورموز التشفير (crypto tokens)،
00:07:14كل هذه الأشياء يتم جمعها وتسريبها بواسطة حصان طروادة (trojan) يتم تحميله بواسطة سكربت ما بعد
00:07:21التثبيت ذاك.
00:07:22هكذا عمل ذلك الهجوم.
00:07:24وهكذا عملت هجمات مماثلة في الماضي.
00:07:29الآن ما هو مثير للاهتمام، بالمناسبة، هو أن هذا الهجوم بدأ قرابة منتصف الليل،
00:07:36تحديداً بعد منتصف الليل بالتوقيت العالمي المنسق اليوم، قبل بضع ساعات.
00:07:40واستمر لبضع ساعات، وكلا إصداري Axios رقم 1.14.1 و 0.30.4 تأثرا خلال
00:07:5040 دقيقة، 39 دقيقة لنكون دقيقين.
00:07:53لذا كان هذا هجوماً منظماً ومخططاً له جيداً.
00:07:56من الواضح أن إنشاء هذه الحزمة الإضافية حدث على ما أظن قبل 18 ساعة من بدء
00:08:03الهجوم.
00:08:04لقد كان هجوماً منظماً ومخططاً له للغاية.
00:08:06الآن ما هو غريب هنا هو أن NPM لديها هذه الآلية المسماة النشر الموثوق (trusted publishing)، والتي
00:08:14يمكن استخدامها من قبل مطوري الحزم.
00:08:17والفكرة هنا هي أن ذلك يحد من عملية نشر إصدارات جديدة من الحزمة لتكون ضمن عملية
00:08:26محددة بوضوح حيث يتعين عليك بناء ونشر إصدار جديد من خلال
00:08:32أحد مزودي خدمات CI/CD المدعومين مع إعداد معين يجب عليك اتباعه.
00:08:38والفكرة هنا هي أنه حتى لو تمت سرقة بيانات اعتماد حساب NPM الخاص بك، نظرياً،
00:08:46لا يستطيع المهاجم نشر إصدار جديد من حزمتك من جهازه لأنه
00:08:51بحاجة للمرور بتلك العملية.
00:08:52الآن قد تجادل بأنه إذا تم اختراق حساب GitHub الخاص بالمطور، فربما
00:08:59يمكن دفع إصدار خبيث إلى GitHub، مما يؤدي إلى تفعيل تدفق عمل النشر (deploy workflow) هنا وبالتالي
00:09:06يتم نشر الكود الخبيث عبر عملية النشر الموثوق تلك.
00:09:11ولكن وفقاً للتقرير الأمني هنا، ليس هذا ما حدث في هذه الحالة.
00:09:16لأن فريق Axios يستخدم عملية النشر الموثوق هذه للفرع 1.x، وليس
00:09:21للفرع 0.30، بل للفرع 1.x.
00:09:26ولكن وفقاً لهذا التقرير، لا يوجد أي سجل (commit) أو هجوم في مستودع GitHub الخاص بـ Axios.
00:09:33لذلك لم يتم دفع أي كود إلى GitHub يحتوي على تلك النسخة المخترقة من Axios.
00:09:40وبالتالي ما كان ينبغي لعملية النشر الموثوق أن تتفعل.
00:09:44بدلاً من ذلك، يذكر هذا التقرير أن المهاجم لابد وأنه حصل على رمز وصول NPM
00:09:50كلاسيكي طويل الأمد لنشر هذا الإصدار الخبيث أو المخترق من Axios لأن
00:09:56الإصدار كان موجوداً فقط على NPM، وليس على GitHub.
00:10:01ربما هذا خاطئ.
00:10:02ربما مر الهجوم عبر GitHub.
00:10:05ولكن إذا كان صحيحاً، فليس من الواضح لي كيف عمل ذلك بالضبط لأنه نظرياً،
00:10:11لا ينبغي أن تكون طريقة النشر هذه ممكنة عندما تكون خاصية النشر الموثوق مفعلة.
00:10:15لست متأكداً ما إذا كانت هذه ثغرة أمنية أو مشكلة ما في NPM هنا.
00:10:20أن بعض الرموز الحالية طويلة الأمد لا يزال من الممكن استخدامها حتى مع تفعيل النشر الموثوق.
00:10:26هذا ما تم تفعيله.
00:10:27هذا شيء لم أتمكن من معرفة كيف حدث بالضبط.
00:10:32وهناك منشور هنا، مشكلة (issue) على GitHub في مكتبة Axios حيث تم الإبلاغ عن هذا الهجوم.
00:10:39بالمناسبة، ملاحظة جانبية، تم إنشاء المزيد من هذه المشكلات وتم حذفها من قبل الحساب
00:10:40المخترق للمطور.
00:10:45هذا المنشور، هذه المشكلة صمدت وتم إيقاف الهجوم في النهاية.
00:10:48لقد استعادوا الوصول إلى حسابهم، ذلك المطور الذي تأثر.
00:10:52وفي ذاك المنشور، في تلك المشكلة، ينشر المطور ويقول إنهم يستخدمون النشر
00:10:56الموثوق وليس من الواضح كيف حدث ذلك بالضبط.
00:11:03إليك نظرية تمت مشاركتها.
00:11:07ولكن فهمي هو أن هذه النظرية ستظل تتطلب دفع نسخة جديدة خبيثة أو مخترقة
00:11:09إلى GitHub، ولكن مرة أخرى، كل هذا غير واضح.
00:11:16ما هو واضح هو أن النسخ المخترقة قد نُشرت وانتهى بها المطاف على NPM وبالتالي
00:11:20يمكن تحميلها على الأنظمة وسرقة الأشياء من هناك.
00:11:25وبالطبع مع وجود أكثر من 80 مليون تحميل أسبوعي، هناك الكثير من الضرر الذي يمكن إلحاقه خلال
00:11:29بضع ساعات.
00:11:35من الواضح أن التحميلات لا تتوزع بالتساوي على مدار ساعات اليوم، ولكن هذا
00:11:37بالتأكيد رقم ضخم ويمكننا أن نفترض أن الآلاف، أو عشرات الآلاف من الأنظمة
00:11:44قد تأثرت خلال تلك الساعات القليلة.
00:11:51بالطبع، لم يكن هذا أول هجوم على سلسلة التوريد.
00:11:55على مدار الأشهر الماضية، رأينا هجمات متعددة.
00:11:59هجوم كبير واحد في نهاية العام الماضي، هجوم shy hulu حيث تم تنفيذ عدة حزم
00:12:01على NPM وكان له نمط مشابه، حقن كود خبيث وتنفيذه
00:12:08على الأنظمة التي حملت تلك الحزم المخترقة ومن ثم سرقة بيانات الاعتماد وأشياء أخرى.
00:12:16لذا فهذا هجوم كبير واحد.
00:12:21وبعد ذلك قبل بضعة أيام فقط وقع حادث مماثل في نظام بايثون البيئي.
00:12:22لذا فالأمر لا يقتصر على جافا سكريبت حيث تأثرت حزمة lightllm.
00:12:25وهي حزمة شهيرة جداً تجعل من السهل استخدام مزودي الذكاء الاصطناعي من خلال واجهة واحدة مريحة
00:12:31وقد تعرضت هي أيضاً لهجوم مماثل وتأثرت.
00:12:37وبالتالي فالأمر بالطبع لا يقتصر على جافا سكريبت فقط.
00:12:43وأعتقد أن هناك عدة أسباب تجعلنا نرى المزيد من هذه الهجمات تحدث.
00:12:49لأنه نظرياً، هذه الأنواع من الهجمات كان يمكن أن تحدث وربما حدثت في
00:12:52الماضي أيضاً ولكن من الواضح أنها أصبحت أكثر تكراراً الآن وأعتقد أن هناك عدة
00:12:57أسباب لذلك.
00:13:03أحد الأسباب الكبيرة بالطبع هو أننا في وقت يتم فيه كتابة وتوليد
00:13:08أكواد أكثر من أي وقت مضى.
00:13:11أعني، يمكنك النظر إلى مقاييس مختلفة.
00:13:17على سبيل المثال رأيت هذا الرسم البياني مؤخراً يوضح أن عدد مستودعات GitHub الجديدة التي يتم
00:13:19إنشاؤها وصل إلى أعلى مستوى له على الإطلاق، وبالطبع هذا بسبب الذكاء الاصطناعي.
00:13:22حيث يعمل الناس على مشاريع، ويقومون بتوليد أكواد.
00:13:27لدينا إنتاج من الأكواد أكثر من أي وقت مضى، وبالطبع هذا يعني أنه مع كتابة الكثير من البرامج،
00:13:31وتوليد الكثير من الأكواد، أصبح سطح الهجوم (attack surface) أكبر بكثير.
00:13:35هناك المزيد من الأهداف.
00:13:42هناك المزيد من الأشخاص الذين يبنون أو يكتبون أكواداً ويقومون بتثبيت الحزم.
00:13:47لذا فالأمر مغرٍ أكثر من أي وقت مضى.
00:13:48ليس الأمر أنه لم يكن مغرياً في الماضي ولكن الآن هناك أشخاص أكثر من أي وقت مضى
00:13:52يمكن مهاجمتهم.
00:13:54لذا فهذا بالطبع سبب كبير واحد.
00:13:59ببساطة أصبح القيام بهذه الهجمات أكثر إثارة للاهتمام ولكنه ليس السبب الوحيد.
00:14:00أعتقد أن هناك سبباً آخر بالطبع يتعلق أيضاً بالذكاء الاصطناعي وهو أولاً، أن شن هجمات كهذه
00:14:03بمساعدة الذكاء الاصطناعي ربما أصبح أسهل، لأن الكود الخبيث يمكنه بالطبع
00:14:07أن يتم توليده وكتابته بمساعدة الذكاء الاصطناعي، لذا فإن المهارات التقنية اللازمة لشن مثل هذه
00:14:15الهجمات أصبحت متاحة أكثر مما كانت عليه في الماضي كما أزعم، رغم أنه كان بإمكانك شراء سكربتات
00:14:21أو أحصنة طروادة كهذه في الشبكة المظلمة (darknet) ولكنها لا تزال الآن أكثر سهولة في الوصول للناس.
00:14:28بالطبع لا يتعلق الأمر فقط بالجانب الجيد للذكاء الاصطناعي في أن المزيد من الناس يمكنهم بناء برمجيات وتحويل
00:14:33أفكارهم إلى أعمال تجارية أو ما شابه ولكن هناك أيضاً الجانب السيئ.
00:14:40المزيد من الناس يمكنهم القيام بأشياء سيئة متعلقة بالكود بفضل الذكاء الاصطناعي وهذا أحد الأسباب.
00:14:46يمكنك أيضاً أن تجادل بأن مطوري الحزم ومطوري المكتبات بالطبع مغمورون
00:14:50بطلبات السحب (pull requests).
00:14:55هذه مشكلة كبيرة أخرى نواجهها هذه الأيام وهي أنك إذا كنت مطوراً لمشروع مفتوح المصدر فهناك
00:15:01طلبات سحب قادمة أكثر من أي وقت مضى، لذا قد لا تكون حذراً للغاية بشأن ما
00:15:02تقوم بدمجه.
00:15:07ليست هذه هي المشكلة هنا لكي أكون واضحاً.
00:15:13في هجوم Axios هذا من الواضح أنه كان حساباً مخترقاً ولكن يمكنك نظرياً
00:15:14طرح الحجة بأنه من الممكن للمطورين أن يدمجوا كوداً خبيثاً أو كوداً
00:15:16يثبت تبعيات خبيثة في مكتبتهم لأنهم ببساطة أغفلوها أو ربما
00:15:22لأن لديهم عملية مراجعة كود مؤتمتة بالكامل لا تكتشف ذلك.
00:15:29هم فقط يعتمدون على الذكاء الاصطناعي.
00:15:34مرة أخرى، ليس هذا هو الحال هنا ولكن يمكن التفكير في أن هذا قد يستخدم في المستقبل من قبل المهاجمين
00:15:38بأن يحقنوا كوداً خبيثاً في قواعد الأكواد لأن الناس ببساطة لا يدققون.
00:15:40بالإضافة إلى ذلك، عندما تستخدم كود Cloth، أو OpenCloth أو غيره على نظامك للقيام بجميع
00:15:45أنواع المهام لك، ليس فقط لمساعدتك في العمل على البرمجيات بل ربما لإدارة نظامك
00:15:51ككل، بالطبع لمهام معينة قد يقرر OpenCloth، أو Cloth code، أو codecs أو غيرها
00:15:56أن تكتب سكربت ما وتشغل كوداً معيناً للقيام بمهمة طلبتها منها وهذا
00:16:01الكود الذي ولدته قد يعتمد أيضاً على تبعيات مثل Axios.
00:16:09لذا مرة أخرى سطح الهجوم يكبر، وهذه حجتي الأولى مجدداً ولكن بعيداً
00:16:15عن مجرد تطوير البرمجيات الكلاسيكي، ولجميع هذه الأسباب وربما أسباب أخرى كثيرة
00:16:20لم أفكر فيها هنا، أصبحت هذه الهجمات أكثر ربحية، وأسهل في التنفيذ وأكثر
00:16:24إثارة للاهتمام، ولهذا أنا متأكد من أننا سنرى المزيد من هذه الهجمات في المستقبل.
00:16:30الآن ما الذي يمكنك فعله لمنع مثل هذه الهجمات ولحماية نفسك؟
00:16:37خطوة أمنية كبيرة واحدة، شيء يمكنك القيام به في جميع مشاريعك التي تعمل
00:16:43بها على تطبيقات وما إلى ذلك، عندما تستخدم أدوات مثل pnpm بدلاً من npm لإدارة
00:16:47تبعياتك، يمكنك إضافة إعداد "الحد الأدنى لعمر الإصدار" (minimum release age) لملف pnpm workspace yaml الخاص بك
00:16:55وتمتلك bun ميزة مماثلة، حيث يمكنك إضافة ملف bunfig.toml إذا كنت تستخدم bun كمدير حزم
00:17:02ولديهم أيضاً إعداد الحد الأدنى لعمر الإصدار الذي يمكنك إضافته في ذاك الملف، فماذا يفعل هذا؟
00:17:09ببساطة يضمن أنه كلما قمت بتثبيت حزمة، مهما كانت الطريقة، فإنه يثبت فقط الحزم
00:17:15التي لا يقل عمرها عن ذاك القدر أو نسخ الحزم التي لا يقل عمرها عن ذاك القدر، فإذا كانت الحزمة
00:17:21قد تم اختراقها قبل خمس ساعات ولكن لديك قاعدة تثبت فقط النسخ التي لا يقل عمرها
00:17:27عن ثلاثة أيام، فينبغي أن تكون في أمان، هذه هي الفكرة، وللأسف فإن npm نفسها
00:17:34لا تمتلك ذلك حالياً. فقط للتأكد من أن هذا واضح، نحن لا نزال نتحدث عن الحزم
00:17:39المستضافة على npm، ليست هذه هي المشكلة، أنا أتحدث عن مدير الحزم هنا
00:17:46وبالطبع يمكنك استخدام bun أو pnpm لتحميل تلك الحزم من npm وإذا كنت تستخدمهما
00:17:51بدلاً من مجرد أداة npm، فعندئذٍ يمكنك الاستفادة من إعدادات كهذه
00:17:56والتي تمنحك ببساطة تلك الطبقة الأمنية الإضافية، لأنه عادةً في الماضي تم
00:18:03اكتشاف تلك الهجمات خلال بضع ساعات، فإذا كان لديك عتبة لمدة ثلاثة أيام
00:18:08على سبيل المثال، فسيتم اكتشاف معظم هذه الهجمات بحلول ذلك الوقت وستكون قد انتهت، الأمر ليس
00:18:14آمناً بنسبة 100% بالطبع، فالهجوم قد يستمر لفترة أطول، ولكنه يمنحك ميزة واضحة وهو
00:18:20بالتأكيد شيء جيد يجب القيام به. الآن لتكون أكثر أماناً، يمكنك ويجب عليك التفكير في استخدام
00:18:25حلول مثل doppler، وهذا ليس إعلاناً مدفوعاً، هذا مجرد مثال واحد وهناك بدائل
00:18:32لقد بنيت بديلي الخاص في الواقع والذي أستخدمه بنفسي وهي عبارة عن خدمات أو أدوات
00:18:39تدير أسرارك، لذا فشيء مثل مفتاح OpenAI API الخاص بك، يمكنك وضعه في ملف
00:18:44dot env ولكن من الأفضل تخزينه مشفراً في أو بمساعدة خدمة مثل doppler على
00:18:49خوادمهم أو في استضافة ذاتية على خادم افتراضي تملكه ثم تقوم بحقنه في البيئة
00:18:55الخاصة بتطبيقك ليكون على علم به ويستخدمه عند الحاجة، بحيث إذا كان هناك
00:19:02حصان طروادة على نظامك يقوم ربما بجلب كل ملفات dot env الخاصة بك ويستخرج المعلومات
00:19:08منها، فإنه لن يجد أي أسرار هناك، هذه هي الفكرة. لذا فإن تخزين تلك الأسرار
00:19:13ليس في ملفات نصية على نظامك، وملف dot env هو مجرد ملف نصي في النهاية، بل بدلاً من ذلك
00:19:20تخزينها مشفرة في مكان آخر هو بالتأكيد شيء قد ترغب في التفكير في القيام به
00:19:25ومرة أخرى هناك حلول مختلفة هنا ولكن هذا شيء قد ترغب في التفكير فيه
00:19:32ولتكون أكثر أماناً بالطبع، يمكنك نقل بيئة التطوير الخاصة بك إلى الخارج
00:19:36وألا تكون موجودة على جهاز MacBook الخاص بك أو حاسوبك الشخصي ولكن بدلاً من ذلك تكون على خادم افتراضي أو Mac Mini
00:19:40تتصل به عبر ssh أو ما شابه أو ربما في حاوية docker بحيث
00:19:45إذا تم تنفيذ كود خبيث هناك، فإنه يؤثر فقط على حاوية docker تلك أو
00:19:50ذاك الخادم الافتراضي وليس نظامك بالكامل، فلا يمكنه جمع كل كلمات مرور نظامك وأشياء
00:19:56من هذا القبيل، بدلاً من ذلك يكون معزولاً ويكون لديك "نطاق انفجار" (blast radius) أصغر لأن تلك الهجمات
00:20:02سوف تستمر في الحدوث بطبيعة الحال، وأنا متأكد تماماً من أننا سنمتلك آليات
00:20:07أفضل وأفضل لتأمين نشر الحزم وما إلى ذلك، ولكن لن يكون هناك ضمان بنسبة 100%
00:20:13بأن مثل هذه الهجمات لا يمكن أن تحدث، وبالتالي فأنت كمستخدم لمثل هذه الحزم يجب عليك تأمين
00:20:21نظامك وامتلاك طبقات متعددة من الدفاع هناك بحيث تقلل من فرصة قيامك
00:20:27بتحميل نسخة حزمة مخترقة وإذا فعلت ذلك يكون نطاق الانفجار أصغر
00:20:33هذا ما يمكنك فعله وسأشارك المزيد حول ذلك في فيديوهات مستقبلية أيضاً على قناتي الأخرى
00:20:39قناة الأكاديمية ولكن نعم ابقوا آمنين هناك وتحققوا مما إذا كنتم قد تأثرتم بهذا
00:20:45الهجوم وكما ذكرت، لقد كانت بضع ساعات عصيبة
00:20:50قناة الأكاديمية، ولكن نعم، ابقوا آمنين وتأكدوا مما إذا كنتم قد تأثرتم بهذا
00:20:55الهجوم، وكما ذكرت، لقد كانت بضع ساعات عصيبة