الوحدة 12 · اختبار تطبيقات الويب

أساسيات أمان الويب

بقلم فريق ضمان الجودة في متقن سوفت · · 20 دقيقة · مبتدئ

أساسيات أمان الويب هي الفحوص الأمنية التي يستطيع المختبِر الوظيفي (functional tester) إجراءها بأمان أثناء اختبار تطبيق ويب: HTTPS في كل مكان، والسمات الصحيحة لملفات تعريف الارتباط (cookies)، ومعاملة المدخلات بوصفها بيانات لا شيفرة، والحماية من البرمجة النصية عبر المواقع (Cross-Site Scripting, XSS) ومن تزوير الطلبات عبر المواقع (Cross-Site Request Forgery, CSRF)، وترويسات الأمان (security headers) التي تطلب من المتصفح حماية المستخدم. ولا يحتاج شيء من ذلك إلى أدوات هجوم: يكفي المتصفح وأدوات المطوّرين وبضعة مدخلات غير ضارة.

مثال ذلك أن يُدخل المختبِر اسم العرض Sara <b>QA</b>. فإذا أظهرت كل صفحة هذه الأحرف كما هي، فقد عولج الإدخال بوصفه نصاً. أما إذا ظهرت كلمة QA بخط عريض في مكان ما، فقد أدرج التطبيق مدخلات المستخدم في الصفحة بوصفها شيفرة HTML (markup)، وهو الخلل نفسه الذي يستغله المهاجم لتشغيل سكربت في متصفح مستخدم آخر. عيب خطير اكتُشف دون أي شيفرة هجوم.

لماذا يهم

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

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

ما الذي يستطيع المختبِر الوظيفي فحصه بأمان

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

  • لا تختبر إلا الأنظمة التي تملكها أو لديك إذن مكتوب باختبارها، ويُفضَّل أن تكون بيئة اختبار؛ ولا تختبر مواقع أطراف ثالثة أبداً، ولا بيئة الإنتاج إلا إذا نصّ الإذن عليها.
  • استخدم حسابات الاختبار الخاصة بك. ولا تقرأ بيانات الآخرين ولا تغيّرها ولا تحذفها أبداً، حتى لو اكتشفت أنك تستطيع ذلك.
  • استخدم علامات غير ضارة مثل <b>qa</b> وعلامات الاقتباس والفاصلة العليا؛ ولا حمولات سكربت ولا أدوات فحص آلي (scanners) ولا أدوات هجوم دون موافقة فريق الأمان.
  • توقّف عند أول مؤشر على ثغرة، واحفظ الأدلة، وأبلغ عنها عبر القناة المقيّدة التي يخصّصها فريقك للعيوب الأمنية، مع إخفاء الرموز (tokens) والبيانات الشخصية.

HTTPS وسمات ملفات تعريف الارتباط

يشفّر HTTPS حركة البيانات بين المتصفح والخادم ويثبت هوية الخادم بشهادة رقمية، ويشرح الدرس التالي عن HTTP وHTTPS كيف يحدث ذلك. ومن دونه يستطيع أي طرف على مسار الشبكة قراءة الصفحات وبيانات النماذج وملفات تعريف الارتباط وتغييرها.

