Question 1

क्या यह एक सक्रिय हमला है?

Accepted Answer

नहीं। यह साधारण GET, HEAD और OPTIONS अनुरोध, TLS हैंडशेक (TLS 1.0 और 1.1 के प्रयास सहित), Cloudflare के DNS-over-HTTPS से DNS लुकअप और 12 पोर्ट पर सादे TCP कनेक्ट करता है। कुछ भी एक्सप्लॉइट नहीं होता, कोई फ़ॉर्म सबमिट नहीं होता और कुछ भी बदला नहीं जाता।

Question 2

क्या मैं किसी भी वेबसाइट को स्कैन कर सकता हूँ?

Accepted Answer

केवल वे जिनके आप मालिक हैं या जिन्हें टेस्ट करने के लिए आप अधिकृत हैं। बिना अनुमति किसी तीसरे पक्ष के इंफ्रास्ट्रक्चर को स्कैन करना आपके स्थान पर गैरकानूनी हो सकता है।

Question 3

कोई जाँच "जाँच नहीं हुई" क्यों कहती है?

Accepted Answer

क्योंकि वह पूरी नहीं हो सकी - आमतौर पर इसलिए कि उस ओरिजिन पर कुछ भी जवाब नहीं आया। इसे ईमानदारी से रिपोर्ट किया जाता है, पास के रूप में दर्ज करने के बजाय।

Question 4

क्या मैं रिपोर्ट एक्सपोर्ट कर सकता हूँ?

Accepted Answer

हाँ, Markdown या JSON में, एक घंटे तक: डाउनलोड चल सकें इसलिए रिपोर्ट उतनी देर सर्वर कैश में रहती है, फिर हट जाती है। किसी भी एक्सपोर्ट में मॉडल शामिल नहीं होता। उपयोग रिकॉर्ड में फ़ाइंडिंग की संख्या और ग्रेड रहते हैं, डोमेन नहीं।

Question 5

यह किन फ़ाइलों और पोर्ट की जाँच करता है?

Accepted Answer

फ़ाइलें: 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 प्रकाशित हो तो आपके पक्ष में गिना जाता है। पोर्ट: 21 FTP, 23 Telnet, 25 SMTP, 3306 MySQL, 5432 PostgreSQL, 6379 Redis, 27017 MongoDB, 9200 Elasticsearch, 3389 RDP, 5900 VNC, 11211 Memcached, 8080 पर एक सादा TCP कनेक्शन, कभी लॉगिन की कोशिश नहीं। इंटरनेट से पहुँचने योग्य डेटाबेस पोर्ट (MySQL, PostgreSQL, Redis, MongoDB, Elasticsearch) या Telnet को क्रिटिकल माना जाता है।

Question 6

SPF और DMARC जाँच किन बातों को फ़्लैग करती हैं?

Accepted Answer

दोनों रिकॉर्ड सार्वजनिक DNS से पढ़े जाते हैं, उस साइट के लिए भी जो ईमेल नहीं भेजती, क्योंकि इनके बिना कोई भी ऐसा ईमेल भेज सकता है जो आपके डोमेन से आया लगे। SPF रिकॉर्ड न होना मीडियम है; +all वाला SPF रिकॉर्ड, जो इंटरनेट के हर सर्वर को अनुमति देता है, हाई है। _dmarc पर DMARC रिकॉर्ड न होना मीडियम है; p=none (या p= टैग न होना) सिर्फ़ निगरानी करता है और लो है; p=quarantine या p=reject पास होता है। जो डोमेन कोई ईमेल नहीं भेजता, वह v=spf1 -all प्रकाशित कर सकता है।

Question 7

यह कौन-से सिक्योरिटी हेडर जाँचता है, और कौन-सी वैल्यू पास होती है?

Accepted Answer

आपके होमपेज के रिस्पॉन्स के छह हेडर। न होने पर 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 कमांड दी जाती है ताकि आप ख़ुद जाँच सकें।

Question 8

यह कुकी फ़्लैग (Secure, HttpOnly, SameSite) कैसे जाँचता है?

Accepted Answer

यह आपके होमपेज के रिस्पॉन्स का हर Set-Cookie हेडर पढ़ता है (12 कुकी तक) और हर एक में Secure, HttpOnly और SameSite जाँचता है। Secure या HttpOnly न हो तो मीडियम; सिर्फ़ SameSite न हो तो लो, और Secure के बिना SameSite=None अलग से बताया जाता है क्योंकि ब्राउज़र ऐसी कुकी को अस्वीकार कर देते हैं। तीनों वाली कुकी पास होती है। आम सुधार है Secure; HttpOnly; SameSite=Lax (Django में: SESSION_COOKIE_SECURE, SESSION_COOKIE_HTTPONLY और SESSION_COOKIE_SAMESITE)। स्कैन लॉग इन नहीं करता, इसलिए सिर्फ़ लॉगिन के बाद बनने वाली कुकी उसे नहीं दिखतीं। ख़ुद जाँचें: curl -sI https://your-site/ | grep -i set-cookie

Question 9

CORS जाँच कैसे काम करती है, और यह क्रिटिकल कब होती है?

Accepted Answer

