أول خطوة في عالم الـ XSS: اختراق مربع البحث (Reflected XSS - HTML Context) 🔓
أهلاً بكم في رحلة جديدة في مدونتنا! اليوم لن نتكلم نظرياً، اليوم سنشمر عن سواعدنا وندخل المعمل (Lab) لنطبق أول ثغرة XSS عملياً على منصة PortSwigger.
اللاب الذي سنقوم بحله اليوم هو:
Reflected XSS into HTML context with nothing encoded
قد يبدو الاسم طويلاً، لكنه ببساطة يعني: "الموقع يثق بك ثقة عمياء، ويأخذ كلامك يضعه في الصفحة كما هو بدون أي فلترة!". دعونا نرى كيف نستغل ذلك. 🕵️♂️
🔍 سيناريو اللاب (The Scenario)
عند دخولك إلى اللاب، ستجد موقعاً بسيطاً يحتوي على شريط بحث (Search Bar). وظيفة البحث طبيعية جداً: تكتب كلمة، وتظهر لك في الصفحة جملة مثل: "You searched for: YourWord".
أين المشكلة؟
المشكلة تكمن في أن المطور أخذ الكلمة التي كتبتها (Input) وقام بطباعتها مباشرة داخل كود الـ HTML للصفحة (Response) دون أن يتأكد منها أو يقوم بتشفيرها (Encoding).
🧠 لماذا تحدث الثغرة هنا؟
في هذا اللاب، السياق هو HTML Context. هذا يعني أن ما تكتبه يتم وضعه بين وسوم الـ HTML العادية.
تخيل أن كود الموقع من الداخل يبدو هكذا:
<h1>نتائج البحث عن: [كلامك يوضع هنا]</h1>بما أن العنوان يقول "Nothing Encoded"، فهذا يعني أنه لا يوجد أي حماية. إذا كتبت نصاً عادياً سيظهر كنص، ولكن إذا كتبت "وسم HTML" مثل <script>، المتصفح سيعتقده جزءاً من برمجة الموقع وسيقوم بتنفيذه! 😈
🛠️ طريقة الحل (The Exploit)
لكي نثبت للموقع وجود الثغرة، سنقوم بحقن كود JavaScript بسيط يظهر نافذة منبثقة (Pop-up).
- اذهب إلى مربع البحث.
- بدلاً من البحث عن كلمة عادية، انسخ والصق هذا الكود (Payload):
<script>alert(1)</script>
- اضغط على زر Search.
النتيجة: 💥 ستظهر لك نافذة منبثقة تقول "1". مبروك! لقد نجحت في تنفيذ كود خارجي على الموقع، وهذا يعني أنك اكتشفت ثغرة Reflected XSS.
💡 الدرس المستفاد
رغم سهولة هذا اللاب، إلا أنه يعلمنا القاعدة الذهبية رقم 1 في أمن المعلومات:
"Never Trust User Input" - لا تثق أبداً في مدخلات المستخدم.
أي نص يأتي من المستخدم يجب أن يتم تنظيفه (Sanitization) أو تشفيره (Encoding) قبل عرضه في المتصفح، وإلا فإن المهاجم سيتحكم في صفحتك.
هل قمت بحل اللاب؟ أخبرني في التعليقات كم استغرق منك وقتاً! 👇
%20%F0%9F%94%93.webp)