وسمات ملفات تعريف الارتباط التي تعلّمتها في درس ملفات تعريف الارتباط والتخزين في المتصفح ضوابط أمنية أيضاً. ففي ملف تعريف ارتباط الجلسة تُبعد Secure الملف عن الاتصالات غير المشفرة، وتُخفيه HttpOnly عن السكربتات، بما فيها السكربت المحقون، وتمنع القيمة الصريحة SameSite=Lax أو Strict المتصفح من إرساله مع معظم الطلبات التي تبدأ من مواقع أخرى. افحصها في لوحة Application أو بأداة Cookie Analyzer.

  • كل عنوان يبدأ بـhttp:// يُعاد توجيهه إلى https:// (برمز ⁦301⁩ أو ⁦308⁩) قبل تقديم أي محتوى أو ضبط أي ملف تعريف ارتباط.
  • لا محتوى مختلطاً (mixed content): يجب ألا تحمّل صفحة HTTPS سكربتات أو أنماطاً أو صوراً عبر http://. والمتصفحات تحجب هذه الطلبات أو ترقّيها إلى HTTPS، وتظهر رسالة تحذير في وحدة التحكم (Console).
  • الترويسة Strict-Transport-Security (HSTS، المعيار RFC 6797)، مثل max-age=31536000، تجعل المتصفح لا يستخدم مع ذلك المضيف إلا HTTPS حتى تنتهي مدتها. ومن دونها يخرج عنوان http:// المكتوب يدوياً بلا تشفير، ويمكن اعتراضه قبل إعادة التوجيه.
  • لا تظهر كلمات المرور والرموز والبيانات الشخصية في عناوين URL أبداً: فالعناوين تُحفظ في سجل المتصفح وسجلات الخادم، وقد تتسرب إلى مواقع أخرى عبر الترويسة Referer.

جرّبها: محلّل ملفات تعريف الارتباط (Cookies)

معالجة المدخلات وXSS وCSRF

كل قيمة تأتي من الخارج غير موثوقة: حقول النماذج ومعاملات URL والترويسات وملفات تعريف الارتباط والملفات. والتطبيقات الآمنة تدافع على الخادم مرتين. عند الدخول تتحقق من صحة المدخلات (Input Validation) وفق قائمة سماح (allow-list) بالنوع والطول والصيغة المتوقعة؛ أما فحوص المتصفح فتسهيل للمستخدم فقط. وعند الخروج ترمّز المخرجات (Output Encoding) بحسب سياقها: في HTML يصبح < هو &lt; فيُعرض ولا يُفسَّر، وتُمرَّر القيم إلى قاعدة البيانات معاملاتٍ (parameters)، لا نصاً ملصقاً في الاستعلام أبداً. ولا يكفي التحقق وحده: فـO'Brien مدخل صالح، والأمان يأتي من طريقة كتابة المخرجات.

البرمجة النصية عبر المواقع (XSS) نتيجة غياب ترميز المخرجات أو خطئه: تصبح المدخلات شيفرة HTML، فيعمل سكربت كتبه المهاجم في متصفح الضحية وبجلسته. وتكون مخزَّنة (stored) حين تُحفظ القيمة وتُعرض للآخرين لاحقاً، ومنعكسة (reflected) حين تعيد الاستجابة القيمة من الطلب مباشرةً، ومعتمدة على DOM (DOM-based) حين تكتب شيفرة JavaScript الخاصة بالصفحة القيمة فيها، مثلاً عبر innerHTML.

أما تزوير الطلبات عبر المواقع (CSRF) فيستغل أن المتصفحات ترفق ملفات تعريف الارتباط تلقائياً. فبينما أنت مسجّل الدخول في متجر، ترسل صفحة على موقع آخر نموذجاً مخفياً إلى عنوان تغيير البريد الإلكتروني في المتجر، والمتجر الذي لا يفحص إلا ملف تعريف الارتباط يستجيب. والدفاع الرئيسي رمز مضاد لـCSRF (anti-CSRF token) في كل نموذج يغيّر البيانات يفحصه الخادم، أما ملفات تعريف الارتباط بسمة SameSite فطبقة ثانية لا تغني عنه. والقيمة Lax ما زالت ترسل ملفات تعريف الارتباط حين يتبع المستخدم رابطاً من موقع آخر، وهذا أحد أسباب ألا تتغيّر البيانات أبداً عبر طلب GET.

  • أدخل ' " < > & و<b>qa</b> في الحقول النصية، ثم ابحث عن القيمة في كل مكان تظهر فيه لاحقاً: القوائم وشاشات الإدارة ورسائل البريد الإلكتروني والملفات المصدَّرة. النتيجة المتوقعة: الأحرف كما كُتبت، ولا خط عريض أبداً، ولا يتلف النص العربي ولا الرموز التعبيرية (emoji).
  • تبقى صفحات الخطأ عامة: لا تتبّع مكدّس (stack trace) ولا جملة SQL ولا مسار ملف. والفاصلة العليا التي تسبب خطأ في قاعدة البيانات تشير إلى نص ملصق في استعلام؛ أبلغ عنها ولا تتعمق في التجربة.
  • النماذج التي تغيّر البيانات تحمل رمزاً مخفياً أو ترسله في ترويسة، ولا يُحذف شيء أو يُدفع أو يُغيَّر عبر رابط عادي.
  • إن كان لديك إذن، فأعد إرسال طلب من هذا النوع بلا رمزه، مثلاً بنسخه بصيغة cURL وحذف الرمز منه. النتيجة المتوقعة: يرفضه الخادم.