यह आपके होमपेज पर Origin: https://scanner-probe.example के साथ एक GET रिक्वेस्ट भेजता है और जवाब में Access-Control-Allow-Origin और Access-Control-Allow-Credentials पढ़ता है। Access-Control-Allow-Origin हेडर न हो, या कोई तय origin हो जो टेस्ट origin को वापस न लौटाए, तो पास। टेस्ट origin को Access-Control-Allow-Credentials: true के साथ लौटाना क्रिटिकल है, क्योंकि लॉग इन यूज़र जिस भी साइट पर जाए वह उसके रिस्पॉन्स पढ़ सकती है। क्रेडेंशियल के बिना origin लौटाना मीडियम है। वाइल्डकार्ड * लो है, या मीडियम अगर क्रेडेंशियल भी अनुमत हों (ब्राउज़र यह जोड़ अस्वीकार करते हैं)। सिर्फ़ होमपेज जाँचा जाता है और OPTIONS प्रीफ़्लाइट नहीं भेजा जाता, इसलिए अपने API रूट अलग से जाँचें: curl -sI -H "Origin: https://scanner-probe.example" https://your-site/api/ | grep -i access-control

Question 10

TLS जाँच क्या परखती है (सर्टिफ़िकेट की समाप्ति, TLS 1.0 और 1.1)?

Accepted Answer

यह पोर्ट 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

Question 11

क्या यह जाँचता है कि HTTP, HTTPS पर रीडायरेक्ट होता है?

Accepted Answer

हाँ। यह रीडायरेक्ट का पालन किए बिना http://your-site/ माँगता है। किसी https:// पते पर 301 या 308 पास है। HTTPS पर 302, 303 या 307 निम्न है, क्योंकि ब्राउज़र अस्थायी रीडायरेक्ट याद नहीं रखते, इसलिए हर नई विज़िट एक बिना एन्क्रिप्शन वाले अनुरोध से शुरू होती है। बिना एन्क्रिप्शन वाले HTTP पर दिया गया पेज (2xx जवाब) उच्च है। अगर पोर्ट 80 बिल्कुल जवाब न दे, तो यह जानकारी भर है, विफलता नहीं। nginx में सुधार है server { listen 80; return 301 https://$host$request_uri; }, फिर Strict-Transport-Security जोड़ें। खुद इस कमांड से जाँचें: curl -I http://your-site/

Question 12

यह किन HTTP मेथड को चिह्नित करता है (TRACE, PUT, DELETE)?

Accepted Answer

यह आपके होमपेज पर एक 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/

Question 13

यह डायरेक्टरी लिस्टिंग ("Index of /") कैसे पकड़ता है?

Accepted Answer

यह 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

Question 14

क्या यह मिश्रित सामग्री और HTTP पर भेजे जाने वाले फ़ॉर्म पकड़ता है?

Accepted Answer

हाँ, होमपेज पर। यह HTML को वैसे ही पढ़ता है जैसा सर्वर भेजता है (कोई JavaScript नहीं चलाया जाता) और हर script, link, iframe या img टैग की सूची बनाता है जिसका src या href http:// से शुरू होता है। इनमें कोई .js या .css फ़ाइल हो तो परिणाम मध्यम है, क्योंकि रास्ते में बदली गई स्क्रिप्ट या स्टाइलशीट आपके HTTPS पेज के अंदर चलती है; सिर्फ़ इमेज और फ़्रेम हों तो निम्न; एक भी न हो तो पास (CWE-311)। जिस फ़ॉर्म का action http:// से शुरू होता है वह उच्च माना जाता है (CWE-319), क्योंकि उसमें लिखा सब कुछ, पासवर्ड समेत, बिना एन्क्रिप्शन के जाता है। समाधान: इन URL को https:// करें या रिलेटिव बनाएँ, और सुरक्षा जाल के रूप में Content-Security-Policy: upgrade-insecure-requests हेडर जोड़ें। ख़ुद जाँचें: curl -s https://your-site/ | grep -Eo "(src|href|action)=.http://[^ >]*"

Question 15

यह robots.txt और security.txt में क्या जाँचता है?

Accepted Answer

robots.txt: यह /robots.txt लाता है और अगर जवाब HTTP 200 वाली टेक्स्ट फ़ाइल है तो उसके पहले 8000 अक्षरों की Disallow पंक्तियाँ पढ़ता है। जिस 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

Question 16

CAA जाँच क्या देखती है और CAA रिकॉर्ड कैसे जोड़ें?

Accepted Answer

यह आपके डाले गए होस्ट नाम के CAA रिकॉर्ड (RFC 8659) Cloudflare के DNS-over-HTTPS से देखती है। रिकॉर्ड मिलने पर जाँच पास होती है और प्रमाण में उनमें से अधिकतम 5 दिखते हैं; कोई न मिले तो यह "No CAA record" को कम गंभीरता के साथ बताती है, क्योंकि तब कोई भी सार्वजनिक प्रमाणपत्र प्राधिकरण (CA) उस नाम के लिए प्रमाणपत्र जारी कर सकता है। CAA रिकॉर्ड उन CA की सूची देता है जिन्हें आप सच में इस्तेमाल करते हैं, जैसे your-site. IN CAA 0 issue "letsencrypt.org", साथ में रिपोर्ट पाने के लिए 0 iodef "mailto:security@your-site"। हर इस्तेमाल होने वाले CA के लिए एक issue पंक्ति जोड़ें, और अगर वाइल्डकार्ड प्रमाणपत्र किसी दूसरे CA से आने हों तो एक issuewild पंक्ति। खुद जाँचें: dig CAA your-site

Question 17

www या किसी सबडोमेन को स्कैन करने पर CAA, SPF या DMARC न होने की रिपोर्ट क्यों आती है?

Accepted Answer

हर 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 से पुष्टि करें

वेबसाइट सुरक्षा स्कैन

हमारे बारे में वेबसाइट सुरक्षा स्कैन

यह क्या करता है

यह कैसे काम करता है

कोई निष्कर्ष बनावटी नहीं है

ग्रेड कैसे निकलता है

झूठे अलार्म से बचाव

एक साफ़ रिपोर्ट कोई प्रमाणपत्र नहीं है

केवल वही स्कैन करें जो आपका है

प्रश्न