فاحصات أمان المواقع المجانية أعطت ثلاث نتائج مختلفة — بأيها نثق؟

تحذير JavaScript الذي وجده الأداة الثانية هو على الأرجح آلية إعادة توجيه شرطية. الأكواد الخبيثة لا تظهر للمديرين المسجّلين دخولهم، بل تُفتح فقط للزوار الذين يحمل ترويسة referer الخاصة بهم Google. اسحب كود الصفحة من الطرفية باستخدام curl مع قيم User-Agent وReferer مختلفة. ابحث داخل الملف عن دوال مشبوهة مثل eval أو base64_decode أو document.write.

بدون أي هلع، تحققوا من نقطتين: أولاً، ادخلوا إلى لوحة Google Search Console لموقعكم وانظروا إلى تبويب مشكلات الأمان؛ إن كان Google قد التقط خطراً فسيُدرجه بوضوح هناك. ثانياً، حدّدوا تاريخ آخر نسخة احتياطية نظيفة لموقعكم. إذا كانت المشكلة قد بدأت قبل بضعة أيام فالمقارنة مع النسخة الاحتياطية هي أسرع طريق.

في العام الماضي تجاهلنا تحذيراً مشابهاً لأن متصفحين قالا إن الموقع نظيف. بعد 48 ساعة حُجب موقعنا من محرك البحث بشاشة حمراء. توقفت الإعلانات وخسرنا ذلك الأسبوع نحو 4,200 دولار من الإيرادات. تقرير النظافة من المتصفحات الخارجية يمنحك طمأنينة زائفة، فأعطوا الأولوية دائماً للتقرير الذي يقول إن الموقع مصاب.

قول المتصفح الثالث إن الخطر مرتفع بسبب ترويسات HTTP هو أسلوب تسويقي معتاد. كثير من الأدوات المجانية تضخّم غياب ترويسات الأمان وكأن فيروساً دخل الخادم، ثم تحاول بيع إضافتها المدفوعة. لا تخلطوا بين نقص الإعدادات وبين إصابة فعلية ببرمجية خبيثة.

تعديل: صححت بعض الأخطاء الإملائية.

بصراحة لا تتجاهلوا تحذير السكربت الخارجي أبداً ثم غالباً تكون عدّادات قديمة منسية في الموقع أو بكسلات دردشة طرف ثالث قد اختُرقت وتضخ إعادة توجيه. انظروا في الكود المصدري بين وسوم head، وإذا وُجد نطاق غريب فسيبدو واضحاً أصلاً.

هل موقعكم مبني على WordPress أم برنامج مخصص مكتوب من الصفر؟ وأيضاً، هل ملف JavaScript المشبوه موجود على خادم موقعكم نفسه أم يُسحب من خادم آخر خارجي؟ لو شاركتم هاتين المعلومتين سيكون التوجيه أسهل.

لتوضيح التقارير المتناقضة اتبعوا هذا الترتيب: 1) سجّلوا الرابط الكامل لملف السكربت الذي قال عنه المتصفح الثاني إنه مشبوه. 2) افتحوا الكود المصدري للملف على الخادم وافحصوا أكواد إعادة التوجيه الغريبة. 3) انظروا إلى تاريخ آخر تعديل عبر FTP أو لوحة الخادم. 4) اتركوا تحذيرات الشهادة والترويسات من الأداة الثالثة إلى وقت لاحق.

لا تحبطوا أبداً، ففي مواقع التجارة الإلكترونية النشطة تحدث أحياناً إنذارات كاذبة كهذه أو تسريبات سكربت صغيرة. إذا كنتم تخشون المساس بالكود، افتحوا تذكرة لدى فريق دعم شركة الاستضافة وأرسلوا لهم سجل الـ log الذي أعطاه المتصفح الثاني، وسيقومون بفحص مكافحة الفيروسات داخل الخادم مجاناً.

عانيت من نفس المشكلة قبل عامين. ابدأ بتجربة صغيرة، لا تربط كل شيء دفعة واحدة.

إذا كان هناك من يفعلها بطريقة أخرى، فأنا فضولي لمعرفة ذلك.

أعتقد أن الحديث بهذه القطعية في جانب فاحص أمان موقع مجاني صعب والناس يدافعون عن العادات وليس العمليات. المقاومة تأتي من هناك.

هل تعتقد أن هذا يعمل لجميع الأحجام؟ وقت اكتشاف المشكلة يحدد تكلفتها بشكل مباشر.

بالتوفيق.

نحن أيضاً واجهنا نفس المشكلة في فترة معينة. عندما تحاول تغيير كل شيء دفعة واحدة، لا يستقر أي شيء.

ابدأ بتجربة صغيرة، لا تربط كل شيء دفعة واحدة. هذه وجهة نظري، ولا أدعي أنها الحقيقة المطلقة.

ظهرت ثلاث وجهات نظر مختلفة، وكلها تكمل بعضها. يعني إذا لم يكن الإذن والنطاق مكتوبين، فلا تبدأوا الاختبار.

لو كنت مكانك، لسلك هذا المسار.

صحيح. الإجابة تختلف كثيراً حسب القطاع، لا توجد قاعدة عامة.

إذا كان هناك من يفعلها بطريقة أخرى، فأنا فضولي لمعرفة ذلك.

أوافقك الرأي تمامًا. بيئات الاختبار المنسية تصبح ثغرات أمنية أكثر تكرارًا من الأنظمة الحية.

إذا كان هناك من يفعلها بطريقة أخرى، فأنا فضولي لمعرفة ذلك.

أتفق، بل أود التأكيد على هذه النقطة. الناس يدافعون عن العادات وليس العمليات. المقاومة تأتي من هناك.

مثبت بالتجربة.

سؤالي قد يبدو مبتدئاً بعض الشيء، آسف على ذلك. وقت اكتشاف المشكلة يحدد تكلفتها بشكل مباشر.

عند اتخاذ القرار، اكتب أسوأ سيناريو أيضًا، وليس الأفضل فقط. دعني أتركها كملاحظة، قد تكون مفيدة.

أكتب هذا حتى لا تكرروا نفس الخطأ. لا تترددوا في السؤال، فالسائل يدفع ثمناً أقل دائماً.

هذا كل شيء، أرجو المعذرة إذا أطالت.