التحقق من صحة المدخلات وترميز المخرجات

لماذا يهم

يشترك الحقن (Injection) والبرمجة النصية عبر المواقع (XSS)، اللذان يختبرهما الدرسان التاليان بالتفصيل، في سبب جذري واحد: قيمة من الخارج تصل إلى مفسّر مثل قاعدة بيانات أو صدفة أوامر (shell) أو متصفح فتُنفَّذ شيفرةً. والحقن إحدى فئات ⁦OWASP Top 10:2025⁩ ويشمل XSS، والضابطان اللذان يمنعانه هما هذان تحديداً: تحقق مما يدخل، ورمّز ما يخرج. وتكفي نقطة دخول واحدة بلا فحص أو مخرج واحد بلا ترميز.

وهذه أرض خصبة للمختبِر، لأن العيوب تختبئ في الفجوات بين الطبقات: نموذج يتحقق وواجهة برمجية لا تتحقق، وصفحة قائمة ترمّز وتصدير لا يرمّز. ولا تصل الاختبارات الوظيفية بقيمها المرتبة إلى تلك الفجوات. أما بضع علامات مميّزة غير ضارة (markers) تحملها من كل نقطة دخول إلى كل مكان تظهر فيه القيمة فتكشفها في دقائق، بلا أدوات هجوم، على أنظمة مصرّح لك باختبارها.

التحقق من صحة المدخلات: قواعد قائمة السماح مفروضة على الخادم

تطلب ورقة OWASP المرجعية للتحقق من المدخلات (Input Validation Cheat Sheet) فحصين لكل قيمة: بنيتها (syntax)، أي النوع والصيغة المتوقعان: النوع والطول والنطاق والصيغة والانتماء إلى مجموعة ثابتة، ودلالتها (semantics)، أي هل القيمة منطقية للعملية المطلوبة: تاريخ الزيارة ليس في الماضي، والكمية لا تتجاوز المخزون. ويسمّيهما المختبِرون عادةً التحقق النحوي والتحقق الدلالي. وتُكتب القواعد قوائمَ سماح (allow-lists): حدّد المقبول وارفض كل ما عداه. فقائمة الحظر (block-list أو deny-list) للنصوص الممنوعة ناقصة دائماً، لأن القيمة الخطيرة تُكتب بطرق أكثر مما تستوعبه أي قائمة، وهي ترفض بيانات سليمة: فحظر الفاصلة العليا يرفض O'Brien من دون أن يجعل أي استعلام آمناً. وتعدّ الورقة قوائم الحظر و«تنظيف» المدخلات من مزالقها الشائعة. وللنص الحر قائمة سماح أيضاً لكنها أوسع: ترميز محارف (character encoding) واحد متفق عليه بين المكوّنات، ورفض المدخلات المشوّهة، والإبقاء على علامات الترقيم وأنظمة الكتابة المشروعة، وحد أقصى للطول، وحيث تُقارَن القيم، تطبيع Unicode واحد (normalisation) يُطبَّق قبل التحقق والتخزين (كي تكون é المكتوبة محرفاً واحداً أو e مع علامة تشكيل القيمةَ نفسها).

أما فحوص المتصفح مثل required وmaxlength والنمط فهي تغذية راجعة لا ضابط: كما في درس اختبار نماذج الويب، يستطيع أي أحد تعديل الصفحة أو إرسال الطلب من دونها. والورقة صريحة: تحقّق على الخادم حتى حين يفحص المتصفح الحقول نفسها، وتحقّق أيضاً من البيانات الآتية من الواجهات البرمجية الداخلية وتغذيات الشركاء وطوابير الرسائل. والنموذج ليس إلا نقطة دخول واحدة: فواجهة JSON التي يستدعيها تطبيق الجوال، والاستيراد الجماعي، وسلسلة الاستعلام، وترويسة مثل Accept-Language، وملف تعريف الارتباط، وخطاف الويب (webhook) كلها تُدخل قيماً من الخارج. ويثبت المختبِر أن كل مسار يفرض كل قاعدة.

