یک اسکن بیرونی غیرفعال. هر یافته شامل مشاهده خامی است که اسکنر انجام داده و دستوری که خودتان می‌توانید برای بازتولید آن اجرا کنید - هیچ چیز در اینجا توسط مدل نوشته نشده است.
14 گروه‌های بررسی:
تحلیل DNS و بررسی رکورد CAA · بررسی SPF و DMARC · بررسی گواهی TLS و نسخه‌های پروتکل · آزمایش هدایت از HTTP به HTTPS · خواندن هدرهای امنیتی پاسخ · بررسی ویژگیهای کوکی · بررسی سیاست CORS · جست‌وجوی بنرهای نسخه · بررسی روش‌های مجاز HTTP · اسکن صفحه اصلی برای محتوای مختلط و فرم‌های ناامن · جست‌وجوی فایل‌های پیکربندی و کنترل نسخه افشا شده · بررسی فهرست‌گیری از دایرکتوری‌ها · خواندن robots.txt و security.txt · بررسی پورت‌های سرویس افشا شده
در حال شروع…
0%
درباره اسکن امنیت وب‌سایت
بسیاری از اسکنرها یک نمره حرفی و فهرستی از واژه‌های ترسناک به شما می‌دهند. این یکی هم نمره میدهد، اما هر امتیازی که کم میکند به یافته‌ای وابسته است که پاسخ واقعی دریافت‌شده و فرمان یک‌خطی‌ای را نشان میدهد که همان پاسخ را به شما برمی‌گرداند؛ پس یافته چیزی است که می‌توانید تأیید کنید، نه چیزی که باید باور کنید.
عملکرد
DNS و CAA، SPF و DMARC، گواهی TLS و TLS 1.0/1.1، تغییر مسیر به HTTPS، سرآیندهای امنیتی، ویژگیهای کوکی، CORS، بنرهای نسخه، روش‌های HTTP، محتوای مختلط، ۲۳ مسیر حساس، فهرست پوشه‌ها، robots.txt، security.txt و ۱۲ درگاه سرویس را بررسی میکند.
هر یافته مشاهده خام و یک دستور شل برای بازتولید آن را همراه دارد.
گزارش‌ها به‌صورت Markdown یا JSON قابل دانلود هستند.
نحوه کار
1دامنهای را که مسئول آن هستید وارد کنید.
2اسکن آزمایش‌های غیرفعال اجرا میکند - درخواستهای معمولی، بدون بهره‌برداری.
3یافته‌ها را، هر یک با شواهدش، بخوانید و آن‌هایی که اهمیت دارند را تأیید کنید.
هیچ یافته‌ای ساختگی نیست
اسکنر هیچ مدل زبانی ندارد. شدت، اثر و راه رفع برای هر بررسی ثابت است و هر یافته از یک مشاهده واقعی ساخته میشود. گزارش روی صفحه و فایل‌های Markdown و JSON از همان یافته‌ها ساخته میشوند و هیچ مدلی در کار نیست.
نمره چطور حساب میشود
امتیاز از ۱۰۰ شروع میشود و برای هر یافته بحرانی ۳۴، هر یافته بالا ۱۳، هر یافته متوسط ۵ و هر یافته پایین ۱٫۵ امتیاز کم میشود و مجموع هر سطح سقف دارد (بالا ۴۵، متوسط ۲۲، پایین ۹). نتیجه‌های اطلاعاتی و قبول‌شده چیزی کم نمی‌کنند. ۹۰ و بالاتر A، از ۷۵ B، از ۶۰ C، از ۴۰ D و پایین‌تر F است. یک فایل .env در معرض دید یا یک درگاه پایگاه داده در دسترس، سایتی بی‌نقص را از ۱۰۰ به ۶۶ یعنی C می‌رساند؛ دو یافته از این نوع ۳۲ یعنی F میدهد.
پرهیز از هشدار نادرست
اسکنر پیش از آزمودن مسیرهایی مانند /.git/HEAD یا /backup.sql، یک نشانی تصادفی را که نمی‌تواند وجود داشته باشد درخواست میکند و پاسخ سایت را ثبت میکند. مسیری فقط وقتی در معرض دید گزارش میشود که HTTP 200 برگرداند، با آن پاسخ مرجع «یافت نشد» فرق داشته باشد و با امضای خود فایل جور باشد؛ پس سایتی که به هر نشانی با صفحه اصلی‌اش پاسخ میدهد، پر از یافته بحرانی نمیشود.
یک گزارش پاک، گواهی‌نامه نیست
این‌ها بررسیهای غیرفعال در برابر یک سایت در حال اجرا هستند. منطق برنامه، احراز هویت، کنترل دسترسی یا هر چیز پس از ورود را پوشش نمی‌دهند - جاهایی که نقض‌های واقعی معمولاً از آنها شروع میشوند. بررسی‌هایی که نتوانستند کامل شوند دقیقاً به همین دلیل بهعنوان بررسی‌نشده فهرست میشوند: قبولی ناشی از یک اتصال ناموفق یک آرامش کاذب است، و اسکن بدون یافته به این معناست که چیزی پیدا نشده، نه اینکه چیزی وجود ندارد.
فقط آنچه از خودتان است را اسکن کنید
دامنه‌هایی را اسکن کنید که مالک آنها هستید یا اجازه کتبی برای آزمایش آنها دارید. این ابزار میزبان‌هایی را که به آدرس‌های خصوصی یا داخلی حل میشوند رد میکند و برای هر IP محدودیت نرخ دارد، اما مجوز همچنان مسئولیت شماست.
سوالات
آیا این یک حمله فعال است؟
نه. درخواستهای معمولی GET، HEAD و OPTIONS، دستدهیهای TLS (از جمله تلاش با TLS 1.0 و 1.1)، پرسوجوهای DNS از طریق DNS-over-HTTPS از Cloudflare و اتصالهای ساده TCP به ۱۲ درگاه انجام میدهد. از هیچ چیز سوءاستفاده نمیشود، هیچ فرمی ارسال نمیشود و چیزی تغییر نمیکند.
آیا میتوانم هر وبسایتی را اسکن کنم؟
فقط سایتهایی که مالک آنها هستید یا برای آزمایش آنها مجاز هستید. اسکن کردن زیرساخت شخص ثالث بدون اجازه ممکن است در محل شما غیرقانونی باشد.
چرا یک بررسی می‌گوید "بررسی نشده"؟
زیرا نتوانست کامل شود - معمولاً چون چیزی از آن مبدأ پاسخ نداد. این به‌صورت صادقانه گزارش میشود، نه ثبت‌شده بهعنوان قبولی.
آیا میتوانم گزارش را صادر کنم؟
بله، به صورت Markdown یا JSON و به مدت یک ساعت: گزارش در این مدت در حافظه نهان سرور می‌ماند تا دانلودها کار کنند و سپس منقضی میشود. هیچ خروجی‌ای از مدل استفاده نمیکند. در سابقه استفاده تعداد یافته‌ها و نمره ثبت میشود، نه نام دامنه.
کدام فایلها و پورتها را بررسی میکند؟
فایلها: ۲۳ مسیر ثابت، از جمله /.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 (۱۸۰ روز) نیاز دارد: کمتر از آن پایین است و 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 فرستاده نمیشود، پس مسیرهای API را جداگانه بیازمایید: curl -sI -H "Origin: https://scanner-probe.example" https://your-site/api/ | grep -i access-control
بررسی TLS چه چیزی را آزمایش میکند (انقضای گواهی، TLS 1.0 و 1.1)؟
به درگاه 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 را میخواند، یا اگر Allow نباشد Access-Control-Allow-Methods را. اگر 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 اضافه کنید، و اگر گواهی‌های wildcard باید از مرجع دیگری بیایند یک خط issuewild. خودتان با dig CAA your-site بررسی کنید
چرا اسکن www یا یک زیردامنه نبودِ CAA، SPF یا DMARC را گزارش میکند؟
هر بررسی DNS روی دقیقاً همان نامی اجرا میشود که وارد کرده‌اید؛ پس www.example.com به‌صورت www.example.com استعلام میشود، نه example.com، و این سه رکورد به شکل‌های متفاوتی به ارث می‌رسند. CAA: مرجع صدور گواهی که روی www.example.com رکورد CAA نیابد، به 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 ناموفق هم به‌صورت رکورد ناموجود نشان داده میشود. دامنه اصلی بدون www را هم اسکن کنید یا با dig CAA example.com و dig TXT _dmarc.example.com تأیید کنید