جرّبها: مرمّز كيانات HTML

ترويسات الأمان

ترويسات الأمان ترويسات استجابة تشغّل وسائل حماية في المتصفح. وهي طبقة ثانية تحدّ من ضرر عيب مثل XSS ولا تصلحه. افحص صفحات HTML الرئيسية في لوحة Network أو الصق ترويساتها في أداة Security Header Analyzer، واقرأ قيمة كل ترويسة، لا مجرد وجودها.

  • Content-Security-Policy (CSP) تحدد المصادر التي يجوز تحميل السكربتات والأنماط والصور والإطارات منها. القيمة default-src 'self' لا تسمح إلا بأصل الصفحة نفسه (origin)، أي البروتوكول والمضيف والمنفذ نفسها، وتحجب السكربتات المضمّنة؛ أما السماح بـ'unsafe-inline' للسكربتات فيتيح تشغيل سكربت مضمّن محقون، والمصدر * يتيح تحميله من أي موقع.
  • التوجيه frame-ancestors في CSP، أو الترويسة الأقدم X-Frame-Options: DENY، يمنع المواقع الأخرى من تضمين الصفحة في إطار لخداع المستخدمين بالنقر على أزرار مخفية، وهو ما يسمى اختطاف النقرات (Clickjacking).
  • X-Content-Type-Options: nosniff تمنع المتصفح من تخمين نوع الملف، فلا يُشغَّل ملف مقدَّم بوصفه نصاً على أنه سكربت.
  • Referrer-Policy تحدّ من الجزء الذي تتلقاه المواقع الأخرى من عنوان URL؛ وPermissions-Policy توقف ميزات لا يستخدمها الموقع، مثل الكاميرا.
  • ترويسات مثل Server: nginx/1.18.0 أو X-Powered-By تكشف البرمجيات، وكثيراً ما تكشف إصداراتها، وتخبر المهاجمين بالثغرات المعروفة التي يجربونها: احذفها أو اجعلها عامة.

جرّبها: محلّل ترويسات الأمان جرّبها: محلّل ترويسات HTTP

مثال تطبيقي: فحص آمن لصفحة الملف الشخصي

تتضمن خطة الاختبار في متجر إلكتروني فحصاً أمنياً سريعاً لصفحة الملف الشخصي الجديدة، وقد أكّد مسؤول الأمان النطاق كتابةً: بيئة الاختبار، وحسابا اختبار، ومدخلات غير ضارة فقط. ويعمل المختبِر بالمتصفح وأدوات المطوّرين.

العنوان http://test.shop.example/profile ينتهي بإعادة توجيه ⁦301⁩ إلى HTTPS، وترويسات استجابة الصفحة معروضة أدناه. وتُظهر لوحة Application ملف تعريف ارتباط الجلسة sid بالسمتين Secure وSameSite=Lax ولكن بلا HttpOnly. واسم العرض Sara <b>QA</b> يظهر كما كُتب في صفحة الملف الشخصي، لكنه بخط عريض في قائمة العملاء بشاشة الإدارة. والفاصلة العليا في بحث الطلبات تعيد صفحة ⁦500⁩ فيها خطأ من قاعدة البيانات. ونموذج الملف الشخصي يرسل رمزاً مخفياً csrf_token، بينما «حذف العنوان» رابط عادي إلى /profile/address/delete?id=12. وعند أول مؤشر على كل ثغرة يتوقف المختبِر عن التعمق فيها، ويحفظ الدليل، وينتقل إلى الفحص التالي.