• اكتب كل قاعدة بصيغة قابلة للاختبار: ^ORD-[0-9]{5}$ لرقم الطلب، أي ORD- ثم خمسة أرقام بالضبط (فالمرساتان ^ و$ تفرضان مطابقة القيمة كلها كما تطلب الورقة، ومن دونهما يقبل النمط أيضاً xx ORD-12345 <b>)؛ وعدد صحيح من 1 إلى 20 للكمية؛ وقيمة واحدة من القائمة المخزَّنة للدولة؛ ولاسم الشركة من 2 إلى 80 حرفاً من حروف Unicode والأرقام والمسافات و' - & .، فتبقى الفاصلة العليا وعلامة العطف مشروعتين.
• انسخ طلب النموذج من لوحة Network بصيغة cURL، وغيّر حقلاً واحداً إلى قيمة ترفضها الصفحة، وأرسله بحساب اختبار، وتوقّع استجابة 4xx تسمّي الحقل والقاعدة، ولا شيء مخزَّناً، ولا تتبّع مكدّس (stack trace) ولا SQL في الرسالة.
• أرسل المجموعة نفسها عبر الواجهة البرمجية والاستيراد: 81 حرفاً، وكمية 0 و21، ودولة ZZ، والطلب أدناه الذي يجتاز فيه company وnotes قاعدتيهما بينما يفشل quantity وcountry. وأي مسار يقبل ما يرفضه النموذج مشكلة تستحق الإبلاغ (finding).
• انتبه للإصلاح الصامت: الخادم الذي يقصّ 81 حرفاً إلى 80 أو يحذف < من دون رسالة يغيّر بيانات المستخدم. أبلغ عنه ما لم يسمح المتطلب به.

POST /api/customers HTTP/1.1
Host: crm.test.example
Content-Type: application/json

{"company": "O'Brien & Sons", "quantity": 21, "country": "ZZ",
 "notes": "Discount < 10% until <b>Ramadan</b>"}

HTTP/1.1 422 Unprocessable Content
Content-Type: application/json

{"errors": [{"field": "quantity", "rule": "integer 1-20"},
            {"field": "country", "rule": "not a known country code"}]}

جرّبها: أداة اختبار Regex جرّبها: مولّد الاختبارات السلبية جرّبها: مولّد مجموعات الأحرف الخاصة

ترميز المخرجات: قيمة واحدة وترميز واحد لكل سياق

يجري الترميز لحظة الإخراج، في الشيفرة التي تكتب القيمة في صفحة أو رابط أو سكربت أو استعلام، ويعتمد على المكان الذي تستقر فيه القيمة. وتعطي ورقة OWASP المرجعية للوقاية من XSS (Cross Site Scripting Prevention Cheat Sheet) كل سياق في HTML قواعده الخاصة: محتوى العناصر، وقيم السمات، وJavaScript، وCSS، والعناوين. ولقاعدة البيانات مقابلها: الاستعلام ذو المعاملات (parameterised query) يرسل القيمة منفصلة عن عبارة SQL، فلا تحلّلها قاعدة البيانات أبداً بوصفها SQL؛ وتعدّ ورقة الوقاية من الحقن (Injection Prevention Cheat Sheet) تهريب المدخلات (escaping) ملاذاً أخيراً. والقيمة المخزَّنة لا تتغير أبداً، أما القيمة المرمَّزة لسياق خاطئ فتبقى غير آمنة، لأن كيانات HTML داخل عنوان أو سلسلة سكربت لا تعني شيئاً هناك.

