برمجة عابرة للمواقع

(بالتحويل من برمجة عبر مواقع)

البرمجة العابرة للمواقع أو هجوم حقن النصوص البرمحية عبر موقع وسيط (بالإنجليزية: (Cross-site scripting (XSS)‏) هي أحد أنواع الهجوم التي يتعرض لها الأنظمة الحاسوبية، ونجدها خصوصاً في تطبيقات الإنترنت عبر ما يسمى برمجة بالحقن، التي يلجأ فيها بعض مستخدمي الإنترنت المخربين لإدخال بعض الجمل البرمجية للصفحات التي يستعرضها الآخرون.[1][2][3] وعادة ما نجد هذا النوع من الهجوم في المواقع التي تستخدم لغة HTML. أما المخربين الذي يستغلون نقطة الضعف في مواقع الإنترنت، فعادة ما يحاولون العبث ببعض المبادئ الرئيسية في النظام مثل تنظيم الدخول (Access Control)، أو لمحاولة الاستيلاء على معلومات حساسة ومهمة. تحمل هذه البرامج عند زيارة المستخدم لمواقع غير آمنة، أو قيامه بفتح مرقفات مجهولة المصدر مع رسائله الإلكترونية، حيث تتتبع ضغط المستخدم للوحة المفاتيح، للحصول على كلمات المرور، والاحتفاظ بها؛ مما يتيح للمخترقين معرفتها.

مُخطط تسلسل العمليات لهجوم حقن الشيفرة المصدريّة عبر موقع وسيط.

مقدمة عدل

بدأت قصة هذا الهجوم منذ بدأت شركتي نتسكيب وجافا، بالسماح للمستخدمين لإرسال الجمل البرمجية من خلال متصفح الإنترنت، والمشكلة الرئيسية هنا هي قدرة المستخدم على فتح نافذتين في وقت واحد، مما يسمح للمخرب بالحصول على المعلومات الحساسة بالتنقل من خلال النافذتين. وفي محاولة لحل هذه المشكلة بدأت المتصفحات باستخدام سياسة المصدر الأوحد (Same Origin Policy). وبشكل أساسي، تسمح هذه السياسة بتبادل المعلومات بين نافذتين، ولكنها لا تسمح للمخربين بالوصول إلى المعلومات الحساسة من خلال نوافذ الجافا(Java). ومن وقتها، بدأت المتصفحات بمحاولة صد هذا الهجوم، بتبنيهم لسياسات أخرى في مختلف لغات البرمجة. ولكن بشكل عام يبقى هذا الهجوم من المحاولات الناجحة للمخربين لتمرير آلياتهم لسرقة المعلومات. ومن الممكن إذا استطاع المخرب أن يوصل الجمل البرمجية اللازمة، أن يصل إلى الكثير من المعلومات الحساسة الذي يحتوي على جهاز الخادم لموقع الإنترنت. تعتمد هذه الثغرات على تصميم موقع الويب بشكل رئيسي، حيث ان تصميم المواقع يجب أن يتبع المعايير الأمنية والمقاييس العالمية المتعارف عليها، وحيث أن بعض من يقوم بعملية تصميم المواقع لا يراعي هذه الجوانب، تجد أن المواقع التي تخترق تم التعامل معها بطريقة سيئة أثناء عملية التصميم.

المصطلح عدل

كان يرمز لهذا النوع من الهجوم بـ"CSS"، ولكن هذا الرمز كان معتمداًَ لأكثر من مصطلح في برمجة المواقع الإلكترونية مثل «صفحات الأسلوب المتعاقبة» (Cascading Style Sheets) و (Content-scrambling System)، فاستعيض عنه بـ"XSS". وكان أول من استخدم هذا الاختصار هو ستيف شامبيون في مقالة له عام 2002.

أنواع الهجمات عدل

محلي (DOM-based) عدل

وفي هذا النوع تكمن في برمجة صفحات الخادوم-المستخدم، فعلى سبيل المثال إذا كان جزء من النظام يحصل على معلومات من جزء آخر، وينشر ما حصل على صفحات المواقع، من دون تشفير من قبل صفحات HTML. هنا ستظهر المشكلة والمساحة للمخرب ليضيف ما لديه. وبشكل تطبيقي، فإن نسخ متصفحات الإنترنت تتعامل مع هذه المشكلة بطريقة مختلفة، فإن صفحات خادوم-المستخدم يحفظها متصفح مايكروسوفت في «المنطقة المحلية» (Local Zone)) وتحديداً في القرص الصلب للمستخدم، وهنا تظهر المشكلة. فيستطيع المخرب هنا، أن يصل من خلال هذا الأمر إلى نظام المستخدم، وبإضافته لبعض الجمل البرمجية فإنه يحصل على الامتيازات الممنوحة لمستخدم الجهاز ذاته. وتم حل هذه المشكلة في الإصدار الأخير من متصفح مايكروسوفت IE7.

المنعكس (غير الثابت) عدل

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

المخزن (الثابت) عدل

هو النوع الأكثر قوة، ويسمى عادة بالحقن بلغة HTML (HTML Injection)، وهنا يقع الهجوم عندما تصل البيانات من المستخدم وتخزن بشكل دائم في جهاز الخادم (قاعدة بيانات، ملفات)، ثم تظهر على الشاشة. والمثال التقليدي هنا هو وسائل الرسائل السريعة، حيث يستطيع المستخدم نشر رسائل بلغة HTML للمستخدمين الآخرين ليقرؤوها. وهذا النوع أهم من الأنواع السابقة، لأن المخرب يبث جمله البرمجية مرة واحدة وتؤثر على أكثر من مستخدم، بدون استخدام الكثير من الموارد وممكن أن يصيب تطبيق الإنترنت هذا بفيروس دائم. وخطورة هذا النوع تكمن في أن المخرب ليس محتاج بالضرورة لاستخدام التطبيق للوصول إليه، فأي شيء قد وصل من النأم (رسائل، ملاحظات..) وهنا يستطيع المخرب التحكم بها، إلا إذا كان البرنامج مشفراً قبل أن يتم إرساله إلى المستخدم.

