فحص خارجي سلبي. تحمل كل نتيجة الملاحظة الأولية التي أجراها الماسح الضوئي
وأمراً يمكنك تشغيله بنفسك لإعادة إنتاجها - لا يوجد شيء هنا مكتوب بواسطة نموذج.
14 مجموعات الفحص:
تحليل DNS والتحقق من سجلات CAA · التحقق من SPF وDMARC · فحص شهادة TLS وإصدارات البروتوكول · اختبار إعادة التوجيه من HTTP إلى HTTPS · قراءة ترويسات الأمان في الاستجابة · التحقق من خصائص ملفات تعريف الارتباط · فحص سياسة CORS · البحث عن لافتات الإصدار · التحقق من طرق HTTP المسموح بها · فحص الصفحة الرئيسية بحثًا عن محتوى مختلط ونماذج غير آمنة · البحث عن ملفات الإعدادات وضبط الإصدارات المكشوفة · التحقق من قوائم الدلائل · قراءة robots.txt وsecurity.txt · التحقق من منافذ الخدمة المكشوفة
جاري البدء…
0%
حول فحص أمان الموقع الإلكتروني
كثير من الماسحات يمنحك درجة بالأحرف وقائمة من الكلمات المخيفة. هذا الماسح يعطي درجة أيضًا، لكن كل نقطة يخصمها مرتبطة بنتيجة تعرض الاستجابة التي حصل عليها فعلًا والأمر ذا السطر الواحد الذي يعيد لك الاستجابة نفسها، فالنتيجة شيء يمكنك التحقق منه لا شيء عليك تصديقه.
تحمل كل نتيجة الملاحظة الخام وأمر shell لإعادة إنتاجها.
الفحوصات التي تعذّر تشغيلها يُبلَّغ عنها بعبارة "لم يتم الفحص" - وليس بصمت على أنها ناجحة.
يمكن تنزيل التقارير بصيغة Markdown أو JSON.
كيف يعمل
1أدخل نطاقاً أنت مسؤول عنه.
2يُجري الفحص عمليات تحرٍّ غير فعّالة - طلبات عادية، بلا استغلال.
3اقرأ النتائج، كل واحدة مع دليلها، وتحقّق من المهمة منها.
لا تُخترَع أي نتيجة
لا يحتوي الماسح على أي نموذج لغوي. الخطورة والأثر وطريقة الإصلاح ثابتة لكل فحص، وكل نتيجة تُولَّد من ملاحظة حقيقية. التقرير المعروض على الشاشة وتنزيلات Markdown وJSON تُبنى من النتائج نفسها، دون أي نموذج على الإطلاق.
كيف تُحسب الدرجة
تبدأ النتيجة من 100 وتخسر 34 نقطة لكل نتيجة حرجة، و13 لكل عالية، و5 لكل متوسطة، و1.5 لكل منخفضة، مع حد أقصى لكل مستوى خطورة (العالية 45، المتوسطة 22، المنخفضة 9). النتائج المعلوماتية والناجحة لا تخصم شيئًا. 90 فأكثر تعني A، و75 تعني B، و60 تعني C، و40 تعني D، وما دون ذلك F. ملف .env واحد مكشوف أو منفذ قاعدة بيانات يمكن الوصول إليه ينزل بموقع سليم من 100 إلى 66، أي C؛ ونتيجتان من هذا النوع تعطيان 32، أي F.
تجنب الإنذارات الكاذبة
قبل فحص مسارات مثل /.git/HEAD أو /backup.sql، يطلب الماسح عنوانًا عشوائيًا لا يمكن أن يوجد ويسجل كيف يجيب الموقع. لا يُعد المسار مكشوفًا إلا إذا أعاد HTTP 200، واختلف عن تلك الاستجابة المرجعية لغير الموجود، وطابق التوقيع الخاص بالملف، لذلك لا يمتلئ موقع يجيب عن كل عنوان بصفحته الرئيسية بنتائج حرجة.
التقرير النظيف ليس شهادة
هذه فحوصات غير فعّالة لموقع قيد التشغيل. لا تغطي منطق التطبيق أو المصادقة أو التحكم في الوصول أو أي شيء خلف تسجيل الدخول - وهي الأماكن التي تبدأ فيها الخروقات الحقيقية عادةً. الفحوصات التي تعذّر إتمامها تُدرَج كغير مفحوصة لهذا السبب بالضبط: النجاح المستمَد من اتصال فاشل هو طمأنة زائفة، وفحص بلا نتائج يعني أنه لم يُعثَر على شيء، لا أنه لا يوجد شيء.
افحص فقط ما يخصّك
افحص النطاقات التي تملكها أو التي لديك إذن خطي لاختبارها. ترفض الأداة المضيفات التي تُحلَّل إلى عناوين خاصة أو داخلية، وهي محدودة المعدل لكل عنوان IP، لكن التفويض يبقى مسؤوليتك.
الأسئلة
هل هذا هجوم فعّال؟
لا. يرسل طلبات GET وHEAD وOPTIONS عادية، ويجري مصافحات TLS (بما فيها محاولات TLS 1.0 و1.1)، واستعلامات DNS عبر خدمة DNS عبر HTTPS من Cloudflare، واتصالات TCP بسيطة إلى 12 منفذًا. لا يُستغل شيء، ولا يُرسل أي نموذج، ولا يُعدَّل شيء.
هل يمكنني فحص أي موقع ويب؟
فقط المواقع التي تملكها أو المُخوَّل لك اختبارها. فحص بنية تحتية لطرف ثالث بدون إذن قد يكون غير قانوني في مكانك.
لماذا يقول الفحص "لم يتم الفحص"؟
لأنه تعذّر إتمامه - عادةً لأن شيئاً لم يستجب من ذلك المصدر. يُبلَّغ عن ذلك بصدق بدلاً من تسجيله كنجاح.
هل يمكنني تصدير التقرير؟
نعم، بصيغة Markdown أو JSON لمدة ساعة: يُحفظ التقرير في ذاكرة التخزين المؤقت للخادم طوال تلك الساعة لكي تعمل التنزيلات، ثم تنتهي صلاحيته. لا يستخدم أي تصدير نموذجًا. يحتفظ سجل الاستخدام بعدد النتائج والدرجة، لا باسم النطاق.
ما الملفات والمنافذ التي يفحصها؟
الملفات: 23 مسارًا ثابتًا، منها /.git/HEAD, /.git/config, /.env, /.env.local, /.env.production, /.aws/credentials, /id_rsa, /backup.zip, /backup.sql, /dump.sql, /wp-config.php.bak, /phpinfo.php, /server-status, /actuator/env، ولا يُبلَّغ عن أي منها إلا إذا طابقت الاستجابة البصمة الخاصة بذلك الملف؛ ويُحسب /.well-known/security.txt لصالحك إذا كان منشورًا. المنافذ: اتصال TCP بسيط، وليس محاولة تسجيل دخول أبدًا، إلى 21 FTP, 23 Telnet, 25 SMTP, 3306 MySQL, 5432 PostgreSQL, 6379 Redis, 27017 MongoDB, 9200 Elasticsearch, 3389 RDP, 5900 VNC, 11211 Memcached, 8080. يُصنَّف منفذ قاعدة بيانات يمكن الوصول إليه (MySQL وPostgreSQL وRedis وMongoDB وElasticsearch) أو Telnet على أنه حرج.
ما الذي تُبلِّغ عنه فحوص SPF وDMARC؟
يُقرأ السجلّان من DNS العام، حتى لموقع لا يرسل بريدًا، لأنه من دونهما يستطيع أي شخص إرسال بريد يدّعي أنه من نطاقك. غياب سجل SPF خطورته متوسطة؛ وسجل SPF يحتوي على +all، أي يأذن لكل خادم على الإنترنت، خطورته عالية. غياب سجل DMARC تحت _dmarc متوسط؛ وp=none (أو غياب الوسم p=) للمراقبة فقط وخطورته منخفضة؛ أما p=quarantine أو p=reject فيجتاز الفحص. يمكن للنطاق الذي لا يرسل أي بريد أن ينشر v=spf1 -all.
ما ترويسات الأمان التي يفحصها، وما القيمة التي تجتاز الفحص؟
ست ترويسات في استجابة صفحتك الرئيسية. عند غيابها تكون خطورة HSTS وContent-Security-Policy عالية، وX-Content-Type-Options وX-Frame-Options متوسطة، وReferrer-Policy وPermissions-Policy منخفضة. تحتاج Strict-Transport-Security إلى max-age لا يقل عن 15552000 (180 يومًا): الأقصر منخفض، وmax-age=0 متوسط. تُعَدّ Content-Security-Policy مُضعَفة (متوسطة) إذا سمح script-src بـ 'unsafe-inline'، أو سمحت السياسة بـ 'unsafe-eval'، أو احتوى default-src أو script-src على حرف البدل * منفردًا. يجب أن تكون قيمة X-Content-Type-Options هي nosniff تمامًا. ويجب أن تكون X-Frame-Options هي DENY أو SAMEORIGIN، ولا حاجة إليها إذا حددت CSP قيمة frame-ancestors. لا يُبلَّغ عن Referrer-Policy إلا مع unsafe-url أو no-referrer-when-downgrade. ويكفي أن تكون Permissions-Policy موجودة. ترافق كل ترويسة غائبة أو ضعيفة أمر curl -sI لتتحقق منها بنفسك.
كيف يفحص سمات ملفات تعريف الارتباط (Secure وHttpOnly وSameSite)؟
يقرأ كل ترويسة Set-Cookie في استجابة صفحتك الرئيسية (حتى 12 ملف تعريف ارتباط) ويتحقق في كل منها من Secure وHttpOnly وSameSite. غياب Secure أو HttpOnly خطورته متوسطة، وغياب SameSite وحده منخفضة، ويُنبَّه إلى SameSite=None من دون Secure لأن المتصفحات ترفض هذا الملف. الملف الذي يحمل السمات الثلاث ينجح. الإصلاح المعتاد هو Secure; HttpOnly; SameSite=Lax (وفي Django: SESSION_COOKIE_SECURE وSESSION_COOKIE_HTTPONLY وSESSION_COOKIE_SAMESITE). لا يسجّل الفحص الدخول، لذا لا يرى الملفات التي تُنشأ بعد تسجيل الدخول فقط. تحقّق بنفسك عبر curl -sI https://your-site/ | grep -i set-cookie
كيف يعمل فحص CORS، ومتى يكون حرجًا؟
يرسل طلب GET واحدًا إلى صفحتك الرئيسية مع Origin: https://scanner-probe.example ويقرأ Access-Control-Allow-Origin وAccess-Control-Allow-Credentials في الرد. غياب ترويسة Access-Control-Allow-Origin، أو وجود أصل ثابت لا يعيد أصل الاختبار، يعني النجاح. إعادة أصل الاختبار مع Access-Control-Allow-Credentials: true خطورتها حرجة، لأن أي موقع يزوره مستخدم مسجّل الدخول يستطيع قراءة ردوده. إعادة الأصل من دون بيانات اعتماد متوسطة. حرف البدل * منخفض، أو متوسط إذا سُمح ببيانات الاعتماد أيضًا (المتصفحات ترفض هذا الجمع). تُفحص الصفحة الرئيسية فقط ولا يُرسل طلب OPTIONS التمهيدي، لذا افحص مسارات واجهتك البرمجية على حدة عبر curl -sI -H "Origin: https://scanner-probe.example" https://your-site/api/ | grep -i access-control
يتصل بالمنفذ 443 ويتحقق من سلسلة الشهادة واسم المضيف. الشهادة التي لا تجتاز التحقق خطورتها عالية، والمنتهية الصلاحية تُعلَّم أيضًا بأنها حرجة، والتي بقي لها أقل من 15 يومًا متوسطة؛ وإلا تُعرض الجهة المالكة والجهة المُصدِرة وتاريخ الانتهاء وأسماء SAN على أنها ناجحة. يجب أن يكون البروتوكول المتفق عليه TLS 1.2 أو TLS 1.3، وأي إصدار أقدم خطورته عالية. ثم يجرّب مصافحة TLS 1.0 ومصافحة TLS 1.1 كلًّا على حدة: الخادم الذي يقبل أيًّا منهما يحصل على نتيجة متوسطة، لأن كليهما أُلغي استخدامه بموجب RFC 8996. وإذا لم يستطع OpenSSL الخاص بالماسح نفسه عرض الإصدار القديم، فلا يُبلَّغ عن شيء بدل التخمين. الإصلاح في nginx هو ssl_protocols TLSv1.2 TLSv1.3; تحقق من التواريخ بنفسك باستخدام echo | openssl s_client -connect your-site:443 -servername your-site 2>/dev/null | openssl x509 -noout -dates
هل يتحقق من أن HTTP يعيد التوجيه إلى HTTPS؟
نعم. يطلب http://your-site/ دون اتباع عمليات إعادة التوجيه. إعادة التوجيه 301 أو 308 إلى عنوان https:// ناجحة. أما 302 أو 303 أو 307 إلى HTTPS فخطورتها منخفضة، لأن المتصفحات لا تتذكر إعادة التوجيه المؤقتة، فتبدأ كل زيارة جديدة بطلب غير مشفر. والصفحة المقدَّمة عبر HTTP غير المشفر (استجابة 2xx) خطورتها عالية. وإذا لم يستجب المنفذ 80 إطلاقًا فهذه معلومة وليست إخفاقًا. الإصلاح في nginx هو server { listen 80; return 301 https://$host$request_uri; }، ثم أضف Strict-Transport-Security. تحقق بنفسك باستخدام curl -I http://your-site/
ما طرق HTTP التي ينبّه عليها (TRACE وPUT وDELETE)؟
يرسل طلب OPTIONS واحدًا إلى صفحتك الرئيسية ويقرأ ترويسة Allow، أو Access-Control-Allow-Methods إذا غابت Allow. إذا أُعلن عن TRACE أو TRACK أو PUT أو DELETE فالخطورة متوسطة؛ وPATCH أو CONNECT وحدهما خطورتهما منخفضة؛ ووجود طرق القراءة القياسية فقط نجاح. وإذا لم يرسل الخادم أيًّا من الترويستين فلا يُبلَّغ عن شيء. الإعلان عن طريقة لا يثبت أنها تعمل، لذا تحقق منها قبل تغيير أي شيء. يمكن لـ TRACE أن يعيد إلى الطالب ترويسات الطلب بما فيها ملفات تعريف الارتباط (Cross-Site Tracing). يرفض nginx طريقة TRACE افتراضيًا؛ وفي Apache اضبط TraceEnable Off. اقصر PUT وDELETE على مسارات API التي تحتاجهما، خلف المصادقة. تحقق بنفسك باستخدام curl -X OPTIONS -i https://your-site/
كيف يكتشف عرض محتويات المجلدات ("Index of /")؟
يطلب 7 مسارات: /, /static/, /assets/, /uploads/, /images/, /files/ و/backup/. المسار الذي يجيب HTTP 200 بصفحة يبدأ عنوانها أو عنوانها الرئيسي بـ "Index of /" يُبلَّغ عنه بخطورة متوسطة (CWE-548)، لأن القائمة تكشف ملفات غير مرتبطة من أي مكان، مثل النسخ الاحتياطية والملفات المصدَّرة والإصدارات القديمة. إذا لم يفعل ذلك أي مسار فالفحص ناجح؛ وإذا تعذّر الوصول إلى الموقع يُبلَّغ عنه بأنه لم يُنفَّذ. الإصلاح في nginx هو autoindex off; (وهو الافتراضي، فابحث عن autoindex on صريح)، وفي Apache هو Options -Indexes، ثم انقل أي شيء حساس خارج جذر الموقع. تحقق بنفسك باستخدام curl -s https://your-site/uploads/ | head -20
هل يكتشف المحتوى المختلط والنماذج التي تُرسل عبر HTTP؟
نعم، في الصفحة الرئيسية. يقرأ HTML كما يُقدَّم (من دون تشغيل JavaScript) ويسرد كل وسم script أو link أو iframe أو img تبدأ قيمة src أو href فيه بـ http://. إذا كان أحدها ملف .js أو .css فالنتيجة متوسطة، لأن سكربتًا أو ملف أنماط يُستبدل أثناء النقل يعمل داخل صفحتك HTTPS؛ والصور والإطارات وحدها منخفضة؛ وعدم وجود أي منها نجاح (CWE-311). أما النموذج الذي يبدأ action فيه بـ http:// فيُصنَّف عاليًا (CWE-319)، لأن كل ما يُكتب فيه، بما في ذلك كلمات المرور، يُرسل بلا تشفير. الإصلاح هو تغيير هذه العناوين إلى https:// أو جعلها نسبية، وإضافة الترويسة Content-Security-Policy: upgrade-insecure-requests كشبكة أمان. تحقق بنفسك باستخدام curl -s https://your-site/ | grep -Eo "(src|href|action)=.http://[^ >]*"
ماذا يفحص في robots.txt وsecurity.txt؟
robots.txt: يجلب /robots.txt، وإذا أعاد HTTP 200 كملف نصي يقرأ أسطر Disallow في أول 8000 حرف منه. أي مسار Disallow يحتوي على إحدى الكلمات admin, internal, private, backup, config, staging, test, api, secret, dev يُصنَّف منخفضًا (CWE-200): فملف robots.txt علني ولا يفعل سوى أن يطلب من الزواحف الملتزمة الابتعاد، لذا فإن ذكر هذه المسارات فيه يعلن عنها. احمها بتسجيل الدخول، واستخدم noindex لإبقاء الصفحات خارج نتائج البحث. security.txt: يطلب /.well-known/security.txt، وهو الموقع الذي يحدده RFC 9116، ويحسبه لصالحك إذا احتوى الملف على سطر Contact:. غياب الملف لا يُنقص الدرجة. ويشترط RFC 9116 أيضًا حقل Expires:، وهو ما لا يفحصه الماسح، لذا انشر الاثنين، مثلًا Contact: mailto:security@your-site, Expires: 2027-06-30T23:00:00Z. تحقق بنفسك باستخدام curl -s https://your-site/.well-known/security.txt
ما الذي يبحث عنه فحص CAA وكيف أضيف سجل CAA؟
يستعلم عن سجلات CAA (RFC 8659) لاسم المضيف الذي أدخلته عبر خدمة DNS-over-HTTPS من Cloudflare. إذا وجد سجلات ينجح الفحص ويعرض الدليل حتى 5 منها؛ وإذا لم يجد أيًا منها يبلغ عن "No CAA record" بخطورة منخفضة، لأن أي جهة إصدار شهادات عامة يمكنها حينئذ إصدار شهادة لهذا الاسم. يذكر سجل CAA جهات الإصدار التي تستخدمها فعلًا، مثل your-site. IN CAA 0 issue "letsencrypt.org"، بالإضافة إلى 0 iodef "mailto:security@your-site" لتلقي البلاغات. أضف سطر issue لكل جهة إصدار تستخدمها، وسطر issuewild إذا كانت شهادات wildcard يجب أن تأتي من جهة أخرى. تحقق بنفسك باستخدام dig CAA your-site
لماذا يُظهر فحص www أو نطاق فرعي عدم وجود CAA أو SPF أو DMARC؟
يعمل كل فحص DNS على الاسم الذي أدخلته بالضبط، فيُستعلم عن www.example.com بوصفه www.example.com وليس example.com، والسجلات الثلاثة تُورث بطرق مختلفة. CAA: جهة الإصدار التي لا تجد سجل CAA على www.example.com تصعد إلى example.com وتستخدم سجله (RFC 8659، القسم 3)، لذا قد تكون نتيجة "No CAA record" على نطاق فرعي إنذارًا كاذبًا. DMARC: يرجع المستلمون إلى سياسة النطاق التنظيمي، الذي يمكنه تحديد سياسة مستقلة للنطاقات الفرعية عبر sp= (RFC 9989 الذي حل محل RFC 7489)، لذا فإن غياب السجل في _dmarc.www.example.com تغطيه عادة _dmarc.example.com. SPF: لا يوجد توريث (RFC 7208)، لذا فإن "No SPF record" صحيحة لهذا الاسم؛ ويمكن لاسم مضيف لا يرسل بريدًا أن ينشر v=spf1 -all. ويظهر استعلام DNS الفاشل أيضًا كسجل غير موجود. افحص النطاق المجرد أيضًا، أو تحقق باستخدام dig CAA example.com وdig TXT _dmarc.example.com