• محتوى عنصر HTML: تصبح & هي &، و< هي <، و> هي >، و" هي "، و' هي ' (و' و' تمثّلان المحرف نفسه)، فتعرض الصفحة المحارف كما كُتبت.
• سمة HTML: الكيانات نفسها داخل سمة محاطة بعلامتي اقتباس مثل title أو value؛ فالسمة غير المقتبسة يمكن الخروج منها بمسافة وبمحارف أخرى كثيرة. أما سمة الحدث مثل onclick فسياق سكربت: يفكّ المتصفح الكيانات قبل تشغيل السكربت، فلا تحمي شيئاً هناك.
• معامل العنوان (URL): ترميز النسبة المئوية (percent-encoding)، فتصبح المسافة %20 و& هي %26، وفي الترميز الصارم وفق RFC 3986 تصبح ' هي %27 (وكثير من أدوات الترميز تترك الفاصلة العليا كما هي)؛ ومن دون ترميز تبدأ & في الاسم معاملاً ثانياً. ثم يُرمَّز العنوان المكتوب في href ترميزَ سمة أيضاً.
• JavaScript وJSON: تهريب السلاسل بمرمِّز من مكتبة تخضع للصيانة لا بتهريب علامات الاقتباس يدوياً، فتصبح " هي \" و\ هي \\، و< هي \u003c حين تكون البيانات داخل صفحة HTML، كي لا تستطيع القيمة إغلاق السكربت. والأسلم: أبقِ القيمة خارج السكربت، في سمة data- مثلاً تُقرأ عبر dataset، واكتبها في الصفحة بـtextContent لا بـinnerHTML أبداً.
• SQL: استعلام ذو معاملات أو عبارة مُعدّة مسبقاً (prepared statement) يُبقي O'Brien بياناتٍ من دون المساس بالنص.

القيمة المخزَّنة    O'Brien & Sons

HTML content        O'Brien & Sons
HTML attribute      title="O'Brien & Sons"
URL parameter       ?q=O%27Brien%20%26%20Sons
JSON / JavaScript   {"company": "O'Brien & Sons"}      (لا شيء يحتاج إلى تهريب هنا)
SQL                 WHERE company = ?                  (القيمة مربوطة معاملاً)

محرف واحد في ثلاثة سياقات:   <   ->   &lt; (HTML)   %3C (URL)   \u003c (script)

جرّبها: مرمّز كيانات HTML جرّبها: مرمّز URL جرّبها: تهريب / إلغاء تهريب JSON

لماذا كلاهما: التحقق عند الباب والترميز عند كل مخرج

لا يغني أي من الضابطين عن الآخر. فالتحقق لا يستطيع رفض O'Brien أو Al-Harbi & Sons أو ملاحظة تقول price < 50، لأنها بيانات صحيحة؛ والترميز وحده يبقيها غير ضارة في طريقها إلى الخارج. والترميز لا يستطيع رفض كمية -1 أو ملاحظة بحجم عشرة ميغابايت أو دولة غير موجودة، لأنها تُعرض على أكمل وجه؛ والتحقق وحده يُبقي البيانات السيئة خارجاً. وتقول ورقة التحقق من المدخلات الشيء نفسه: التحقق لا يغني عن الاستعلامات ذات المعاملات في SQL، ولا عن ترميز المخرجات حسب السياق في مواجهة XSS.

لذلك الترتيب ثابت: مدخل، ثم تحقق (قبول أو رفض، ولا إصلاح صامت أبداً)، ثم تخزين القيمة المقبولة من دون تغيير، ثم ترميز حسب السياق عند كل مخرج. وتخزين قيمة مرمَّزة سلفاً يكسر السلسلة، لأن كل مخرج آخر يتلقى عندئذ بيانات خاطئة: يعرض البريد الإلكتروني & نصاً، ويحمل تصدير CSV كيانات، وتعرض الصفحة التي ترمّز بصورة صحيحة & على الشاشة لأن مصدرها صار يحوي &، وهو عيب الترميز المزدوج. أما التنقية (sanitisation) فعملية ثالثة منفصلة للحقول القليلة التي يجب أن تقبل وسوم HTML (markup)، مثل محرر النص المنسّق: تُبقي مكتبة التنقية قائمة سماح من الوسوم والسمات فقط، وتبقى النتيجة مرمَّزة أينما خرجت نصاً عادياً.