يسرد التقرير الملاحظات، الأخطر أولاً: شيفرة HTML في قائمة الإدارة (XSS مخزَّن مرجَّح يعمل بجلسة المسؤول)، وخطأ قاعدة البيانات، ورابط الحذف بطلب GET، وغياب HttpOnly، وغياب CSP والحماية من التضمين في إطار، ثم إصدار nginx ملاحظةً منخفضة الخطورة.

GET /profile HTTP/1.1
Host: test.shop.example

HTTP/1.1 200 OK
Server: nginx/1.18.0
Content-Type: text/html; charset=utf-8
Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
ثمانية فحوص آمنة لصفحة الملف الشخصي في بيئة اختبار متجر، وما لاحظه المختبِر، والخطر الذي يحمي منه كل فحص: اثنان ناجحان وخمسة فاشلة وواحد تحذير.
الفحصما لوحظ في بيئة الاختبارالخطر حين يفشل الفحص
إعادة التوجيه إلى HTTPShttp:// ينتهي بإعادة توجيه ⁦301⁩ إلى https://نجاحيمكن قراءة الصفحات وبيانات النماذج وملفات تعريف الارتباط أو تغييرها على الشبكة
ترويسة HSTSمضبوطة بالقيمة max-age=31536000نجاحيمكن اعتراض عنوان http:// مكتوب يدوياً قبل إعادة التوجيه
سمات ملف تعريف ارتباط الجلسةSecure وSameSite=Lax، ولكن بلا HttpOnlyفشليستطيع سكربت محقون قراءة معرّف الجلسة
شيفرة HTML في اسم العرضكما كُتبت في صفحة الملف الشخصي، وبخط عريض في قائمة الإدارةفشلXSS مخزَّن: سيعمل السكربت بجلسة المسؤول
فاصلة عليا في بحث الطلباتصفحة ⁦500⁩ فيها خطأ من قاعدة البياناتفشلحقن محتمل، ورسالة الخطأ تكشف تفاصيل داخلية
الطلبات التي تغيّر البياناتنموذج الملف الشخصي يرسل رمزاً؛ و«حذف العنوان» رابط GETفشلCSRF: موقع آخر يجعل متصفح المستخدم ينفّذ الإجراء
CSP والحماية من التضمين في إطارلا توجد أيّ منهمافشللا حاجز ثانياً أمام XSS، ويمكن تضمين الصفحة في إطار لاختطاف النقرات
ترويسات أخرىnosniff وReferrer-Policy مضبوطتان؛ وServer تُظهر nginx/1.18.0تنبيهالإصدار يخبر المهاجمين بالثغرات المعروفة التي يجربونها

الفحص الفاشل ملاحظة تُبلَّغ، لا دليل على استغلال؛ ففريق الأمان هو من يؤكد مدى خطورتها.

أخطاء شائعة

  • تجربة الفحوص الأمنية على بيئة الإنتاج أو على مواقع شركات أخرى دون إذن مكتوب: فقيمة الاختبار غير الضارة قد تُسجَّل وتُعامل بوصفها هجوماً.
  • استخدام حمولات سكربت أو أدوات فحص آلي منقولة من درس على الإنترنت بدلاً من العلامات غير الضارة، أو مواصلة التجربة بعد أول مؤشر على ثغرة بدلاً من الإبلاغ عنها.
  • فحص المدخلات في مكان إدخالها فقط، وعدم فحصها حيث تُعرض لاحقاً: شاشات الإدارة ورسائل البريد الإلكتروني والملفات المصدَّرة وملفات PDF.
  • اعتبار فحوص المتصفح مثل maxlength أو type="email" حماية؛ فالعبرة بفحوص الخادم وحدها.
  • تسجيل الترويسة موجودةً دون قراءة قيمتها: فـContent-Security-Policy التي تسمح بسكربتات 'unsafe-inline' لا تحمي من XSS إلا قليلاً.
  • تسجيل الملاحظات الأمنية في نظام تتبع يقرؤه الجميع، أو لصق ملفات تعريف ارتباط ورموز حقيقية في التقرير.