الذاتية عدل

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

تجنب الهجوم ومحاربته عدل

النوع المعتمد عليه هذه الأيام لتجنب هذا الهجوم، يتطلب تشفير جميع الرموز الخاصة في البيانات المشكوك بها في لغة HTML، وهذا يتم عادة قبل عرض النتائج في متصفح الإنترنت، وهناك الكثير من لغات البرمجة التي تحتوي في مكتباتها على وظائف جاهزة توفر هذا التشفير. ولكن المشكلة الكبرى في تجنب هذا الهجوم، أن كل حالة مختلفة عن الأخرى، في المتطلبات والتطبيق. وعلى سبيل المثال، إذا كان إدخال المستخدم سيصل إلى الهدف في ارتباط تشعبي ما (Hyper Link)، ويجب عليه إدخال الرابط لإظهار صورة (url)

<img src='$url'>

فإن المخرب يستطيع إدخال

doesntexist.jpg' onerror='alert(document.cookie)

وهنا يضيف المخرب وظيفة ليقوم بها الخادم عندما لا يجد الصورة المسماة في المثال، ويقوم بتنفيذ تلك الوظيفة. ولعل أبرز ما يمكن به تجنب الهجوم هو تصميم المواقع استنادا على المعايير الأمنية المتبعة، وحيث أن العديد ممن يقوم بعملية التصميم لا يراعي ذلك نجد أن غالبية المواقع تتعرض لهجمات عنيفة من هذا النوع تؤدي إلى افساد عدد كبير من البيانات، لذا فعملية تصميم مواقع الويب يجب أن ترتكز على أسس ومقاييس عالمية في مجال تصميم المواقع.

وسائل التخفيف من الهجوم عدل

كما ذكرنا أن الوسيلة الأسهل والأفضل هي تشفير جمل لغة HTML، ولكن هذه الوسيلة تمنع مستخدمي الإنترنت وخصوصاً مستخدمي المنتديات والبريد الإلكتروني (webmail) من الحصول على كل ما يريدون. ولذلك فإن بعض تطبيقات الإنترنت (مثل ماي سبيس، ويكيميديا ومعظم برامج المنتديات) تلجأ لتحييد جمل البرمجة، إما بإلغائها أو تعديلها. ولكن بسبب التعديلات السريعة على لغة HTML والإضافات المستمرة لها، فإنه يغدو مستحيلاً معرفة ما هي الجمل البرمجية التي يجب مسحها. وإضافة إلى طريقة «ترشيح المحتوى»، فإن طرقاً أخرى معتمدة وأشهرها هي استخدام طريقة «الكعكات» (Cookies)، فالكثير من تطبيقات الإنترنت تستخدم «كعكة لكل جلسة» للتحقق من صحة المعلومات المتبادلة، وبما أن جهاز الخادم– المستخدم عادة ما تصل إلى هذه الكعكات، فإن الخوف من هذه الهجوم يكمن في سرقة المعلومات التي تحتويها الكعكات. ولذلك تلجأ هذه التطبيقات لربط عنوان الجهاز (IP) بهذه الكعكة، ولذلك يغدو الجهاز ذاته هو الوحيد القادر على فتح هذه الكعكة. وتبدو هذه الطريقة ناجحة، ولكن فشلها يظهر عندما يعمل المخرب من خلال وكيل ما (Web Proxy).

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

الطريقة الأخيرة هي أن تعمل تطبيقات الإنترنت من دون الحاجة لاستخدام صفحات الخادم–المستخدم، وهذا يمكن المستخدمين من تعطيل جميع المداخل التي تمكن المخربين من الوصول إلى البيانات من خلال البرمجة عبر المواقع. وهكذا أغلب المحاولات للوصول إلى هذه الأجهزة ستنتهي حتى قبل دخولها للمتصفح. ولكن هذه الطريقة تبقى عاجزةً أمام البرمجة من خارج الصفحات مثل <frame> أو <object>، وهذا كافٍ لخداع المستخدمين. وتكمن المشكلة هنا عن جهل المستخدمين، فالمستخدم العادي لا يعرف أي الأنواع يعطل، وإذا لجأ إلى تعطيل جميع الأنواع، فهذه سيمنع بعض المواقع من العمل بشكل فعال، فيحتار المستخدم، ويختار إما التخلي عن بعض مواقعه المفضلة، أو أن يترك جهازاً معرضاً لهذا النوع من الهجوم.

مراجع عدل

  1. ^ Amit، Yair (21 ديسمبر 2005). "Google.com UTF-7 XSS Vulnerabilities". Watchfire. مؤرشف من الأصل في 2018-07-22. اطلع عليه بتاريخ 2008-05-29.
  2. ^ Schneider، Christian. "CSRF and same-origin XSS". www.webappsecblog.com. مؤرشف من الأصل في 2013-11-25.
  3. ^ Leyden، John (23 مايو 2008). "Facebook poked by XSS flaw". The Register. مؤرشف من الأصل في 2017-11-13. اطلع عليه بتاريخ 2008-05-28.

وصلات خارجية عدل