الهجوم الذي لا يراه أحد يأتي من نموذج الاتصال في موقعك
يبدو نموذج الاتصال بريئًا. لكنه أكثر باب مفتوح لديك، ولا يكاد أحد يوصده.
الجميع يحمي صفحة الدخول. لا أحد ينظر إلى نموذج الاتصال. ومع ذلك فهو يقبل مدخلات أي شخص، دون تحقق، دون احتكاك، وغالبًا دون حتى حدٍّ لعدد الرسائل.
هذا هو التفاوت الذي يبحث عنه المهاجم. صندوق نص يتحدث إلى خادم البريد لديك، إلى قاعدة بياناتك، أو إلى webhook داخلي. أنت ترى حقل "الرسالة". هو يرى سطر أوامر.
لماذا هذا الهدف مغرٍ إلى هذا الحد
يجمع نموذج الاتصال ثلاث خصائص نادر أن تجتمع في مكان واحد. يقبل مدخلات غير موثوقة. يشغّل منطقًا على الخادم. ولا يكاد يُدقَّق أبدًا. اختبر المطور أن الرسالة تصل إلى البريد. وتوقف عند هذا الحد.
المشكلة أن جملة "الرسالة تصل إلى البريد" تُخفي مسارًا كاملًا. نص المستخدم يُركَّب داخل ترويسة SMTP، يُدمج في استعلام، أو يُرسل إلى خدمة طرف ثالث. كل حدٍّ من هذه الحدود فرصة للحقن.
حقن ترويسات البريد
الحالة الكلاسيكية اسمها email header injection. إذا أخذت حقل "الموضوع" أو "المُرسِل" ولصقته مباشرة في ترويسة الرسالة، يكتب المهاجم فاصلة سطر ويضيف ترويساته الخاصة. نسخة مخفية Bcc إلى ألف عنوان، مثلًا.
وفجأة صار خادمك يرسل رسائل مزعجة. ليس باسمك مجازًا، بل حرفيًا عبر بنيتك التحتية، بعنوان IP الخاص بك ونطاقك. النتيجة متوقعة: مزوّدو البريد الكبار يصنّفون نطاقك مصدرًا للسبام، فيتوقف بريد عملك عن الوصول إلى أي مكان.
النص الذي يتحول إلى شيفرة
ثم تأتي السيناريوهات الأسوأ. إذا خزّنت الرسالة في قاعدة بيانات دون تحضير الاستعلام، فتحت الباب أمام SQL injection. وإذا عرضت الرسالة في لوحة إدارة دون تهريب HTML، يزرع المهاجم سكربتًا يعمل في متصفح فريقك حين يفتح العميل المحتمل. هذا XSS مخزَّن، وهو من أكثر المتجهات التي يُستهان بها.
انتبه للنمط. في أيٍّ من هذه الحالات لم "يخترق" المهاجم شيئًا. استعمل النموذج تمامًا كما صُمّم ليُستعمل. الثغرة ليست خللًا نادرًا. إنها غياب قاعدة بسيطة: لا تثق أبدًا بما يدخل.
ما الذي تفعله، حسب أولوية الأهمية
لا تحتاج إلى WAF ولا إلى مستشار أمني لإغلاق 90% من هذا. تحتاج إلى انضباط في أربع نقاط.
- تحقّق على الخادم، لا في المتصفح فقط. تحقق الواجهة راحة للمستخدم، وليس أمنًا. المهاجم لا يستعمل نموذجك، بل يرسل POST مباشرة إلى نقطة النهاية.
- هرّب المخرجات، دائمًا. عند الحفظ في قاعدة البيانات استعمل استعلامات مُحضَّرة. وعند العرض في لوحة الإدارة هرّب HTML. عامل كل رسالة على أنها عدائية حتى يثبت العكس.
- ارفض فواصل الأسطر في حقول الترويسة. الموضوع والاسم والبريد لا سبب لأن يحتوي أيٌّ منها على \r أو \n. رشّحها قبل أن تمسّ SMTP.
- حدّد معدل الإرسال وأضف تحديًا خفيًا. تحديد المعدل حسب IP مع honeypot أو hCaptcha يوقف الروبوتات الآلية دون إفساد تجربة من هو إنسان فعلًا.
والجانب الذي ينساه الجميع تقريبًا
نموذج الاتصال يجمع بيانات شخصية. اسمًا، بريدًا، وغالبًا رقم هاتف ومحتوى الرسالة. هذا يضعك داخل نطاق اللائحة العامة لحماية البيانات RGPD، شئت أم أبيت. تحتاج إلى أساس قانوني لمعالجة تلك البيانات، والموافقة يجب أن تكون مستنيرة.
عمليًا يعني هذا ثلاثة أمور محددة. إشعار خصوصية واضح مرتبط بالنموذج. أساس قانوني معرَّف، عادةً المصلحة المشروعة في المادة السادسة أو الموافقة الصريحة. وسياسة احتفاظ، لأن تخزين العملاء المحتملين إلى الأبد ليس استراتيجية، بل مسؤولية متراكمة. إذا سُرقت قاعدة بيانات عملائك، تحوّلت المشكلة من تقنية إلى تنظيمية.
أمن النماذج ليس جدارًا ناريًا باهظًا. إنه رفضك أن تثق بنصٍّ كتبه غريب.— يوميات كريفار
العِبرة مملّة، ولذلك تنجح. الهجوم الذي لا يراه أحد يأتي من الباب الذي لا ينظر إليه أحد. عامل نموذج الاتصال بالاحترام نفسه الذي توليه لصفحة الدخول، ولن يحدث معظم هذه المشكلات أصلًا.