من منظور ضمان الجودة

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

أبلغ عن الملاحظات كأي عيب: الخطوات، والمدخل غير الضار، ومكان ظهوره، والطلب والاستجابة مع إخفاء الأسرار؛ ولكن بصلاحية اطلاع مقيّدة، واتفق على الخطورة مع فريق الأمان الذي يحكم على قابلية الاستغلال. وبعد الإصلاح أجرِ اختبار التأكيد في كل مكان تظهر فيه القيمة، وأبقِ الفحوص في حزمة الانحدار: فالترويسات وسمات ملفات تعريف الارتباط كثيراً ما تتغيّر مع خادم جديد أو وكيل (proxy) جديد أو إصدار جديد من إطار العمل.

تمرين عملي

راجع صفحة حجز في عيادة بأمان

المطلوب

لديك إذن مكتوب بفحص أمني سريع لبيئة الاختبار في موقع حجز مواعيد لعيادة. وأدناه استجابة صفحة المواعيد وأربع ملاحظات: (⁦1⁩) عنوان http:// يحمّل الصفحة دون إعادة توجيه؛ (⁦2⁩) رابط الإلغاء Cancel؛ (⁦3⁩) ملاحظة كتبتها بصفتك المريض في نموذج الحجز، وتظهر في شاشة الطبيب وكلمة results فيها مائلة؛ (⁦4⁩) الطلب الذي يرسله نموذج تسجيل الدخول.

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

المادة
GET https://test.clinic.example/appointments

HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8
X-Powered-By: Express
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'
X-Frame-Options: DENY
Set-Cookie: session=c2Vzc2lvbi0x; Path=/; HttpOnly

(1) GET http://test.clinic.example/appointments  ->  200 OK
(2) <a href="/appointments/cancel?id=481">Cancel</a>
(3) Bring <i>results</i>
(4) GET /login?user=sara&password=[masked]
الخطوات
  1. الصق ترويسات الاستجابة في أداة Security Header Analyzer وسطر Set-Cookie في أداة Cookie Analyzer، وسجّل ما هو موجود أو مفقود أو ضعيف.
  2. صنّف كل ملاحظة من الملاحظات الأربع: ناجحة أم ملاحظة أمنية.
  3. اكتب لكل ملاحظة أمنية الخطر في جملة واحدة وعنواناً لتقرير الخطأ.
  4. رتّب الملاحظات، واكتب الفحوص الآمنة التالية، وفحصاً واحداً يحتاج إلى موافقة فريق الأمان.
إظهار الإجابة النموذجية
الإجابة النموذجية

الناجح: X-Frame-Options: DENY تمنع التضمين في إطار، وملف تعريف ارتباط الجلسة يحمل HttpOnly. وتوجد CSP بالقيمة default-src 'self' لكنها ضعيفة: فـ'unsafe-inline' في script-src تتيح تشغيل سكربت مضمّن محقون، وهذا يهم الملاحظة الأمنية (أ).

الملاحظات الأمنية، الأخطر أولاً، مرقّمة بالحروف كي لا تختلط بأرقام البنود. (أ، البند ⁦3⁩) «ملاحظة الموعد تُعرض بوصفها HTML في شاشة الطبيب»: XSS مخزَّن مرجَّح لن تمنعه CSP لأنها تسمح بسكربتات 'unsafe-inline'. (ب، البند ⁦4⁩) «تسجيل الدخول يرسل كلمة المرور في عنوان URL لطلب GET»، حيث يحفظها سجل المتصفح وسجلات الخادم والترويسة Referer. (ج، البند ⁦1⁩) «صفحة المواعيد تُقدَّم عبر HTTP دون إعادة توجيه أو HSTS»؛ ومع غياب Secure ينتقل معرّف الجلسة بلا تشفير.