مثال تطبيقي: عميل واحد عبر مخرجاته

نظام إدارة علاقات العملاء (CRM) في بيئة الاختبار لديك، مع إذن مكتوب باختباره، فيه نموذج العملاء المذكور أعلاه. يحفظ المختبِر عميلاً اسم شركته O'Brien & Sons وملاحظته Discount < 10% until <b>Ramadan</b>، مرة عبر النموذج ومرة عبر الواجهة البرمجية بكمية ودولة صالحتين، ثم يزور كل مكان تظهر فيه القيمتان: قائمة العملاء، وتلميح الاسم (سمة title)، ورابط «البحث عن مشابه»، وتصدير CSV، وبريد الترحيب.

• قائمة العملاء: القيمتان معروضتان كما كُتبتا؛ والمصدر يحوي ' و& و<. ناجح.
• التلميح: يعرض O فقط. وفي المصدر title='O'Brien & Sons': أنهت الفاصلة العليا السمة المحاطة بعلامة اقتباس مفردة، وحطّ باقي القيمة خارجها. النتيجة: لا ترميز للسمات. توقّف وأبلغ؛ ومن هنا يكمل درس XSS.
• رابط البحث عن مشابه: /customers?q=O'Brien & Sons من دون ترميز نسبة مئوية؛ فيجري البحث عن O'Brien ويتلقى الخادم معاملاً ثانياً اسمه Sons. النتيجة: لا ترميز للعناوين، وعيب وظيفي لكل اسم فيه علامة عطف.
• تصدير CSV: تصل الملاحظة بصيغة Discount < 10% until <b>Ramadan</b>. النتيجة: أعاد التصدير استخدام نص مرمَّز لـHTML، فيحصل من ينزّله على بيانات خاطئة؛ ترميز لسياق خاطئ.
• بريد الترحيب: Ramadan بخط عريض. النتيجة: يدرج القالب الملاحظة وسومَ HTML تُفسَّر، فيُعرض نص كتبه مستخدم في صندوق بريد مستخدم آخر؛ أبلغ عنه بوصفه حقن HTML برؤية مقيَّدة، واترك تقدير الخطورة لمسؤول الأمان.
• نقاط الدخول: عبر الواجهة البرمجية تعيد quantity: 21 وcountry: ZZ استجابة 422 تسمّي الحقلين، ولا شيء مخزَّن. ناجح. وعبر الاستيراد يُقبل اسم شركة من 81 حرفاً ويُقصّ إلى 80 من دون رسالة. النتيجة: الاستيراد يتحقق أقل مما يتحقق النموذج.

أسئلة شائعة

المراجع

• OWASP Cheat Sheet Series: Input ValidationOWASP Foundationالتحقق بقوائم السماح، والفرق بين الفحص النحوي والدلالي، ولماذا لا يُعدّ التحقق في المتصفح ضابطاً أمنياً أبداً.
• OWASP Cheat Sheet Series: Cross Site Scripting PreventionOWASP Foundationمنع XSS: الترميز عند الإخراج بحسب كل سياق، وتعقيم HTML الذي يكتبه المستخدم، ومواضع الإدراج الآمنة في DOM وحمايات الأطر، مع اعتبار CSP طبقة دفاع إضافية فقط.
• OWASP Cheat Sheet Series: Injection PreventionOWASP Foundationمنع حقن SQL وأوامر النظام وغيرها عبر التعامل بالمعاملات والتحقق والتهريب.
• OWASP Top 10:2025OWASP Foundation · 2025أخطر عشرة مخاطر أمنية لتطبيقات الويب، مع كيفية اختبار كل منها والوقاية منه.