(د، البند ⁦2⁩) «إلغاء الموعد رابط GET بلا حماية من CSRF»: يستطيع موقع آخر أن يقود متصفح مريض مسجّل الدخول إليه؛ وملف تعريف الارتباط بلا قيمة SameSite صريحة، وحتى SameSite=Lax كانت سترسله عند اتباع رابط. (هـ، ترويسات الاستجابة) منخفضة الخطورة: X-Powered-By: Express تكشف إطار العمل، وnosniff وReferrer-Policy مفقودتان.

الفحوص الآمنة التالية: الملاحظة في شاشة المريض، وفي رسائل التذكير بالبريد الإلكتروني والنسخ المطبوعة؛ وعلامات الاقتباس والفاصلة العليا في الملاحظة وفي الحقول النصية الأخرى. ولا يُجرى دون فريق الأمان: تجربة سكربت في الملاحظة، أو تشغيل أداة فحص آلي، أو تغيير المعرّف لإلغاء حجز مريض آخر.

أسئلة شائعة

هل هذا هو اختبار الاختراق نفسه؟

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

لماذا أختبر بـ<b> بدلاً من سكربت حقيقي؟

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

الموقع يعيد التوجيه إلى HTTPS، فهل ما زال ملف تعريف ارتباط الجلسة يحتاج إلى Secure؟

نعم. فمن دون Secure يرسل المتصفح ملف تعريف الارتباط أيضاً مع أي طلب http:// عادي إلى المضيف نفسه، مثل عنوان مكتوب يدوياً أو رابط قديم، قبل حدوث إعادة التوجيه. وHSTS تقلّل هذه الطلبات، لكن Secure حماية الملف نفسه ولا تكلّف شيئاً.

هل يعني تقدير جيد من أداة فحص الترويسات أن الموقع آمن؟

لا. الترويسات طبقة ثانية تحدّ من الضرر، ولا تقول شيئاً عن التحكم في الوصول أو الحقن أو الجلسات أو قواعد العمل. استخدم التقدير قائمةً بالترويسات المفقودة أو الضعيفة، واقرأ كل قيمة بنفسك.

المراجع

  • OWASP Web Security Testing Guide (WSTG)OWASP Foundationالمنهجية المرجعية لاختبار تطبيقات الويب وواجهات API بحثاً عن نقاط الضعف الأمنية، اختباراً تلو الآخر.
  • OWASP Cheat Sheet Series: Cross Site Scripting PreventionOWASP Foundationمنع XSS: الترميز عند الإخراج بحسب كل سياق، وتعقيم HTML الذي يكتبه المستخدم، ومواضع الإدراج الآمنة في DOM وحمايات الأطر، مع اعتبار CSP طبقة دفاع إضافية فقط.
  • OWASP Cheat Sheet Series: Cross-Site Request Forgery PreventionOWASP Foundationدفاعات CSRF: رموز المزامنة وملفات تعريف الارتباط SameSite وفحص المصدر.
  • OWASP Cheat Sheet Series: HTTP HeadersOWASP Foundationأي ترويسات أمنية تُرسَل (HSTS وCSP وX-Content-Type-Options وحماية الإطارات) وأيها تُزال (Server وX-Powered-By).
الأدوات

تدرّب بأدوات متقن

محلّل ترويسات الأمان

تقييم ترويسات أمان HTTP (CSP وHSTS وX-Frame-Options وReferrer-Policy وPermissions-Policy وCOOP/CORP) من ترويسات ملصقة أو عنوان URL عام.

التحقق

مرمّز كيانات HTML

تهريب أحرف HTML الخاصة (< و> و& وعلامات الاقتباس) إلى كيانات لمنع هجمات XSS.

الترميز

محلّل ترويسات HTTP

تحليل ترويسات طلبات واستجابات HTTP الخام إلى جدول منظّم مع الشروحات.

الويب

للتعمّق أكثر

تقدّمك في هذا الموضوع

جزء من مسار تعلم ضمان الجودة

الموضوعات التالية